[LLVMdev] OT: intel darwin losing primary target status

Nick Kledzik kledzik at apple.com
Fri Sep 18 10:28:15 PDT 2009


I think there is an extra dimension to darwin that might be confusing  
things.  Darwin uses two-level-name-space.  That means that at build  
time the linker records where it found each dylib (SO) symbol.  (It  
records the path the dylib supplied as its "install name" - not just  
the leafname as SO_NEEDED does.)

On a SnowLeopard system you *can* link against /usr/lib/libgcc_s. 
10.5.dylib, but the linker will not record any symbols coming from  
it.  In fact, the link order does not matter.  That is because /usr/ 
lib/libgcc_s.10.5.dylib has magic symbols in it that say if you are  
targeting 10.6 then _Unwind_Resume  (and other other symbols) are not  
in that dylib, so the linker looks elsewhere and finds them in  
libSystem.B.dylib.  In other words, the compiler changes to  
SnowLeopard to omit /re-order the linking with -lgcc_s when targeting  
10.6 was just an optimization and not required.

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.

That does mean you will *not* be implicitly testing the libgcc just  
built (since at runtime the OS implementation of libgcc functions in  
libSystem.dylib will be used), but I think this test suite is supposed  
to be testing the compiler.  So that should be OK.

It also means any new symbols introduced in main line libgcc *will* be  
recorded as coming from /custom/path/libgcc_s.1.dylib.  Which again is  
what you want (as long as the functions are independent and don't need  
to be used in sets). And very similar to the libgcc_ext.dylib idea  
from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3988


On Sep 18, 2009, at 9:47 AM, Jack Howarth wrote:

> Nick,
>    How exactly do you envision this being done? Looking at the  
> contents
> of config/darwin.h, I see...
> /* Support -mmacosx-version-min by supplying different (stub)  
> libgcc_s.dylib
>   libraries to link against, and by not linking against libgcc_s on
>   earlier-than-10.3.9.
>   Note that by default, -lgcc_eh is not linked against!  This is
>   because in a future version of Darwin the EH frame information may
>   be in a new format, or the fallback routine might be changed; if
>   you want to explicitly link against the static version of those
>   routines, because you know you don't need to unwind through system
>   libraries, you need to explicitly say -static-libgcc.
>   If it is linked against, it has to be before -lgcc, because it may
>   need symbols from -lgcc.  */
> #define  
> REAL_LIBGCC_SPEC                                                   \
>   "%{static-libgcc|static: -lgcc_eh - 
> lgcc;                                \
>      shared-libgcc|fexceptions|fgnu- 
> runtime:                              \
>       %:version-compare(!> 10.5 mmacosx-version-min= -lgcc_s. 
> 10.4)        \
>       %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s. 
> 10.5)        \
>       - 
> lgcc;                                                              \
>      :%:version-compare(>< 10.3.9 10.5 mmacosx-version-min= -lgcc_s. 
> 10.4) \
>       %:version-compare(>= 10.5 mmacosx-version-min= -lgcc_s. 
> 10.5)        \
>       -lgcc}"
> Would it be as simple as adding...
> %:version-compare(>= 10.6 mmacosx-version-min= -lgcc_s.10.5)        \
>       -lSystem -lgcc}"
> or could we even use...
> %:version-compare(>= 10.6 mmacosx-version-min= -lgcc_s.10.5)        \
>       -lSystem -lgcc_s}"
> I think the second case would solve the outstanding issue of the
> TLS emutls not being linked in on darwin...
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888
> which would definitely be nice and take a lot of the testsuite
> out of the unsupported result mode.
>   If anyone would like to propose a specific patch, I would be
> more than happy to test it against current gcc trunk.
>                    Jack
> On Fri, Sep 18, 2009 at 09:21:52AM -0700, Nick Kledzik wrote:
>> This may be that the libgcc_s.dylib based unwinder is incompatible  
>> with
>> the darwin unwinder.  You cannot mix and match the two.  One of the  
>> lines
>> from the bugzilla comments shows:
>> /sw/lib/gcc4.5/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
>> being used.   That will not work.  All of the libgcc_s.dylib
>> functionality has been subsumed into libSystem.dylib on SnowLeopard
>> (darwin10).   The gcc compiler that shipped with SnowLeopard leaves  
>> the
>> -lgcc_s off the link line when targeting SnowLeopard.   If there is a
>> newer libgcc_s with new functions added, then the link line needs to
>> change to "-lSystem -lgcc_s", that way the linker will find the most
>> routines in libSystem.dylib and only the new functions from
>> libgcc_s.dylib.  Thus all linkage units will use the same unwinder.
>> -Nick
>> On Sep 18, 2009, at 8:16 AM, Jack Howarth wrote:
>>> I realize this is off-topic for the list, but I thought
>>> all the darwin developers here might want to be aware of
>>> this. The current regressions in gcc trunk regarding
>>> exception handling has been escalated to a P1 in order to
>>> attract darwin developers to the issue...
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41260#c31
>>> If these regressions aren't fixed before gcc 4.5's release,
>>> it appears the *-*-darwin will be removed from the primary
>>> target list for FSF gcc. This would be rather unfortunate
>>> since it would eventually compromise the quality of fortran
>>> compilers that darwin users have access to. Hopefully the
>>> current darwin maintainers listed for FSF gcc can find some
>>> approach acceptable to their management where the other
>>> FSF gcc developers can be guided through debugging and
>>> fixing this regression.
>>>               Jack
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

More information about the llvm-dev mailing list