PATCH] PR target/65612: Multiversioning doesn't work with DSO nor PIE

[Rich Felker]

On Fri, Apr 17, 2015 at 05:36:30AM -0700, H.J. Lu wrote:
> On Fri, Apr 17, 2015@4:59 AM, Jakub Jelinek <jakub@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
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.

Rich