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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24561 invoked from network); 26 Sep 2022 16:03:49 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 26 Sep 2022 16:03:49 -0000 Received: (qmail 3354 invoked by uid 550); 26 Sep 2022 16:03:46 -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 3313 invoked from network); 26 Sep 2022 16:03:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1664208213; bh=/iAfn3NAevVh93LmrJwdgxItjMC8Jvm1PJto0JaGcTo=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=US1E9kc3pGAEthjMWvu38jZ5oh8P8Lg2ReyREbBAQkc3PtVL6DGBFraeBgbsWJ69N 20zmvqpuBB9RTSzeekKgBUfLr6r4DtTn0yYoISvBDvAneZwtrAgPuU5f46qqFhEahk anTMk5ZAOC4pkGQEomJaVMvne1cvxyxaLjkdmyNk= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Mon, 26 Sep 2022 18:03:32 +0200 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20220926160332.GB2645@voyager> References: <20220926010339.GA9709@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220926010339.GA9709@brightrain.aerifal.cx> User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:bS77vJpHhxoAqdsiJTvXYJaX+IQLsMDqt3KL5KG3NmPgWzzLQbG jb+zpt8TMe4H5JjwbLzvMhJmG1X06CWcGAreJD4sHxYZDKlDosmnyRMFsOxUh/ZzgpKhw6w z+KRzRPL4//FVx0IEzfDfl+c/K7fPcb9AARovhnrcKQiOYjKbmUZC53wvLsoT/WPQtqzPwW Ma1IxByeJuBIfPBt/LcyQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:Luw4W/fKWoE=:2Qiy2fd8/E6XJUGQsscmIg 3/4NfncP2zOVIw4T6LWZJ9YKF4teMzN5MLBg8MI9UnJ9Gj1Zf//KeC599DeVAAPhzJ9sdl9Gg CGJCSzvEVMTEguDpkT+3YnSsHc+A+PDP2hDExmQR99Q970rUAxVBxI0D5yd64nKReup3CP3W7 gcSMF/uN3sBM6YvtZk5bAGRqH7JLe7mXaNKGEK8njgtLTX7amoIMf1BY35d2DeLZYs4r9qxD+ vfrvFen7KT4eVvUMlnp8kBXREW9b3Swb/PKoEQ1W00p2Hr1q5C3XVRBf4vKHxX/v1ao8AN85s EPwp9O9oDYup1K1gZfYrqxVFVfilAcoYDfL1UsmCJ04ODRI9gumZDAlJF1SgLrZhoWv4dqxyB Kpqz6RcX7dgXoAiHCwZuy4N3IJzhVFU+rvpe9adZr+Ii9rIbscRuAZ7zDax4PdnQ4G8tvbhWU LSg7u4BGCGd3rwZ41kU+W/9ZQWlI4dFpLEQ+K8JPw3/95yOe7Ewz7JSLK/s+DTu/hlnkSexvU EbxZwIlYhrEIkZ5nxUglmrgZjtvDpeqq4M6HhOruGFIDhMnv/FJxfpyJuLWuhbWzEmKDfA/VZ QSvuNN3UlBrPRnIxTlY88+rjdgIVDuIqRMvjTtLxZAtWyv1it98MFt14yvcMwxP5irnq9zbPi xggEzwQI01ItML1I+N2yiBQLzIg7znF+w+uvIEU9irkwAgDmuRsjFbUbyOtbY0Y31fQfFs1Dj 8wA/RqNY1JWCg+/P0jWcDhoLDJONQjP90i+85Jh0V3xn4cY1qTuys+WvH6b4HJGmIBNkEfcla /faZoOKS0OFyR20/fPp5U96r4C6BYBEoUG6rGSuh1qVDFa5tpH92Bj7pBK5JNJNBAHVgIBlai S4ylL/I1MI6+i+PTrpVcyir17hboBfzSrFc8VcBKYI9ixBs7Yc/SVhyjPuLDrQ4I+NW7azaVD 4Zpyx9KNFnKMI8W3bebYv0WxSO90Y3ek78IL7VfgSoY2DsCuCEAds/G53CF3xXLB2CegqhSfF lL9YXztCXSGeuRxFjSJ8jpWE4F88HsIZsX2MzSer46t8ihqeGnZLX2MdiW0aprxQWwhdJxxLJ zlPxpoqwSlTochfgrR97e/ZIzaowA3I3zVJsi/MOn1HxgcnrCFiUSWcS7HAEnXrt5BvuJwqVI zS5oUFBpt8XQueSHw9npQC5/av Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Revisiting LFS64 removal 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=3Dbinutils-gdb.git;a=3Dcommitdiff;h=3Dfe3= 9ffdc202f04397f31557f17170b40bc42b77a) > 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. > 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. Ciao, Markus