[LLVMdev] OT: intel darwin losing primary target status

[Nick Kledzik]

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?

-Nick

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.