On Sat, May 09, 2015 at 10:41:41AM -0700, H.J. Lu wrote: > On Sat, May 9, 2015 at 7:31 AM, Szabolcs Nagy <n...@port70.net> wrote: > > * H.J. Lu <hjl.to...@gmail.com> [2015-04-17 05:36:30 -0700]: > >> On Fri, Apr 17, 2015 at 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... > >> >> > > > > > I think the patch committed for this is suboptimal. > > (it breaks with musl libc on x86 if libgcc_s is linked into a binary) > > > > the patch: > > http://gcc.gnu.org/ml/gcc-patches/2015-04/msg00878.html > > original thread: > > http://gcc.gnu.org/ml/gcc-patches/2015-03/msg01520.html > > > > The symbol versioning hack for __cpu_model and __cpu_indicator_init > > makes them invisible to the musl dynamic linker so their relocation > > fails with 'symbol not found' error. > > (affects anything linked with -lgcc_s) > > 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.
The intent in musl was always not to support symbol versioning. There are various reasons for this, which I could go into, but I'd rather not turn this thread into an argument about the merits of symbol versioning. Originally, musl ignored the version data completely, and would happily have resolved the above symbol, but this also led to problems where third-party libraries used symbol versioning and at runtime we got the oldest-versioned symbol instead of the desired current one. So I changed the lookup to use the same logic as ld, rejecting all symbols with the hidden bit set, and getting us the newest one (which is the only one we intended to support). We can't just do the same version processing as glibc because we want symbols in libc itself to resolve regardless of the version in the reference (this is needed for the glibc ABI compat we provide). It might work to honor symbol versions only when the library being searched has versions, and otherwise allow symbols to match any version requested, but I haven't thought this through entirely yet. In any case I'd like the decision for what musl does about symbol versions (which are not intended to be supported, anyway) to be independent of libgcc's solution of this problem. We can solve it with a hack on our side (just providing dummy symbols by those names) but that's ugly too and I'd rather not do it. Could you clarify the reasoning for why libgcc is using this hack with a reference to an 'obsolete' symbol version rather than just visibility? Rich
