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

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

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,
    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