[06/18] RISC-V: Add path of library directories for the 32-bit

  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(-)
  

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