_Unwind_GetIPInfo changed the ABI for libgcc and it is hard to add it to the new libgcc for 10.4. See http://gcc.gnu.org/ml/gcc-patches/2006-02/msg02041.html I am filing this so we keep track of this and this is a blocker for 4.2 for being released.
If darwin doesn't care about the PR other/26208 problem, it can certainly just #define _Unwind_GetIPInfo(ctx, ip) (*(ip) = 0, _Unwind_GetIP (ctx) in its own unwind.h or something similar. But if it cares, it needs to allow libgcc_s symbol additions.
Clearly, we cannot add any symbols to the 10.4 libgcc_s. 10.4 has already shipped, and we do not have a time travel device. By default, gcc compiles for the earliest OS version it knows about. For C++, that means 10.3.9/10.4. This is best for users. Thus, by default, you cannot use any new symbols in libgcc_s. The problem occurs because libstdc++ wants to use the new symbol by default. I can think of a bunch of solutions to the problem: 1. Have libstdc++ use autoconf to detect the presence of the new symbol and use it only if it exists. 2. Decide that the purpose of libstdc++ is to be installed only on new (not yet existing) system versions, and pass appropriate flags to the compiler to make this happen. Of course, this might make testing hard for people still using 10.4. 3. Decide that libstdc++ and libgcc go together, and hack libstdc++'s link to use libgcc_s.1.dylib directly. Apple doesn't do this internally, we're shipping 4.0.0 libstdc++ and 4.0.1 libgcc. Apple's libstdc++ is binary incompatible with FSF libstdc++ (in small but important ways) and so the effect of this might be that no-one can use FSF libstdc++ or FSF libgcc on Darwin at all. 4. Declare that we don't care. The problem right now affects only people with the MACOSX_DEPLOYMENT_TARGET environment variable set which they probably shoudn't have set while building FSF GCC. I think we should go for (1), although (4) has certain advantages...
It appears that on Macintel, simply unsetting MACOSX_DEPLOYMENT_TARGET is insufficient to eliminate the undefined symbols for _Unwind_GETIPInfo when building gcj. This doesn't happen on ppc Darwin. Currently the fink developers have decided to leave MACOSX_DEPLOYMENT_TARGET set to 10.4 and use the http://gcc.gnu.org/ml/gcc-patches/2006-02/msg02041.html patch. Would it be better for them to unset MACOSX_DEPLOYMENT_TARGET and use Jakub's recommendation of adding... #define _Unwind_GetIPInfo(ctx, ip) (*(ip) = 0, _Unwind_GetIP (ctx) to a darwin specific unwind.h? I am trying to get them from forking the libstdc++ in fink. Jack
Geoff, Does any other os, that uses gcc, version libgcc_s in the manner that Apple does? Simply not setting MACOSX_DEPLOYMENT_TARGET during the build of gcc 4.2 doesn't make the problem go away. The resulting libstdc++.6.dylib and libgcc_s.1.dylib libraries have _Unwind_GetIPInfo symbols whereas libgcc_s.10.4.dylib and libgcc_s.10.5.dylib don't. This precludes safely using MACOSX_DEPLOYMENT_TARGET at all with gcc 4.2. I know you said you won't assign this to yourself until it happens to you. However it isn't happening to you because you don't want it to. Apple really needs to deal with the breakage caused by their decision to version libgcc_s. Jack (In reply to comment #2) > Clearly, we cannot add any symbols to the 10.4 libgcc_s. 10.4 has already > shipped, and we do not have a time travel device. > > By default, gcc compiles for the earliest OS version it knows about. For C++, > that means 10.3.9/10.4. This is best for users. > > Thus, by default, you cannot use any new symbols in libgcc_s. > > The problem occurs because libstdc++ wants to use the new symbol by default. I > can think of a bunch of solutions to the problem: > 1. Have libstdc++ use autoconf to detect the presence of the new symbol and use > it only if it exists. > 2. Decide that the purpose of libstdc++ is to be installed only on new (not yet > existing) system versions, and pass appropriate flags to the compiler to make > this happen. Of course, this might make testing hard for people still using > 10.4. > 3. Decide that libstdc++ and libgcc go together, and hack libstdc++'s link to > use libgcc_s.1.dylib directly. Apple doesn't do this internally, we're > shipping 4.0.0 libstdc++ and 4.0.1 libgcc. Apple's libstdc++ is binary > incompatible with FSF libstdc++ (in small but important ways) and so the effect > of this might be that no-one can use FSF libstdc++ or FSF libgcc on Darwin at > all. > 4. Declare that we don't care. The problem right now affects only people with > the MACOSX_DEPLOYMENT_TARGET environment variable set which they probably > shoudn't have set while building FSF GCC. > > I think we should go for (1), although (4) has certain advantages... >
Created attachment 11724 [details] libstdc++ macro to test for _Unwind_GetIPInfo I have attached a macro that could be put in libstdc++-v3/acinclude.m4 and called from configure to check for the existence of _Unwind_GetIPInfo. I haven't submitted it as a patch because I don't know how to handle Java. libjava also uses _Unwind_GetIPInfo but the java configure script doesn't seem to allow for compiling and linking test programs in order to check for routines.
I think this can be confirmed now.
Proposed patch at http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00734.html
I can confirm on MacOS X 10.4 that Steve's proposed patch works fine with the current gcc trunk. I can successfully bootstrap while MACOSX_DEPLOYMENT_TARGET is set to 10.4 and no regressions occur when the 'make check' is done afterwards without MACOSX_DEPLOYMENT_TARGET being set. Only libgcc_s.1.dylib ends up with __Unwind_GetIPInfo being defined. The libgcc_s.10.4.dylib and libgcc_s.10.5.dylib files do not. However I guess we should ask Geoff if Apple would like __Unwind_GetIPInfo defined in libgcc_s.10.5.dylib since that library is unreleased.
We can't define __Unwind_GetIPInfo in libgcc_s.10.5.dylib at this time. If we create a situation in which we can, rest assured, we will.
Subject: Bug 26792 Author: sje Date: Fri Jul 21 21:07:15 2006 New Revision: 115653 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115653 Log: PR target/26792 * unwind_ipinfo.m4: New. Added: trunk/config/unwind_ipinfo.m4 Modified: trunk/config/ChangeLog
Subject: Bug 26792 Author: sje Date: Fri Jul 21 21:11:46 2006 New Revision: 115654 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115654 Log: PR target/26792 * configure.ac: Use GCC_CHECK_UNWIND_GETIPINFO to define HAVE_GETIPINFO. * aclocal.m4: Add include of ../config/unwind_ipinfo.m4. * config.h.in: Regenerate. * configure: Regenerate. * Makefile.in: Regenerate. * libmath/Makefile.in: Regenerate. * include/Makefile.in: Regenerate. * src/Makefile.in: Regenerate. * libsupc++/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. * po/Makefile.in: Regenerate. * libsupc++/eh_personality.cc: Check HAVE_GETIPINFO. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/Makefile.in trunk/libstdc++-v3/aclocal.m4 trunk/libstdc++-v3/config.h.in trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac trunk/libstdc++-v3/include/Makefile.in trunk/libstdc++-v3/libmath/Makefile.in trunk/libstdc++-v3/libsupc++/Makefile.in trunk/libstdc++-v3/libsupc++/eh_personality.cc trunk/libstdc++-v3/po/Makefile.in trunk/libstdc++-v3/src/Makefile.in trunk/libstdc++-v3/testsuite/Makefile.in
This looks fixed to me.
Actually libstdc++ is only part of the problem, the other part is libjava. Eric if you are going to close something, you should test it.
The bug says c++, feel like opening another one or fixing the title on the bug you opened?
Bryce, have you looked at ifdef'ing the use of _Unwind_GetIPInfo in the Java library? Would you be willing to do so? I have created an autoconf test (GCC_CHECK_UNWIND_GETIPINFO) in trunk/config/unwind_ipinfo.m4 and the C++ runtime library is checking for HAVE_GETIPINFO before using it. I believe the un-ifdef'ed use of this function in the java library is the reason this PR is still open.
Is this what we are waiting for? I came up with that by just placing wrappers around the changes submitted on... http://gcc.gnu.org/viewcvs/trunk/libjava/stacktrace.cc?r1=115069&r2=115235&pathrev=115235 and http://gcc.gnu.org/bugzilla/attachment.cgi?id=10915 so that the previous code was in place when HAVE_GETIPINFO is false. Index: exception.cc =================================================================== --- exception.cc (revision 116995) +++ exception.cc (working copy) @@ -231,7 +231,11 @@ PERSONALITY_FUNCTION (int version, // Parse the LSDA header. p = parse_lsda_header (context, language_specific_data, &info); + #ifdef HAVE_GETIPINFO ip = _Unwind_GetIPInfo (context, &ip_before_insn); + #else + ip = _Unwind_GetIP (context) - 1; + #endif if (! ip_before_insn) --ip; landing_pad = 0; Index: stacktrace.cc =================================================================== --- stacktrace.cc (revision 116995) +++ stacktrace.cc (working copy) @@ -131,6 +131,7 @@ _Jv_StackTrace::UnwindTraceFn (struct _U else #endif { +#ifdef HAVE_GETIPINFO _Unwind_Ptr ip; int ip_before_insn = 0; ip = _Unwind_GetIPInfo (context, &ip_before_insn); @@ -139,9 +140,13 @@ _Jv_StackTrace::UnwindTraceFn (struct _U // to ensure we get the correct line number for the call itself. if (! ip_before_insn) --ip; - +#endif state->frames[pos].type = frame_native; +#ifdef HAVE_GETIPINFO state->frames[pos].ip = (void *) ip; +#else + state->frames[pos].ip = (void *) _Unwind_GetIP (context); +#endif state->frames[pos].start_ip = func_addr; } @@ -217,6 +222,12 @@ _Jv_StackTrace::getLineNumberForFrame(_J else offset = (_Unwind_Ptr) ip - (_Unwind_Ptr) info.base; +#ifndef HAVE_GETIPINFO + // The unwinder gives us the return address. In order to get the right + // line number for the stack trace, roll it back a little. + offset -= 1; +#endif + finder->lookup (binaryName, (jlong) offset); *sourceFileName = finder->getSourceFile(); *lineNum = finder->getLineNum();
(In reply to comment #15) Yes, I think the #ifdef is a reasonable solution. Stack traces will be inaccurate when GetIPInfo is unavailable, but I don't see any easy way around that.
Created attachment 12288 [details] Patch to revert to _Unwind_GetIP when HAVE_GETIPINFO undefined
Tested the patch on Darwin 8 with no regressions. Verified that the _Unwind_GetIPInfo symbols are absent for libgcj with HAVE_GETIPINFO undefined. While the patch is over 10 lines, I would argue that I only wrote the lines with the preprocessor statements and the rest is simply a return of previously existing code from others. LAST_UPDATED: Tue Sep 5 01:41:47 UTC 2006 (revision 116689) Native configuration is powerpc-apple-darwin8 === libjava tests === Running target unix === libjava Summary === # of expected passes 6989 # of expected failures 12 # of untested testcases 8 Compiler version: gcc libjava Platform: powerpc-apple-darwin8 configure flags: --prefix=/sw --prefix=/sw/lib/gcc4 --with-gmp=/sw --with-included-gettext --host=powerpc-apple-darwin8 --with-as=/sw/lib/odcctools/bin/as --with-ld=/sw/lib/odcctools/bin/ld --with-nm=/sw/lib/odcctools/bin/nm '--mandir=\${prefix}/share/man' '--infodir=\${prefix}/share/info' --with-libiconv-prefix=/sw --disable-bootstrap --enable-languages=c,c++,fortran,java,objc
Created attachment 12289 [details] clean up whitespace in Changelog for patch to revert to _Unwind_GetIP when HAVE_GETIPINFO undefined
Steve has checked in the changes to config/unwind_ipinfo.m4, so I believe all we need now is... Index: libjava/configure.ac =================================================================== --- libjava/configure.ac (revision 117056) +++ libjava/configure.ac (working copy) @@ -1480,6 +1480,9 @@ # See if we support thread-local storage. GCC_CHECK_TLS +# For _Unwind_GetIPInfo. +GCC_CHECK_UNWIND_GETIPINFO + # Check if linker supports static linking on a per library basis LD_START_STATIC_SPEC= LD_FINISH_STATIC_SPEC= I'll test that with tonight's gcc trunk build using MACOSX_DEPLOYMENT_TARGET unset which should create both a libstdc++ and libgcj with the _Unwind_GetIPInfo symbols. This should complete the fix for this PR.
Okay, the autoconf changes for libstdc++ and libgcj actually work okay. The test program uses the static libgcc.a to link (which lacks the __Unwind_GetIP symbol) so that HAVE_GETIPINFO remains undefined regardless of whether MACOSX_DEPLOYMENT_TARGET is set or not. I believe this is the behavior we want on Darwin since the alternative of allowing MACOSX_DEPLOYMENT_TARGET unset to cause __Unwind_GetIP to be used in libstdc++ and libgcj would create libraries that couldn't be used when MACOSX_DEPLOYMENT_TARGET was set to 10.4 or 10.5. I'll post the patches to gcc-patches shortly.
Proposed patches are posted at... http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00906.html http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00908.html ...which together should allow this PR to be finally closed.
Created attachment 12333 [details] revised libjava patch preventing double deincrementation
Subject: Bug 26792 Author: tromey Date: Wed Sep 27 21:24:23 2006 New Revision: 117259 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117259 Log: 2006-09-26 Jack Howarth <howarth@bromo.med.uc.edu> PR target/26792: * exception.cc (PERSONALITY_FUNCTION): use _Unwind_GetIP if HAVE_GETIPINFO not defined. * stacktrace.cc (_Jv_StackTrace::UnwindTraceFn): Likewise. (_Jv_StackTrace::getLineNumberForFrame): Likewise. * configure.ac: use GCC_CHECK_UNWIND_GETIPINFO. * aclocal.m4, configure, include/config.h.in, Makefile.in: Rebuilt. Modified: trunk/libjava/ChangeLog trunk/libjava/Makefile.in trunk/libjava/aclocal.m4 trunk/libjava/configure trunk/libjava/configure.ac trunk/libjava/exception.cc trunk/libjava/gcj/Makefile.in trunk/libjava/include/Makefile.in trunk/libjava/include/config.h.in trunk/libjava/stacktrace.cc trunk/libjava/testsuite/Makefile.in
Fix checked in.
One last minor nit with regards to the autoconf changes for both libstdc++-v3 and libjava. I notice that in config.log in libstdc++-v3 for example, I get... configure:31103: checking for _Unwind_GetIPInfo configure:31130: /sw/src/fink.build/gcc4-4.1.9999-20060927/darwin_objdir/./gcc/xgcc -shared-libgcc -B/sw/src/fink.build/gcc4-4.1.99 99-20060927/darwin_objdir/./gcc -nostdinc++ -L/sw/src/fink.build/gcc4-4.1.9999-20060927/darwin_objdir/powerpc-apple-darwin8/libstdc+ +-v3/src -L/sw/src/fink.build/gcc4-4.1.9999-20060927/darwin_objdir/powerpc-apple-darwin8/libstdc++-v3/src/.libs -B/sw/lib/gcc4/power pc-apple-darwin8/bin/ -B/sw/lib/gcc4/powerpc-apple-darwin8/lib/ -isystem /sw/lib/gcc4/powerpc-apple-darwin8/include -isystem /sw/lib /gcc4/powerpc-apple-darwin8/sys-include -o conftest -g -O2 -fno-exceptions conftest.cc -lm >&5 /sw/lib/odcctools/bin/ld: warning -L: directory name (/sw/src/fink.build/gcc4-4.1.9999-20060927/darwin_objdir/powerpc-apple-darwin8/ libstdc++-v3/src) does not exist /sw/lib/odcctools/bin/ld: warning -L: directory name (/sw/src/fink.build/gcc4-4.1.9999-20060927/darwin_objdir/powerpc-apple-darwin8/ libstdc++-v3/src/.libs) does not exist /sw/lib/odcctools/bin/ld: Undefined symbols: __Unwind_GetIPInfo which suggests that configure is attempting to use directories before they exist. Is that worth fixing in both libstdc++-v3 and libjava?
I doubt those configure warnings are very important.
Subject: Bug 26792 Author: aph Date: Fri Jan 19 15:25:34 2007 New Revision: 120968 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120968 Log: 2006-07-21 Steve Ellcey <sje@cup.hp.com> PR target/26792 * unwind_ipinfo.m4: New. Added: branches/redhat/gcc-4_1-branch-java-merge-20070117/config/unwind_ipinfo.m4 - copied unchanged from r115653, trunk/config/unwind_ipinfo.m4 Modified: branches/redhat/gcc-4_1-branch-java-merge-20070117/config/ChangeLog
The configure check is finding the definition of _Unwind_GetIPInfo in libgcc_s (from unwind-compat.o) when configuring with --with-system-libunwind.
When configuring with --with-system-libunwind, GCC should not include unwind-compat.o (or any unwind code) in the build of libgcc_s. Then the configure check will work correctly.
unwind-compat is _required_ for the system libunwind.
Geoff, do you intend to backport these Darwin patches to 4.2.0?
I don't know what patches you're referring to, so no.
(In reply to comment #33) > Geoff, do you intend to backport these Darwin patches to 4.2.0? > Mark, Are you under the impression that the libstdc++-v3 and libjava patches were only applied to trunk? That isn't the case as those went into 4.2 branch some time ago as r115654 and r117259. The only outstanding issue I see is comment 31 which doesn't seem to be Darwin specific. Jack
(In reply to comment #31) > When configuring with --with-system-libunwind, GCC should not include > unwind-compat.o (or any unwind code) in the build of libgcc_s. Then the > configure check will work correctly. > Steve, Does this problem merit a P1 blocker status? For that specific issue, can't we downgrade this bug report to P2? Is it essential that --with-system-libunwind work in gcc 4.2.0 or could that just be retargeted for gcc 4.2.1? Jack
libgcc_s.10.5.dylib now includes __Unwind_GetIPInfo on mainline and in 4.2...
I think a non-working --with-system-libunwind corner case on darwin is a P4 at best?
Mike, Why don't you close this report as RESOLVED and create another one just for the non-working --with-system-libunwind issue as a P4. That might help prevent folks from constantly reopening this PR as a P1. Jack
Closing for now.