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

[Rich Felker <dalias@libc.org>]

On Mon, May 11, 2015 at 12:31:51PM +0200, Jakub Jelinek wrote:
> On Mon, May 11, 2015 at 11:20:15AM +0100, Szabolcs Nagy wrote:
> > 
> > 
> > On 09/05/15 19:57, Szabolcs Nagy wrote:
> > > * H.J. Lu <hjl.tools@gmail.com> [2015-05-09 10:41:41 -0700]:
> > >> There are
> > >>
> > >>      4: 0000000000002b70   806 FUNC    GLOBAL DEFAULT   12
> > >> __cpu_indicator_init@GCC_4.8.0
> > >>     38: 00000000002153d0    16 OBJECT  GLOBAL DEFAULT   25 __cpu_model@GCC_4.8.0
> > >>
> > >> and
> > >>
> > >> 000000000215000  0000000400000001 R_X86_64_64
> > >> 0000000000002b70 __cpu_indicator_init@GCC_4.8.0 + 0
> > >> 0000000000215220  0000002600000006 R_X86_64_GLOB_DAT
> > >> 00000000002153d0 __cpu_model@GCC_4.8.0 + 0
> > >>
> > >> in libgcc_s.so.1.  Musl ld.so must be fixed to handle it.
> > >>
> > 
> > Rich is looking at how to do this non-intrusively, but
> > it seems non-trivial (some users of musl prefer not to
> > resolve such versioned symbols).
> > 
> > > 
> > > i think it might be enough to add __cpu_indicator_init_local
> > > as an alias to __cpu_indicator_init in libgcc.a and then use
> > > the *_local symbol from the ifunc resolver, that way no new
> > > dependency is added to libgcc_s.so handling.
> > 
> > i tried this approach and it seems to work: passes all
> > multiversioning tests on x86_64.
> > 
> > i think it's no worse than the symver approach.
> > 
> > is it ok to change the current fix to this?
> 
> No.  Instead of piling hacks like this just fix it in musl.

I wouldn't call it piling hacks; it's an improvement as far as I can
tell since it remove symbolic relocations and replaces them with
relative ones.

> libgcc certainly isn't the only library that uses @ symbol versions,
> e.g. libstdc++ does as well, as well as many other shared libraries.

We haven't encountered such issues there.

Rich