[LLVMdev] OT: intel darwin losing primary target status
kledzik at apple.com
Fri Sep 18 13:13:52 CDT 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.
>> 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?
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 LLVMdev