From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id ABABE38708FA for ; Mon, 7 Sep 2020 13:32:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org ABABE38708FA From: Andreas =?ISO-8859-1?Q?K=2E_H=FCttel?= To: libc-alpha@sourceware.org Subject: RISC-V 64bit and 32bit binaries on the same system Date: Mon, 07 Sep 2020 16:32:39 +0300 Message-ID: <7023981.W097sEU6C4@farino> Organization: Gentoo Linux MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4068302.uqheUzb2qO"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2020 13:32:48 -0000 --nextPart4068302.uqheUzb2qO Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi all,=20 as you probably know, the gcc multilib settings for riscv build and install= 4=20 ABI (rv64/lp64d, rv64/lp64, rv32/ilp32d, rv32/ilp32). Now that rv32 support= is=20 in glibc, I gave this a try (*) in qemu-user.=20 gcc and glibc build and install fine. However, there's a fundamental proble= m=20 with this configuration. ld.so does not filter by ELFCLASS (as it does, e.g= =2E,=20 for x64-64 vs i686), and the order of directories in the dynamic linker con= fig=20 determines e.g. which libstdc++ a binary sees first. [#] Which means, either rv32 or rv64 binaries will terminate with a "wrong=20 ELFCLASS" fatal error. Now, what to do? * Introduce a special cache flag as for x86-64 FLAG_X8664_LIB64? * Make ld.so ignore wrong-ELFCLASS binaries instead of producing an error?= =20 (Same result handled at different point...) * Propose to change the gcc multilib profiles so we don't pretend that this= =20 works? Cheers,=20 Andreas (*) I know that there is no real hardware that can run both rv64 and rv32 a= t=20 the moment. However, it would be useful for me to bootstrap different singl= e- ABI environments. [#] (riscv-main chroot) farino /lib # ldconfig -p|grep c++ libstdc++.so.6 (libc6,double-float) =3D> /usr/lib/gcc/riscv64-unkno= wn- linux-gnu/10.2.0/lib64/lp64d/libstdc++.so.6 libstdc++.so.6 (libc6,double-float) =3D> /usr/lib/gcc/riscv64-unkno= wn- linux-gnu/10.2.0/lib32/ilp32d/libstdc++.so.6 libstdc++.so.6 (libc6,soft-float) =3D> /usr/lib/gcc/riscv64-unknown- linux-gnu/10.2.0/lib64/lp64/libstdc++.so.6 libstdc++.so.6 (libc6,soft-float) =3D> /usr/lib/gcc/riscv64-unknown- linux-gnu/10.2.0/lib32/ilp32/libstdc++.so.6 libstdc++.so (libc6,double-float) =3D> /usr/lib/gcc/riscv64-unknown- linux-gnu/10.2.0/lib64/lp64d/libstdc++.so libstdc++.so (libc6,double-float) =3D> /usr/lib/gcc/riscv64-unknown- linux-gnu/10.2.0/lib32/ilp32d/libstdc++.so libstdc++.so (libc6,soft-float) =3D> /usr/lib/gcc/riscv64-unknown-l= inux- gnu/10.2.0/lib64/lp64/libstdc++.so libstdc++.so (libc6,soft-float) =3D> /usr/lib/gcc/riscv64-unknown-l= inux- gnu/10.2.0/lib32/ilp32/libstdc++.so versus farino ~ # ldconfig -p |grep c++ libstdc++.so.6 (libc6,x86-64) =3D> /usr/lib/gcc/x86_64-pc-linux-gnu/ 9.3.0/libstdc++.so.6 libstdc++.so.6 (libc6) =3D> /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/= 32/ libstdc++.so.6 libstdc++.so (libc6,x86-64) =3D> /usr/lib/gcc/x86_64-pc-linux-gnu/9= =2E3.0/ libstdc++.so libstdc++.so (libc6) =3D> /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/32/ libstdc++.so libnetcdf_c++.so.4 (libc6,x86-64) =3D> /usr/lib64/libnetcdf_c++.so.4 libnetcdf_c++.so (libc6,x86-64) =3D> /usr/lib64/libnetcdf_c++.so =2D-=20 Andreas K. H=FCttel dilfridge@gentoo.org Gentoo Linux developer=20 (council, qa, toolchain, base-system, perl, libreoffice) --nextPart4068302.uqheUzb2qO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQKTBAABCgB9FiEE50NBr50KpJKM5MK59n+4O2olsAAFAl9WNndfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEU3 NDM0MUFGOUQwQUE0OTI4Q0U0QzJCOUY2N0ZCODNCNkEyNUIwMDAACgkQ9n+4O2ol sACx6A/6AwwIiIOrumhJXwofD+d+1viLPnuTN4TMgTBwUUrNqDhWrl8bSTgjRVrI twLlpvY9A8BQqjpQ6CempNPBl4WyKSB015hSLtmwMhw/twBusdLo9kSeAMaQbE7J 4+A8letwfXdJFyS279uQvvGXI+cmWChGy0WBOFAQxuSXzdjbYqImIf6p07iZoy1Z blA4RMsbm3hKvuAtggRt8eCZQTI39qSmqt2vThZJBvWF1ik0yPxtKBjQsasGeBEx 3raITIC5RaaASdHJk/YX8XzTt5jOtUzxxga0OSxZGQSbWXZi6g/IF+vtM2mXayFi xVfJzGlNRcZiYJUmC2HkbTOuorpoJ2SwoEgEwKTD1C2m+8ipUhKeUPwPQMnGUnoZ b3aBviXfxNM1CYXKs1mhDGcJ5bwMbXM/4UIbLiMgypnLydbQq7cieYEuT0XPZZZe 9SA6WO2ggJeaAojI7vG9CVJGJMz/Bx/tvd26KA8LaKCxCHKpDFYgotp4OW3DHd14 1UtGdnk90PKpimvw73KFEHtBRksyXSHzm/JZrHf1eTZctO6iUQmmnaLTPOM2CFo5 mA6IGJPTKt6c7K7o3c8wwypCZKHVcuEGtnlgo8ENQxVSkdhcgG9R4LI4wAFTg5Bc xOY6hBOzykqq+oKKr3DSD8SUTAa3qwiMcwyr1mGnorytzuqp/HY= =6Ir3 -----END PGP SIGNATURE----- --nextPart4068302.uqheUzb2qO--