Message ID | 20200402162939.358617-7-alistair.francis@wdc.com |
---|---|
State | Committed |
Headers |
Return-Path: <prvs=35496a5c6=alistair.francis@wdc.com> X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from esa4.hgst.iphmx.com (esa4.hgst.iphmx.com [216.71.154.42]) by sourceware.org (Postfix) with ESMTPS id E3DD5388B803 for <libc-alpha@sourceware.org>; Thu, 2 Apr 2020 16:37:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E3DD5388B803 IronPort-SDR: 6IaA41idLyXUxUeJnI09DGscXh+7OH/DP+dVd2S5GYQj/D34S5WDQ59q8TkK/ytrAS2Mqfv4Vd 9psnd2MVosDlv1qHa6o5lsDap5qUl3dvNn7p3eKQkJ58a9gmcJ1UC3fqf+hsFQCJNIMH4c0p7b S8yZ4061PGMBLAoXQWvnpg9e4LbJWYPwKHlmog6EPH8hRgBMiL285Ba0Y4eGeJirf0EHnIFYUR NIwsNgUqRoMw5s4X7r7C15DNVvk6RkL6NyshnPveIbyZ11H+NLu+ptHc0UXVmeYVvgj1oTS/j3 RGU= X-IronPort-AV: E=Sophos;i="5.72,336,1580745600"; d="scan'208";a="134426331" Received: from uls-op-cesaip02.wdc.com (HELO uls-op-cesaep02.wdc.com) ([199.255.45.15]) by ob1.hgst.iphmx.com with ESMTP; 03 Apr 2020 00:37:26 +0800 IronPort-SDR: m0F02wZ2PvH84zzQfd7fA7vhwLdrceBmCijUs4C4aSaqfcE19kVMsUO+M7VdFL+Y6OJoSt0n95 cemmZPjR+mJW6fZYNlTR+tIL6bs6S2VVO7+v6o5Jrb8mDg+pZgSLYxZPoGCoZEMO/0BR2nsZ2E cia02U8KBS9IvgsUf2dFn75F435cKBqlk9V6HIY/H0hGgD3jkqnTKRxO3KOhXb1K438Ot5PpKG WXsBM1FhrnN2mUwxOg3EBvz8iIL3f1sW5q2Pzffy+OO7H4Nuev/JV+u+/5aLBqyojIkaoqBvF9 HH6SPBhp2uILzkTvllg2j8zE Received: from uls-op-cesaip02.wdc.com ([10.248.3.37]) by uls-op-cesaep02.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Apr 2020 09:28:18 -0700 IronPort-SDR: sLbzi1klEZjLkxr/Am5h+RCddpaSbDqaF+tNfX/dzjx6z2u1eodt49eYDme77Yw/DrUfg6Vxkl dRKjp5/nl8h6+3/PgXF5BveA92bXMK1b/RAvIwGe22z7Pru1PJQsMWIiTXdXupLea7CwtZpGpU G+s4WkZtZVvJjrYfpsWYdD5VSt1cC4Tua5b8yjZeGc/9IzSaZYgvZG0LzWiPysCN1rUpoHZQhI N0vJMmtjw14FLno8tUKoIwZBbIXnvhUEv2eyIqsyEOwEH1oR7g04HGmE6sPI3C8N6/N02ZQW44 aM4= WDCIronportException: Internal Received: from phd004806.ad.shared (HELO risc6-mainframe.hgst.com) ([10.86.55.43]) by uls-op-cesaip02.wdc.com with ESMTP; 02 Apr 2020 09:37:26 -0700 From: Alistair Francis <alistair.francis@wdc.com> To: libc-alpha@sourceware.org Cc: alistair23@gmail.com, Zong Li <zongbox@gmail.com> Subject: [PATCH 06/18] RISC-V: Add path of library directories for the 32-bit Date: Thu, 2 Apr 2020 09:29:36 -0700 Message-Id: <20200402162939.358617-7-alistair.francis@wdc.com> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200402162939.358617-1-alistair.francis@wdc.com> References: <20200402162939.358617-1-alistair.francis@wdc.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-26.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_HELO_NONE, 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 <libc-alpha.sourceware.org> List-Unsubscribe: <http://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <http://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> X-List-Received-Date: Thu, 02 Apr 2020 16:37:34 -0000 |
Series |
glibc port for 32-bit RISC-V (RV32)
|
|
Commit Message
Alistair Francis
April 2, 2020, 4:29 p.m. UTC
From: Zong Li <zongbox@gmail.com>
For the recommand of 64 bit version, we add the libraries path of 32 bit
in this patch.
The status of RV32 binaries under RV64 kernels is that the ISA
optionally supports having different XLEN for user and supervisor modes,
but AFAIK there's no silicon that implements this feature, and the Linux
kernel doesn't support it yet.
For the recommand of 64 bit version, we add the libraries path of 32 bit
in this patch. This includes a fix to avoid an out of bound array check
when building with GCC 8.2.
---
sysdeps/unix/sysv/linux/riscv/dl-cache.h | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
Comments
On Thu, Apr 2, 2020 at 9:38 AM Alistair Francis via Libc-alpha <libc-alpha@sourceware.org> wrote: > diff --git a/sysdeps/unix/sysv/linux/riscv/dl-cache.h b/sysdeps/unix/sysv/linux/riscv/dl-cache.h > index c297dfe84f..60fc172edb 100644 > --- a/sysdeps/unix/sysv/linux/riscv/dl-cache.h > +++ b/sysdeps/unix/sysv/linux/riscv/dl-cache.h > @@ -34,6 +34,8 @@ > RISC-V, libraries can be found in paths ending in: > - /lib64/lp64d > - /lib64/lp64 > + - /lib32/ilp32d > + - /lib32/ilp32 > - /lib (only ld.so) > so this will add all of those paths. > FYI This reminds me of something. I was forwarded a complaint that the RISC-V ABI was violating the Filesystem Hierarchy Standard (FHS), which specifies that libraries are only allowed to be in /lib and /lib<qual>. The complaint was that /lib64/lp64d doesn't follow this pattern, and hence is a violation of this standard. However, the standard doesn't clearly state that <qual> can't contain a slash. The person who complained insisted that it was implied. It wasn't clear to me what to do with the complaint. Changing the ABI now would be rather disruptive and undesirable, and I also don't know how important the FHS standard is, or whether this interpretation is correct. http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html Jim
On Thu, Apr 2, 2020 at 2:49 PM Jim Wilson <jimw@sifive.com> wrote: > > On Thu, Apr 2, 2020 at 9:38 AM Alistair Francis via Libc-alpha > <libc-alpha@sourceware.org> wrote: > > diff --git a/sysdeps/unix/sysv/linux/riscv/dl-cache.h b/sysdeps/unix/sysv/linux/riscv/dl-cache.h > > index c297dfe84f..60fc172edb 100644 > > --- a/sysdeps/unix/sysv/linux/riscv/dl-cache.h > > +++ b/sysdeps/unix/sysv/linux/riscv/dl-cache.h > > @@ -34,6 +34,8 @@ > > RISC-V, libraries can be found in paths ending in: > > - /lib64/lp64d > > - /lib64/lp64 > > + - /lib32/ilp32d > > + - /lib32/ilp32 > > - /lib (only ld.so) > > so this will add all of those paths. > > > > FYI This reminds me of something. I was forwarded a complaint that > the RISC-V ABI was violating the Filesystem Hierarchy Standard (FHS), > which specifies that libraries are only allowed to be in /lib and > /lib<qual>. The complaint was that /lib64/lp64d doesn't follow this > pattern, and hence is a violation of this standard. However, the > standard doesn't clearly state that <qual> can't contain a slash. The > person who complained insisted that it was implied. It wasn't clear > to me what to do with the complaint. Changing the ABI now would be > rather disruptive and undesirable, and I also don't know how important > the FHS standard is, or whether this interpretation is correct. Hmm.... Ideally I would prefer to do the same as RV64, it seems simpler. If it is explicitly against the standard though then I think it makes sense to fix it for RV32 now though. It does seem to imply that <qual> shouldn't contain a slash, but it's not stated (as you mentioned). As it's not against the spec I'm thinking we leave it as is unless anyone else objects? Alistair > > http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html > > Jim
On Thu, Apr 2, 2020 at 4:05 PM Alistair Francis <alistair23@gmail.com> wrote: > Ideally I would prefer to do the same as RV64, it seems simpler. If it > is explicitly against the standard though then I think it makes sense > to fix it for RV32 now though. I would prefer to follow the existing scheme also. If you change the rv32 glibc paths, then you will also need changes to gcc and binutils at least, and maybe also to other stuff, as these paths are already hard wired into those tools. Maybe the FHS can be fixed to allow these paths? If <qual> isn't allowed to contain a /, then it seems that debian and ubuntu are already violating it with the multiarch support which puts libraries in /lib/x86_64-linux-gnu/ for instance, but maybe they don't care, or maybe this non-slash interpretation is wrong. Though researching that a bit, I found this https://www.debian.org/doc/debian-policy/ch-opersys.html which says they follow FHS with exceptions, one of which is to allow multiarch. Jim
Jim Wilson <jimw@sifive.com> 於 2020年4月3日 週五 上午7:33寫道: > > On Thu, Apr 2, 2020 at 4:05 PM Alistair Francis <alistair23@gmail.com> wrote: > > Ideally I would prefer to do the same as RV64, it seems simpler. If it > > is explicitly against the standard though then I think it makes sense > > to fix it for RV32 now though. > > I would prefer to follow the existing scheme also. If you change the > rv32 glibc paths, then you will also need changes to gcc and binutils > at least, and maybe also to other stuff, as these paths are already > hard wired into those tools. > > Maybe the FHS can be fixed to allow these paths? If <qual> isn't > allowed to contain a /, then it seems that debian and ubuntu are > already violating it with the multiarch support which puts libraries > in /lib/x86_64-linux-gnu/ for instance, but maybe they don't care, or > maybe this non-slash interpretation is wrong. Though researching that > a bit, I found this > https://www.debian.org/doc/debian-policy/ch-opersys.html > which says they follow FHS with exceptions, one of which is to allow multiarch. > > Jim Agree with you. It seems to me that we follow the existing scheme would be better if we didn't really violate the rule, but I'm not sure whether the multiarch exception is applicable to our case.
On Thu, 2 Apr 2020, Jim Wilson wrote: > > diff --git a/sysdeps/unix/sysv/linux/riscv/dl-cache.h b/sysdeps/unix/sysv/linux/riscv/dl-cache.h > > index c297dfe84f..60fc172edb 100644 > > --- a/sysdeps/unix/sysv/linux/riscv/dl-cache.h > > +++ b/sysdeps/unix/sysv/linux/riscv/dl-cache.h > > @@ -34,6 +34,8 @@ > > RISC-V, libraries can be found in paths ending in: > > - /lib64/lp64d > > - /lib64/lp64 > > + - /lib32/ilp32d > > + - /lib32/ilp32 > > - /lib (only ld.so) > > so this will add all of those paths. > > > > FYI This reminds me of something. I was forwarded a complaint that > the RISC-V ABI was violating the Filesystem Hierarchy Standard (FHS), > which specifies that libraries are only allowed to be in /lib and > /lib<qual>. The complaint was that /lib64/lp64d doesn't follow this > pattern, and hence is a violation of this standard. However, the > standard doesn't clearly state that <qual> can't contain a slash. The > person who complained insisted that it was implied. It wasn't clear > to me what to do with the complaint. Changing the ABI now would be > rather disruptive and undesirable, and I also don't know how important > the FHS standard is, or whether this interpretation is correct. Hmm, I wonder if there is actually a technical justification for the flat structure of library directories, e.g. for automatic library processing by some tools based on a flat glob pattern. We have a long-established practice to use subdirectories for libraries, both for multilibs and for hardware capabilities, and it has been considered appropriate, as tree filesystem structures scale better than flat ones (large directories require more time to process their entries). For instance the MIPS64r3 architecture, which has six base ABIs: legacy-NaN-o32, 2008-NaN-o32, legacy-NaN-n32, 2008-NaN-n32, legacy-NaN-n64, 2008-NaN-n64, all of which can coexist and independently run on a single machine, will keep the 2008-NaN variants in a nan2008/ subdirectory of the respective library directories. There are further subdirectories defined for Loongson variants. Then ld.so(8) lists the various hardware capabilities the GNU C library's dynamic loader will use for various platforms as subdirectories to the respective library directories in order to determine the most suitable binary variant of the required library to choose. Unfortunately while the FHS standard does provide a rationale for many of its choices, there does not seem to be one provided for the arrangement of library directories chosen. And the choice made long ago back in 1990s, where a typical Linux platform may have had at most two or maybe three ABIs defined to choose from based merely of the address space size being 32-bit or 64-bit, may no longer be adequate some 20 years later as the world has evolved. Perhaps the choice made long ago for the library locations would best be revisited and any technical justification reevaluated. I would recommend approaching The Linux Foundation, the entity backing the standard, with this problem. Maciej
On Fri, Apr 3, 2020 at 9:02 AM Maciej W. Rozycki <macro@wdc.com> wrote: > Perhaps the choice made long ago for the library locations would best be > revisited and any technical justification reevaluated. I would recommend > approaching The Linux Foundation, the entity backing the standard, with > this problem. Thanks for the MIPS examples. I sent email to fhs-discuss to start a discussion there. Jim
diff --git a/sysdeps/unix/sysv/linux/riscv/dl-cache.h b/sysdeps/unix/sysv/linux/riscv/dl-cache.h index c297dfe84f..60fc172edb 100644 --- a/sysdeps/unix/sysv/linux/riscv/dl-cache.h +++ b/sysdeps/unix/sysv/linux/riscv/dl-cache.h @@ -34,6 +34,8 @@ RISC-V, libraries can be found in paths ending in: - /lib64/lp64d - /lib64/lp64 + - /lib32/ilp32d + - /lib32/ilp32 - /lib (only ld.so) so this will add all of those paths. @@ -49,9 +51,16 @@ do \ { \ size_t len = strlen (dir); \ - char path[len + 9]; \ + char path[len + 10]; \ memcpy (path, dir, len + 1); \ - if (len >= 12 && ! memcmp(path + len - 12, "/lib64/lp64d", 12)) \ + if (len >= 13 && ! memcmp(path + len - 13, "/lib32/ilp32d", 13)) \ + { \ + len -= 9; \ + path[len] = '\0'; \ + } \ + if (len >= 12 \ + && (! memcmp(path + len - 12, "/lib32/ilp32", 12) \ + || ! memcmp(path + len - 12, "/lib64/lp64d", 12))) \ { \ len -= 8; \ path[len] = '\0'; \ @@ -64,6 +73,10 @@ add_dir (path); \ if (len >= 4 && ! memcmp(path + len - 4, "/lib", 4)) \ { \ + memcpy (path + len, "32/ilp32d", 10); \ + add_dir (path); \ + memcpy (path + len, "32/ilp32", 9); \ + add_dir (path); \ memcpy (path + len, "64/lp64d", 9); \ add_dir (path); \ memcpy (path + len, "64/lp64", 8); \