[LLVMdev] OT: intel darwin losing primary target status

[Jack Howarth]

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