[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150528171241.GT17573@brightrain.aerifal.cx>
Date: Thu, 28 May 2015 13:12:41 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Progress since 1.1.9
On Thu, May 28, 2015 at 01:45:15PM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@...c.org> [2015-05-27 19:13:08 -0400]:
> > The one roadmap item I don't have any progress on is what to do with
> > the libgcc_s symbol version mess, and I think we should probably just
> > hold off until the next release cycle for that now.
>
> in case anyone wonders about the issue:
>
> libgcc_s has a symbolic reference to an internal deprecated
> symbol with no default version on x86 (in gcc trunk).
> (so no @version only @@version which makes it invisible to
> musl and ld).
>
> the deprecated function is a constructor in libgcc_s that
> initializes an unused struct in libgcc_s.
>
> the only reason the symbol got versioned this way is because
> they want old binaries to work and remove the symbol from
> libgcc_s for new binaries, while still using the same symbol
> name in new binaries but with different abi behaviour: now
> it's only available in libgcc.a to fix their ifunc hack for
> multi-versioning.
>
> since it's a symbol internal to libgcc and the semantics
> of the symbol changed they could have just used a new name
> and left the old one alone (so old stuff is guaranteed to not
> break including musl and new binaries use the new symbol with
> new semantics).
Yes but if the new symbol is not linkable like they made it, then old
musl-linked binaries depending on getting it from libgcc_s would fail
to find it at dynamic-link time and error out. I don't know whether
this can happen without use of the multiversioning feature, though,
which would not have worked with musl anyway since we don't have
ifunc.
> so i still think my proposed libgcc patch makes more sense
> than versioning:
> https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00899.html
>
> gcc is unlikely to fix this, but this is a nonsense usecase
> (and there is no other known use of versioning that is broken
> with musl.. in theory other libs may deprecate symbols in a
> similar way while still keeping symbolic references to them,
> but such use was not yet observed).
Are you sure? have you tried building C++ programs with gcc 3.x or 4.2
then using a libstdc++ from recent gcc? Unless the soname is
different, I suspect they're using symbol versions to make it "work"
and it will probably break catastrophically.
> in musl-gcc it can be worked around by preloading a noop
> __cpu_indicator_init and in a musl based gcc it can be
> patched out.
But it sounds like that patch will be unacceptable for upstream. There
are alternatives we could do, like providing in musl a list of useless
symbols to ignore (resolve to a nop func or a dummy data symbol) if
they're not found, but these are all a bit hackish and I worry more
stuff with symbol versioning will come back to bite us in the future.
The other option would be to teach gcc and binutils that musl does not
support symbol versions, but I worry that might break even more things
that expect versions to be available on Linux but that work fine with
musl's current dummying-out of version matching.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
