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.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.
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
