Re: [build, libgcc] Ensure libgcc_s unwinder is always used on 64-bit Solaris 10+/x86 (PR target/59788)
"Joseph S. Myers" writes: > On Tue, 4 Feb 2014, Rainer Orth wrote: > >> > The patch to libgo/ltmain.sh is now committed to mainline. >> >> I've now committed the rest, thanks. >> >> Btw., what's the procedure for syncing the toplevel ltmain.sh these >> days? AFAIK there's both the old CVS src repo as well as the new >> binutils-gdb git repo. Does the patch need to go to both? > > Yes, shared files and directories should be kept in sync between all three > repositories (the src repository is still used for newlib). It looks like > some (e.g. configure.ac) have been getting out of sync lately. Committed to both now. Thanks for the info. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [build, libgcc] Ensure libgcc_s unwinder is always used on 64-bit Solaris 10+/x86 (PR target/59788)
On Tue, 4 Feb 2014, Rainer Orth wrote: > > The patch to libgo/ltmain.sh is now committed to mainline. > > I've now committed the rest, thanks. > > Btw., what's the procedure for syncing the toplevel ltmain.sh these > days? AFAIK there's both the old CVS src repo as well as the new > binutils-gdb git repo. Does the patch need to go to both? Yes, shared files and directories should be kept in sync between all three repositories (the src repository is still used for newlib). It looks like some (e.g. configure.ac) have been getting out of sync lately. -- Joseph S. Myers jos...@codesourcery.com
Re: [build, libgcc] Ensure libgcc_s unwinder is always used on 64-bit Solaris 10+/x86 (PR target/59788)
Ian Lance Taylor writes: >> Could you please take care of that, provided the RMs approve? The patch >> was ok two weeks ago and is completely Solaris-specific, so I'd like to >> get it into the 4.9.0 release. > > I was just waiting for you to commit it elsewhere. And I was waiting for you to commit the libgo part since doing it the other way round would have broken the amd64 libgo. > The patch to libgo/ltmain.sh is now committed to mainline. I've now committed the rest, thanks. Btw., what's the procedure for syncing the toplevel ltmain.sh these days? AFAIK there's both the old CVS src repo as well as the new binutils-gdb git repo. Does the patch need to go to both? Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [build, libgcc] Ensure libgcc_s unwinder is always used on 64-bit Solaris 10+/x86 (PR target/59788)
On Mon, Feb 3, 2014 at 2:55 AM, Rainer Orth wrote: > Ian Lance Taylor writes: > >> On Mon, Jan 20, 2014 at 4:29 AM, Rainer Orth >> wrote: >>> >>> Given that there were no other comments, I'd like to install the patch >>> now. Ian, could you please install the ltmain.sh patch in libgo/config, >>> or should I do so myself? >> >> I'll do it. Thanks. > > Could you please take care of that, provided the RMs approve? The patch > was ok two weeks ago and is completely Solaris-specific, so I'd like to > get it into the 4.9.0 release. I was just waiting for you to commit it elsewhere. The patch to libgo/ltmain.sh is now committed to mainline. Ian
Re: [build, libgcc] Ensure libgcc_s unwinder is always used on 64-bit Solaris 10+/x86 (PR target/59788)
Ian Lance Taylor writes: > On Mon, Jan 20, 2014 at 4:29 AM, Rainer Orth > wrote: >> >> Given that there were no other comments, I'd like to install the patch >> now. Ian, could you please install the ltmain.sh patch in libgo/config, >> or should I do so myself? > > I'll do it. Thanks. Could you please take care of that, provided the RMs approve? The patch was ok two weeks ago and is completely Solaris-specific, so I'd like to get it into the 4.9.0 release. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [build, libgcc] Ensure libgcc_s unwinder is always used on 64-bit Solaris 10+/x86 (PR target/59788)
On Mon, Jan 20, 2014 at 4:29 AM, Rainer Orth wrote: > > Given that there were no other comments, I'd like to install the patch > now. Ian, could you please install the ltmain.sh patch in libgo/config, > or should I do so myself? I'll do it. Thanks. Ian
Re: [build, libgcc] Ensure libgcc_s unwinder is always used on 64-bit Solaris 10+/x86 (PR target/59788)
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/msg5.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
>
> 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
Re: [build, libgcc] Ensure libgcc_s unwinder is always used on 64-bit Solaris 10+/x86 (PR target/59788)
Rainer Orth writes: > 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/msg5.html The patch has been accepted upstream now. > I don't need approval for the Solaris specific parts, but another pair > of eyes would certainly be helpful. Given that there were no other comments, I'd like to install the patch now. Ian, could you please install the ltmain.sh patch in libgo/config, or should I do so myself? Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
