alan buckley wrote:
In an attempt to narrow down the crash I
get when exceptions are thrown in various
C++ programs (wesnoth and others) I've
managed to come up with the following short
c++ program that crashes.
<snip>
I've been looking into this over the past few weeks without much
success. I believe that this bug may be part of the problem:
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38952>
Fixing this allows wesnoth to go a bit further but then hits another
problem. I think a big part of it is the use of the builtin
setjmp/longjmp functions which GCC generates inlined code for. This code
doesn't save and restore the stack limit register or take into account
the stack chunk/alloca freeing code. I did try disabling the builtin
versions so that calls to the UnixLib versions would be used, but that
resulted in an internal compiler error during the building of libstdc++
by the cross compiler.
I think it was at this point that I decided I was wasting my time trying
to fix SjLj exceptions and I'd be better off trying to fix the call
frame exception code instead as that is the better of the two exception
models.
However, there are similar problems here to do with the stack extension
code. This exception model depends on return addresses stored on the
stack to determine which call frame is responsible for handling the
exception, but the stack extension code can change the return address so
that __stack_free is automatically called. This causes the search for a
handler to fail. We can get around this by interrogating the stack to
find the original return address - a bit of a hack unfortunately. I
think this helps, but wesnoth still crashes :-(
I'll keep looking.
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
