[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 26 Sep 2022 12:47:14 -0400
From: Rich Felker <dalias@...c.org>
To: Markus Wichmann <nullplan@....net>
Cc: musl@...ts.openwall.com
Subject: Re: Revisiting LFS64 removal
On Mon, Sep 26, 2022 at 06:03:32PM +0200, Markus Wichmann wrote:
> On Sun, Sep 25, 2022 at 09:03:40PM -0400, Rich Felker wrote:
> > Seeing a recent wrong-fix commit in binutils
> > (https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=fe39ffdc202f04397f31557f17170b40bc42b77a)
> > reminded me of the longstanding "we need to remove LFS64" issue.
> >
>
> Whenever I see stuff like that, it makes me break out in hives. The
> stupidest part is that the commit is adding configure tests, so they
> could just test for the things they want. But no, they test for
> something unrelated and then assume that that has the implications they
> want.
Exactly.
> > I believe the simplest short-term way is probably going to be just
> > having the dynamic linker symbol lookup error path make one final
> > check before bailing out with an error:
> >
> > - If the symbol to lookup ends in "64"..
> > - ..and it's in a hard-coded list of LFS64-compat symbols..
> > - ..and looking up the name with the "64" removed in libc succeeds..
> >
> > Then use the version without the "64" suffix and go on with relocation
> > processing.
> >
>
> Took me a while to figure out what you were trying to do here: You want
> to hide the LFS64 symbols at link-time. At compile-time, the macros
> prevent actual use of those symbols, at link-time, access will fail, but
> the symbols will still be there at dynamic load-time, so existing
> binaries don't break.
>
> Of course, that means that you will have to keep the kludge around for
> the foreseeable future, as even if those symbols are added to
> libgcompat, existing binaries would break if it were removed (since
> existing binaries do not depend on libgcompat), which violates the musl
> ABI stability goals. Oh well, it's not going to be the last bit of
> legacy cruft in the library.
No, that's not the case. ABI stability is only guaranteed for ABIs
that result from use of the public APIs. If you pull in a symbol that
was accidentally exposed by not marking it hidden, or by manually
declaring some glibc-ABI-compat symbol that's not part of the public
API, or anything like that, you get to keep both parts when it breaks.
OTOH if a public API generates a reference to a symbol, then that
symbol is stable ABI.
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.
