http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59788
Bug ID: 59788 Summary: Mixing libc and libgcc_s unwinders on 64-bit Solaris 10+/x86 breaks EH Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: ro at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Host: i386-pc-solaris2.1[01] Target: i386-pc-solaris2.1[01] Build: i386-pc-solaris2.1[01] I've received a few reports in private mail that exception handling on 64-bit Solaris 10+/x86 is broken when linking with -Bdirect. The following testcase shows this: $ cat unwind-direct.cc #include <stdexcept> int main(void) { try { throw std::runtime_error( "Catch me if you can!"); } catch(...) { return 0; } return 1; } $ g++ -Wl,-Bdirect -m64 -o unwind-direct unwind-direct.cc $ ./unwind-direct terminate called after throwing an instance of 'std::runtime_error' Segmentation Fault (core dumped) Investigating this with LD_DEBUG=bindings, one finds $ LD_DEBUG=bindings ./unwind-direct 2>&1 | grep Unwind 03243: 1: binding file=../../../i386-pc-solaris2.11/amd64/libstdc++-v3/src/.libs/libstdc++.so.6 to file=/lib/64/libc.so.1: symbol '_Unwind_RaiseException' 03243: 1: binding file=../../../i386-pc-solaris2.11/amd64/libstdc++-v3/src/.libs/libstdc++.so.6 to file=/lib/64/libc.so.1: symbol '_Unwind_GetLanguageSpecificData' 03243: 1: binding file=../../../i386-pc-solaris2.11/amd64/libstdc++-v3/src/.libs/libstdc++.so.6 to file=/lib/64/libc.so.1: symbol '_Unwind_GetRegionStart' 03243: 1: binding file=../../../i386-pc-solaris2.11/amd64/libstdc++-v3/src/.libs/libstdc++.so.6 to file=../../amd64/libgcc_s.so.1: symbol '_Unwind_GetIPInfo' 03243: 1: binding file=../../../i386-pc-solaris2.11/amd64/libstdc++-v3/src/.libs/libstdc++.so.6 to file=../../amd64/libgcc_s.so.1: symbol '_Unwind_Resume_or_Rethrow' 03243: 1: binding file=../../amd64/libgcc_s.so.1 to file=/lib/64/libc.so.1: symbol '_Unwind_RaiseException' The problem is that the amd64 Solaris 10+ libc contains an implementation of the amd64 unwinder, as prescribed by the amd64 ABI, but only those functions that are listed there. libgcc_s contains some more, and both implementations use different internal datastructures, so mixing them wreaks havoc. This problem has been seen several times during gcc development when it affected gcc runtime libraries. I'm working on a patch to avoid this once and for all by forcing all gcc-built executables to bind to the unwinder in libgcc_s. Rainer