Dear GHDL colleagues,

I am posting this information in the hopes that someone might have
encountered it before, or can point me where to look to help isolate
things down further.

I'm (unfortunately) not as expert with gdb as others, but I'll continue to
dig into this. Its a learning experience thats for sure, and now I want to
learn Ada... assuming this eventually gets solved.

===

Here are what I believe are the relevant bits of information:

Program received signal SIGSEGV, Segmentation fault.
0x00028304 in grt.signals.update_signals ()
    at 
/home/ssingh/GHDL/27-gcc-4.1.2/gcc-4.1.2/gcc/vhdl/grt/grt-signals.adb:3054

===

This is line 3054 of the grt-signals source file, using gcc-4.1.2 and
ghdl-0.27 grafted into the source tree on Solaris 8 for SPARC.

===

Here is the backtrace:

(gdb) bt
#0  0x00028304 in grt.signals.update_signals ()
    at 
/home/ssingh/GHDL/27-gcc-4.1.2/gcc-4.1.2/gcc/vhdl/grt/grt-signals.adb:3054
#1  0x0002c150 in grt.processes.simulation_cycle ()
    at 
/home/ssingh/GHDL/27-gcc-4.1.2/gcc-4.1.2/gcc/vhdl/grt/grt-processes.adb:694
#2  0x0003097c in __ghdl_run_through_longjump (
    func=0x2c128 <grt.processes.simulation_cycle>)
    at ../../../gcc/vhdl/grt/config/linux.c:312
#3  0x0002bb64 in grt.processes.simulation ()
    at 
/home/ssingh/GHDL/27-gcc-4.1.2/gcc-4.1.2/gcc/vhdl/grt/grt-processes.adb:841
#4  0x00036614 in grt.main.run ()
    at /home/ssingh/GHDL/27-gcc-4.1.2/gcc-4.1.2/gcc/vhdl/grt/grt-main.adb:147
#5  0x0003479c in ghdl_main (argc=0, argv=4290705380)
    at /home/ssingh/GHDL/27-gcc-4.1.2/gcc-4.1.2/gcc/vhdl/grt/ghdl_main.adb:51
#6  0x00030ba0 in main (argc=1, argv=4290705380)
    at ../../../gcc/vhdl/grt/main.adb:24
(gdb)

===

You can see that before breaking at 3054, it passes through several other
functions that are part of the GHDL runtime package.

I took a closer look at the linux.c file and it appears that there is some
kind of handling of the SIGSEGV signal within this file:

#ifdef linux
/* If set, SIGSEGV is caught in order to automatically grow the stacks.  */
#define EXTEND_STACK 1
#endif

I take this to mean that if this SIGSEGV (signal segment violation?) flag
goes up, the runtime is able to catch it and enlarge the stack as
necessary, but if there is no signal handler for this, its thrown to the
operating system with mercilessly kills the process.

So, does this get processed in the case of a Solaris environment? Would it
need to? I'm not sure.

===

I might try to cross reference with a .25 binary with gdb tomorrow to see,
and/or look at the sources for .25, but its significantly earlier and such
functionality might be absent.

Anyway, if anyone has any advice, please let me know.

Thanks for your time reading this.

S.

_______________________________________________
Ghdl-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/ghdl-discuss

Reply via email to