Il 17/01/2014 15:21, Rainer Orth ha scritto: > As described in the PR, the 64-bit Solaris 10+/x86 libc contains an > implementation of those _Unwind_* functions required by the AMD64 ABI, > i.e. those contained in libgcc_s.so.1 at version GCC_3.0. > > If by some circumstance (use of -Bdirect, -z lazyload, maybe others) > libc.so.1 happens to be searched by ld.so.1 before libgcc_s.so.1 and > some library (e.g. libstdc++.so.6) uses functions both from GCC_3.0 > (then resolved from libc.so.1) and others (resolved from libgcc_s.so.1), > crashes result due to mixing those different implementations with > different internal data structures. > > To avoid this, I suggest linking libgcc_s.so.1 with a mapfile that > enforces direct binding to the libgcc_s.so.1 implementation to avoid > that mixture. > > The following patch does just that. Initially, I tried to only use the > mapfile when -lgcc_s is used, but libtool often links shared objects > with -shared -nostdlib, adding -lgcc_s -lc -lgcc_s itself (for whatever > reason it deems appropriate to second-guess the compiler driver here). > Therefore I'm keying the mapfile use off -shared resp. -shared-libgcc > instead. > > Unfortunately, the patch needs a change to the bundled ltmain.sh: by > default, libtool `optimizes' -lgcc_s -lc -lgcc_s into -lc -lgcc_s. > Combined with direct binding, this lead to exactly the failure the patch > intends to avoid. The libtool bug has already been reported and a patch > proposed: > > http://lists.gnu.org/archive/html/libtool-patches/2014-01/msg00005.html > > The patch has been tested on i386-pc-solaris2.{9,10,11} and > sparc-sun-solaris2.{9,10,11} with Sun as/ld and on i386-pc-solaris2.10 > with Sun as/GNU ld. > > I don't need approval for the Solaris specific parts, but another pair > of eyes would certainly be helpful. > > One potential issue would be a version of gcc containing the patch used > with a libtool without the change. The last libtool release was almost > two years ago, so this is quite a likely condition. Fortunately, > problems would only ensure if some 64-bit Solaris/x86 program/library > uses the gcc extensions to the AMD64 unwinder. According to a code > search, uses of those functions are very rare outside of gcc, and the > problem can be worked around by invoking libtool with > --preserve-dup-deps, so I consider this risk acceptable. > > Rainer > > > 2014-01-14 Rainer Orth <r...@cebitec.uni-bielefeld.de> > > gcc: > PR target/59788 > * config/sol2.h (LINK_LIBGCC_MAPFILE_SPEC): Define. > (LINK_SPEC): Use it for -shared, -shared-libgcc. > > libgcc: > PR target/59788 > * config/t-slibgcc-sld (libgcc-unwind.map): New target. > (install-libgcc-unwind-map-forbuild): New target. > (all): Depend on install-libgcc-unwind-map-forbuild. > (install-libgcc-unwind-map): New target. > (install): Depend on install-libgcc-unwind-map. > > gcc/testsuite: > PR target/59788 > * g++.dg/eh/unwind-direct.C: New test. > > libgo: > PR target/59788 > * config/ltmain.sh (opt_duplicate_compiler_generated_deps): Enable on > *solaris2*. > > toplevel: > PR target/59788 > * ltmain.sh (opt_duplicate_compiler_generated_deps): Enable on > *solaris2*. > > > >
Thanks for getting the patch upstream! Paolo
