thr3ads.net - llvm dev - [LLVMdev] OT: intel darwin losing primary target status [Sep 2009]

If this information is useful, please help other people find it:
Share via:

Jack Howarth

2009-Sep-18 16:47 UTC

[LLVMdev] OT: intel darwin losing primary target status

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

Nick Kledzik

2009-Sep-18 17:28 UTC

head link

[LLVMdev] OT: intel darwin losing primary target status

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

Jack Howarth

2009-Sep-18 17:43 UTC

head link

[LLVMdev] OT: intel darwin losing primary target status

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

Possibly Parallel Threads

Search for more reasonably related threads

llvm dev - Sep 2009 - [LLVMdev] OT: intel darwin losing primary target status

[LLVMdev] OT: intel darwin losing primary target status

[LLVMdev] OT: intel darwin losing primary target status

[LLVMdev] OT: intel darwin losing primary target status

Possibly Parallel Threads