alan buckley wrote:
On Wed, 2 Apr 2008 18:42:15 +0100 Lee Noar wrote:
alan buckley wrote:
I've cross compiled a large C++ game (the latest version of
wesnoth) in the autobuilder using the GCC4.1 cross compiler
on Cygwin and although it builds OK, when I try to run it I get
a wimp error box with the following:
Unixlib detected recursion of signal SIGSEGV.
My usual debugging technique of putting printf into the
program is not working as it doesn't even reach the main
function.
A grep of the src didn't show any signal handlers that
could be installed at this point.
Could this be a bug in the compiler/unixlib?
Can anyone suggest what I need to do to track the
error down?
>>
Global object constructors are called before main(), so this is probably
where the crash is occurring.
That was/still is my thought, but I couldn't see how you could get
a signal recursion if no signal was being set. (It is possible
that I missed something though).
Basically, the order of execution is:
1) UnixLib initialisation
2) Global object constructors called (IIRC, the order the constructors
are called is the same as the order they appear on the linker's command
line).
3) main() called.
Signal handlers for hardware exceptions such as memory violations are
set up by UnixLib during its initialisation, so global object
constructors can cause a SIGSEGV.
One trick you can try is disabling the
UnixLib signal handlers in syslib.s so that RISC OS gives you the error
directly. !Reporter may be useful here to catch the error for reading.
I've looked at syslib.s and unfortunately the code is beyond me. Is there
a simple modification I can make to the file to do this?
Yes, in syslib/_syslib.s, you should see a section that starts like this:
handlers:
.word 0 @ Memory limit
.word __h_sigill @ Undefined instruction
.word __h_sigsegv0 @ Prefetch abort
.word __h_sigsegv1 @ Data abort
.word __h_sigbus @ Address exception
by replacing the __h_* symbols above with a zero, you can disable the
hardware exception signals. You'll have to rebuild UnixLib and relink
your binary.
Are you static linking?
Yes. I was also running it through elf2aif. I tried again running it as an
elf application and got the same result.
At least we can rule out dynamic linking as a possible cause.
Lee.
_______________________________________________
GCCSDK mailing list [email protected]
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK
