[LLVMdev] OT: intel darwin losing primary target status
Nick Kledzik
kledzik at apple.com
Fri Sep 18 10:28:15 PDT 2009
Jack,
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
-Nick
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. */
> #undef REAL_LIBGCC_SPEC
> #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