[LLVMdev] OT: intel darwin losing primary target status

Nick Kledzik kledzik at apple.com
Fri Sep 18 11:13:52 PDT 2009

On Sep 18, 2009, at 10:43 AM, Jack Howarth wrote:

> On Fri, Sep 18, 2009 at 10:28:15AM -0700, Nick Kledzik wrote:
>> So, when these test cases are run, is the binary linked against /usr/
>> lib/libgcc_s.10.5.dylib? or against some just built libgcc_s. 
>> 10.5.dylib?
>> or against some just build libgcc_s.dylib?  If either of the  
>> latter, then
>> if you changed the FSF build of libgcc_s for darwin to have the right
>> magic symbols, then when targeting 10.6, the linker will ignore those
>> dylibs and record that the symbols should be found in
>> /usr/lib/libSystem.B.dylib at runtime.
> I'll double check but I believe that the testsuite always links the
> libgcc_s.10.5.dylib built by the FSF gcc build. The problem with the
> emutls symbols if I recall correctly is that those are not exposed
> through libgcc_s.10.5 but rather libgcc_s directly. For now, it would
> be better to ignore the emults issues and focus on what needs to be
> done to fix the unwinding. I guess you are saying we need to move
> the unwinders symbols out into a libgcc_ext and use that in the
> linkage on 10.6 or later so the FSF unwinder is used instead of
> the system one?
>                  Jack

The important thing is that only one unwinder is used.  The  
_Unwind_Context data structure is different between the darwin and FSF  
implementations, so you can't pass it between two different  
implementations.   Since darwin uses two-level namespace and swapping  
in a new libgcc_s.dylib at runtime is not going to effect the various  
OS dylibs that are looking for _Unwind_* routines in libSystem.dylib.

Even if you managed to get the test suite to run where everything is  
consistently using the just built libgcc_s.dylib, how will this work  
for end users of the gcc-4.5+ who want to ship an app built with  
gcc-4.5+?  Their code needs to use the OS unwinder.

So it seems to me you should be testing the compiler against the OS  
unwinder - not against the just built unwinder.

Has something changed in the FSF unwinder that clients of gcc will want?


P.S. One minor pet peeve of mine is that the exception handling is  
well layered (e.g. _cxa_* layer on top the _Unwind_* layer (which on  
darwin is now built upon the libunwind layer)).  Except for one  
glaring problem.  The compiler mostly emits calls to _cxa_* functions,  
but it makes one call to _Unwind_Resume.   Ah!!   And those are in  
different dylibs!  If instead the compiler made some call like  
__cxa_resume() in libstdc++.dylib which turned around and called  
_Unwind_Resume() in libgcc_s.dylib, then much of the problem above  
would never happen.

More information about the llvm-dev mailing list