From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30027 invoked from network); 26 Sep 2022 16:47:30 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 26 Sep 2022 16:47:30 -0000 Received: (qmail 30620 invoked by uid 550); 26 Sep 2022 16:47:28 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 30588 invoked from network); 26 Sep 2022 16:47:27 -0000 Date: Mon, 26 Sep 2022 12:47:14 -0400 From: Rich Felker To: Markus Wichmann Cc: musl@lists.openwall.com Message-ID: <20220926164713.GD9709@brightrain.aerifal.cx> References: <20220926010339.GA9709@brightrain.aerifal.cx> <20220926160332.GB2645@voyager> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220926160332.GB2645@voyager> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] 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