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.