From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id E457F3858C53 for ; Sun, 17 Jul 2022 13:58:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E457F3858C53 From: "Andreas K. Huettel" To: Palmer Dabbelt , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Revert "[PATCH] RISC-V: Use new linker emulations for glibc ABI." Date: Sun, 17 Jul 2022 15:57:39 +0200 Message-ID: <3183556.44csPzL39Z@pinacolada> Organization: Gentoo Linux In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8089216.T7Z3S40VBb"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2022 13:58:17 -0000 --nextPart8089216.T7Z3S40VBb Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; protected-headers="v1" From: "Andreas K. Huettel" To: Palmer Dabbelt , gcc-patches@gcc.gnu.org Date: Sun, 17 Jul 2022 15:57:39 +0200 Message-ID: <3183556.44csPzL39Z@pinacolada> Organization: Gentoo Linux References: MIME-Version: 1.0 > I'm kind of torn on this one: this has been around for a while and=20 > dropping it would be an ABI break, but the feedback from distro folks is= =20 > pretty consistently that multlib is broken on RISC-V. If it's really=20 > unusably broken then I could buy the argument that there's no binaries=20 > (and thus no ABI to break), but there's at some base multilib=20 > functionality working -- I build multilib cross toolchains regularly,=20 > for example, and they can build simple stuff. So as the one who initially bootstrapped rv64 for Gentoo in full multilib=20 mode... 1) Multilib works in principle. 2) The main problem with the lib64/lp64d etc paths is that software authors out there assume that the "libdir" is a single-depth directory.=20 In Gentoo specifically, "normally" $(get_libdir) echos "lib64" and people assume that "$(get_libdir)/../" ends up at a specific location. Now if=20 $(get_libdir) echos "lib64/lp64" ... That is not limited to the Gentoo side though. 3) The second problem is that binary-distributed software, built for non-multilib lp64d (hey, rust, I'm talking of you), of course use "lib64" and not "lib64/lp64d". 4) The third problem (more of an oddity) is that for rv32 the non-multilib fallback for the "lib32/ilp32d" directories is not "lib32" but "lib". With incompatible changes some time ago (the 17.0 to 20.0 profile change),= =20 2) and 3) was "fixed" in Gentoo (where we officially only do rv64 so far because usermode qemu-riscv32 is b0rk b0rk b0rk). What I did: * The main ABI (normally lp64d) was moved to lib64 https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/multilib.eclass#n419 * Compat symlinks, e.g. /usr/lib64/lp64d -> . were installed. This=20 * *mostly* solves 2) because only a small subset of libraries is installed for the non-default ABI,=20 * and solves 3) because the default ABI is in the fallback non-multilib location (but also accessible via the symlink if something insists). https://gentoo.osuosl.org/releases/riscv/autobuilds/ Given these hacks, our multilib stages are not linked on the website,=20 but they are built just fine and should work just fine. Feel free to try in a chroot / with qemu / ... > I always find making that "nobody's used it" argument really hard,=20 > there's just too many users to try and track everyone down. We're in=20 > kind of a weird spot with RISC-V in general when it comes to ABI stuff:=20 > we were probably a bit overly optimistic about how fast any of this was=20 > going to get used when we committed to the ABI freeze, but any ABi break= =20 > has such a huge potential for user headaches that I'm not sure it's=20 > going to be possible. It means we're stuck with some baggage, and while= =20 > it's a headache to keep around stuff that's probably not all that useful= =20 > I think it's just what we've got to live with. =2D-=20 Andreas K. H=FCttel dilfridge@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) --nextPart8089216.T7Z3S40VBb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQKTBAABCgB9FiEE6W4INB9YeKX6Qpi1TEn3nlTQogYFAmLUFVNfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEU5 NkUwODM0MUY1ODc4QTVGQTQyOThCNTRDNDlGNzlFNTREMEEyMDYACgkQTEn3nlTQ ogYQYQ/8D2iS5royRcV+9I6kGD3N+J1wUzIOvG2BwSzuLqn2NSkgs7Dt8SFuC+Zj R8YVWa4grGmuw7yUTQjug56oMOrye/pZeNLmYNRSk7dnW6hIrL9a7SGmUlTMT9ee EBX1vT55WiEguYXqaq9XmBb4fVnh195tP31w1OvHs+hTfQArfNh6qLpIeGbihYVy 1YUc1u3ox7JZeKCWUlPr22qEqu0cbX0q1eSP27k4uQ0+P9QKMT63153ohm+NfwU0 gMlClKWzdkMc59S/mzyzrbOhL6KDBJJRhGmzhx1Lfyc+jsf1+ISXu+fsaPlb6RZP gUi7Be878/t7V/F8Z/ZUZY05za3BZWQEQvn6A0KWAXENjsYZkzADkS4/+3d8POGJ IYzpkCvAbEJcaVgA0GM2tVCYnujXeQQxOoSZsIShi/SqVU/XuTL5ebQ6RSyL77sj 4x+ispkF28xKvyqcGSnL71yDx4X6j7Iq2a2ZCFmu7Q76q0fRlZblaplabxszOE11 dWNVDv2qbPUOdoC0m9P3/oTckLCWmPkvjgQGWiMxRkDrb6zgZ961u5RG7wIdGSvq axmWPYd6rmP5sind8OVDXuc8kD+/mjDWaXg2gj4B+bKVA/RxJ/DYu2sB4aemUAF4 uwE/mkCzS2eoiTN8QV9agcDHqDJhlrjFpF822J1EB47lmpoz7Mg= =CiA3 -----END PGP SIGNATURE----- --nextPart8089216.T7Z3S40VBb--