On 31/05/2006, at 6:19 PM, Jack Howarth wrote:
If I take the link line generated for -shared-libgcc and substitute the the static libgcc, the resulting xplor binary doesn't abort on the throw.Also if I take the link line generated without -shared-libgcc and add "-lgcc_s.10.4", the resulting xplor binary also doesn't abort on the throw. Anything else to try to help pin this down?
I think that's pretty conclusive: something in the FSF GCC libgcc is causing this behaviour.
But... whatever it is must be in libgcc.a. That is, the part of libgcc that *doesn't* contain any exception-handling code!
Some parts of libgcc.a (the moddi and divdi routines) are built with unwind information. They're normally pretty simple, but maybe they contain bad data, or at least data that the shared library on Tiger doesn't understand. I don't see anything particularly weird in my copy.
I guess the next step would be to try to narrow it down to a specific file in libgcc.a. I think you can pass the '-whyload' command to the linker to see each .o file that gets loaded. Hopefully this will narrow it down to just one, which I guess you could then send to me so I can see if it's different from the one I have built here.
smime.p7s
Description: S/MIME cryptographic signature
