Exception handling information in the macintosh

[jacob navia]

Jack Howarth a écrit :
> On Thu, Feb 04, 2010 at 08:12:10PM +0100, jacob navia wrote:
>   
>> Hi
>>
>> I have developed a JIT for linux 64 bits. It generates exception  
>> handling information
>> according to DWARF under linux and it works with gcc 4.2.1.
>>
>> I have recompiled the same code under the Macintosh and something has  
>> changed,
>> apparently, because now any throw that passes through my code crashes.
>>
>> Are there any differences bertween the exception info format between the
>> macintosh and linux?
>>
>> The stack@the moment of the throw looks like this:
>>
>>    CPP code compiled with gcc  4.2.1 calls
>>    JIT code generated on the fly by my JIT compiler that calls
>>    CPP code compiled with gcc 4.2.1 that throws. The catch
>>    is in the CPP code
>>   The throw must go through the JIT code, so it needs the DWARF frame  
>> descriptions
>> that I generate. Apparently there is a difference.
>>
>> Thanks in advance for any information.
>>
>> jacob
>>
>>
>>     
>
> Jacob,
>     Are you compiling on darwin10 and using the Apple or FSF
> gcc compilers? If you are using Apple's, this question should
> be on the darwin-devel mailing list instead. 
I did that. I was compiling with Apple's gcc.

Now, I downloaded the source code of gcc 4.2.1 and compiled that in my Mac.
The build crashed in the java section by the way,  there was a script that
supposed the object files in a .libs directory but the objects were in the
same directory as the source code. This happened several times, so at the
end I stopped since I am not interested in Java.

I installed gcc, everything went OK, and I recompiled the source code
with the new gcc.

Then, in the new executable, the normal throws that have been working
under the Apple's gcc do not work anymore and any throw (not only those
that go through the JIT) fail.

I do not understand what is going on.

> I would mention
> though that darwin10 is problematic in that the libgcc and its
> unwinder calls are now subsumed into libSystem. This means that
> regardless of how you try to link in libgcc, the new code in
> libSystem will always be used. For darwin10, Apple decided to
> default their linker over to compact unwind which causes problems
> with some of the java testcases on gcc 4.4.x. This is fixed for
> FSF gcc 4.5 by forcing the compiler to always link with the
> -no_compact_unwind option. 
If you use that option I get

ld: symbol dyld_stub_binding_helper not defined (usually in 
crt1.o/dylib1.o/bundle1.o)
and Apple's linker refuses to go on.

> Another complexity is that Apple
> decided to silently abort some of the libgcc calls (now in
> libSystem) that require access to FDEs like _Unwind_FindEnclosingFunction().
> The reasoning was that the default behavior (compact unwind info) doesn't
> use FDEs.
>    This is fixed for gcc 4.5 by http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00998.html.
> If you are using any other unwinder call that is now silently
> aborting, let me know as it may be another that we need to re-export
> under a different name from libgcc_ext. Alternatively, you may
> be able to work around this issue by using -mmacosx-version-min=10.5
> under darwin10.
>        Jack
>   


OK, now, what would be the procedure for getting to avoid Apple's 
modifications to the
exception handling stuff?

Pleeeeeeeze :-)

P.S. If this discussion does not belong in this list please send me just 
an email.

Thanks for your answers.

jacob