On Fri, May 8, 2015 at 4:00 PM, Rich Felker <dal...@libc.org> wrote: > On Fri, Apr 17, 2015 at 05:36:30AM -0700, H.J. Lu wrote: >> On Fri, Apr 17, 2015@4:59 AM, Jakub Jelinek <ja...@redhat.com> wrote: >> > On Fri, Apr 17, 2015 at 04:48:48AM -0700, H.J. Lu wrote: >> >> > I don't like it. Nonshared libgcc is libgcc.a, period. No sense in >> >> > creating yet another library for that. >> >> > So, IMHO beyond making the __cpu* entrypoints compat symbols only (@ >> >> > instead >> >> > of @@ symbol versions) the right fix is simply tweak init_gcc_spec, so >> >> > that >> >> > static_name is always linked in, in the switch combinations that it >> >> > isn't >> >> > right now of course after shared_name rather than before that. >> >> > I thought we've fixed that years ago... >> >> > >> >> >> >> We never pass -lgcc to linker when building C++ DSO: >> >> >> >> /usr/libexec/gcc/x86_64-redhat-linux/4.9.2/collect2 -plugin >> >> /usr/libexec/gcc/x86_64-redhat-linux/4.9.2/liblto_plugin.so >> >> -plugin-opt=/usr/libexec/gcc/x86_64-redhat-linux/4.9.2/lto-wrapper >> >> -plugin-opt=-fresolution=/tmp/ccZC7iqy.res >> >> -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc >> >> -plugin-opt=-pass-through=-lgcc_s --build-id --no-add-needed >> >> --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -shared >> >> /usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../lib64/crti.o >> >> /usr/lib/gcc/x86_64-redhat-linux/4.9.2/crtbeginS.o >> >> -L/usr/lib/gcc/x86_64-redhat-linux/4.9.2 >> >> -L/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../lib64 >> >> -L/lib/../lib64 -L/usr/lib/../lib64 >> >> -L/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../.. x.o -lstdc++ -lm >> >> -lgcc_s -lc -lgcc_s /usr/lib/gcc/x86_64-redhat-linux/4.9.2/crtendS.o >> >> /usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../lib64/crtn.o >> >> [hjl@gnu-32 tmp]$ >> >> >> >> That is why libgcc_nonshared.a is needed. >> > >> > See what I wrote. I think it is a bug that we don't do that, in your case >> > we should pass -lgcc_s -lgcc -lc -lgcc_s -lgcc. >> > Or, if you don't want to change that, as the multi-versioning change is >> > i386/x86_64 only change, just ensure that those targets have >> > t-slibgcc-libgcc in libgcc/config.host and thus behave like most other >> > linux >> > targets where -lgcc is linked in always after -lgcc_s. >> > >> > Jakub >> >> This patch works for me. OK for trunk? >> >> gcc/testsuite/ >> >> PR target/65612 >> * g++.dg/ext/mv18.C: New test. >> * g++.dg/ext/mv19.C: Likewise. >> * g++.dg/ext/mv20.C: Likewise. >> * g++.dg/ext/mv21.C: Likewise. >> * g++.dg/ext/mv22.C: Likewise. >> * g++.dg/ext/mv23.C: Likewise. >> >> libgcc/ >> >> PR target/65612 >> * config.host (tmake_file): Add t-slibgcc-libgcc for Linux/x86. >> * config/i386/cpuinfo.c (__cpu_model): Initialize. >> (__cpu_indicator_init@GCC_4.8.0): New. >> (__cpu_model@GCC_4.8.0): Likewise. >> * config/i386/t-linux (HOST_LIBGCC2_CFLAGS): Add >> -DUSE_ELF_SYMVER. >> >> Thanks. > > This patch seems to be making some trouble for musl's dynamic linker, > which I could go into details on if necessary, but I'm wondering if
It sounds like a bug in musl's dynamic linker. foo@VERSION is visible to ld.so, but invisible to ld. > there's any reason why simple visibility wasn't used if you want to > hide the symbols from the linker. Could you explain the motivation for > doing it this way? Is the intent for libgcc_s.so to refer to its own > internal copy of __cpu_model and __cpu_indicator_init? If so, it seems > wrong to have a relocation referring to them symbolically at all; this > should just be a relative relocation. It is for backward binary compatibility so that the old binaries which have references to libgcc_s.so.1 work with the new libgcc_s.so.1. -- H.J.
