On 29/03/11 2:18 PM, Brian Davis wrote:
>
> You seem to have missed the main point of my earlier message:
>
>>> It looks like you're building an mcode target, which doesn't create
> object files.
>
> i.e., the GHDL you have built __IS NOT USING THE GCC BACK END__
>
> It is instead using the mcode back end, which is a stand alone JIT
> module that generates object code at runtime.
Thanks for straightening me out. I've been doing too many things at the
same time and getting wires crossed. I hadn't even noticed I had gotten a
segmentation fault:
Macbook: ghdl -r test_config des_tb --stop-time=1ns
Segmentation fault
Until your insistent repetition caused me to look closer. And I used to
know all about this stuff, didn't write anything down and "Short term memory
is the first to go". Almost as bad as a memory leak.
Macbook: ghdl -a hello.vhdl
Macbook: ghdl -r hello world
Segmentation fault
Macbook: ghdl -r hello moon
hello.vhdl:20:9:@0ms:(report note): "greetings earthling!"
Macbook: more hello.vhdl
use std.textio.all;
entity hello is
end;
architecture world of hello is
begin
hello_world:
process
variable l: line;
begin
write (l, String'("Hello world!"));
writeline (output, l);
wait;
end process;
end world;
architecture moon of hello is
begin
hello_world:
process
begin
report """greetings earthling!""";
wait;
end process;
end moon;
--
A simple hello world doesn't run without a segmentation fault.
An even simpler program does though.
> I think I have tracked down the Windows mcode stack allocation bug,
> with a fix better than the double-the-stack-alignment-constant hack
> I mentioned earlier; I'll post a patch in a day or so once I've run it
> against some non-trivial VHDL source code.
>
> That same bug might be causing your OS-X mcode segmentation fault.
There's a chance.
Thanks
_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss