Jack Howarth
2009-Sep-18 15:16 UTC
[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
Nick Kledzik
2009-Sep-18 16:21 UTC
[LLVMdev] OT: intel darwin losing primary target status
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 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
Possibly Parallel Threads
- [LLVMdev] OT: intel darwin losing primary target status
- [LLVMdev] OT: intel darwin losing primary target status
- [LLVMdev] OT: intel darwin losing primary target status
- Unifying CMake variable names used in checks across subprojects
- LLD-linked binary segfaults at runtime on alpine linux