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.to...@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.
libgcc certainly isn't the only library that uses @ symbol versions,
e.g. libstdc++ does as well, as well as many other shared libraries.
Jakub
