Re: [PATCH 2/6] RISC-V Port: gcc

[Karsten Merker <merker@debian.org>]

On Mon, Jan 16, 2017 at 09:37:15PM -0800, Palmer Dabbelt wrote:
> On Sat, 14 Jan 2017 02:05:27 PST (-0800), merker@debian.org wrote:
> > Palmer Dabbelt wrote:
> >
> >> diff --git a/gcc/config/riscv/linux.h b/gcc/config/riscv/linux.h
> >> new file mode 100644
> >> index 0000000..045f6cc
> >> --- /dev/null
> >> +++ b/gcc/config/riscv/linux.h
> >> [...]
> >>  +#define GLIBC_DYNAMIC_LINKER "/lib" XLEN_SPEC "/" ABI_SPEC "/ld.so.1"
> >
> > [with XLEN_SPEC being either 32 or 64 and ABI_SPEC being one of
> >  ilp32, ilp32f, ilp32d, lp64, lp64f, lp64d]
[...]
> > I am not fully happy with the way the dynamic linker path (which
> > gets embedded into every Linux executable built by gcc and
> > therefore cannot be changed later) is defined here.  The dynamic
> > linker path must be unique over all platforms for which a Linux
> > port exists to make multiarch installations (i.e. having
> > dynamically linked binaries for multiple architectures/ABIs in
> > the same root filesystem) possible.  The path specifier as cited
> > above contains nothing that makes the linker path inherently
> > specific to RISC-V.  While there is AFAIK no other architecture
> > that currently uses exactly this specific linker path model with
> > the ABI specifier as a separate subdirectory (instead of encoding
> > it into the filename), so that there technically isn't a naming
> > conflict, I think that we should follow the convention of the
> > other "modern" Linux architectures, which all include the
> > architecture name in their linker path:
> >
> >   * arm64:    /lib/ld-linux-aarch64.so.1
> >   * armhf:    /lib/ld-linux-armhf.so.3
> >   * ia64:     /lib/ld-linux-ia64.so.2
> >   * mips n64: /lib64/ld-linux-mipsn8.so.1
> >   * nios2:    /lib/ld-linux-nios2.so.1
> >   * x86_64:   /lib64/ld-linux-x86-64.so.2
> >
> > So the actual ld.so binary should be called something like
> > "ld-linux-rv.so.1" instead of just "ld.so.1". With everything
> > else staying the same, that would give us a dynamic linker path
> > along the lines of "/lib64/lp64f/ld-linux-rv.so.1" for an RV64G
> > system.
[...]
> Just to be clear, the paths you'd like would look exactly like
> 
>   rv32-ilp32: /lib32/ilp32/ld-linux-rv.so.1
>   rv64-lp64d: /lib64/lp64d/ld-linux-rv.so.1
> 
> ?

Yes, that is what I had in mind.

> If so, that should be a pretty straight-forward change.  I'll
> incorporate it into our v2 patchset.  I'd also be OK with something
> like "/lib64/lp64d/ld-linux-rv64imafd-lp64d.so.1", if for some reason
> that's better (it looks a bit more like the other architectures to
> me).  I'm really OK with pretty much anything here, so feel free to
> offer suggestions -- otherwise I'll just go with what's listed above.

Including the ABI specifier twice, i.e. both as a subdirectory
name (.../lp64d/...) and as part of the ld.so filename
(ld-linux-rv64imafd-lp64d.so.1) doesn't seem useful to me. The
ABI specifier must be a part of the dynamic linker path, but
having it in there once should be enough :-).

Whether one encodes the ABI specifier inside the ld.so filename
or in the form of a subdirectory AFAICS doesn't make any
technical difference and appears to me largely as a matter of
taste.  My proposal above was just the minimalst-possible change
against the existing code that would fullfill my aim.

The other Linux platforms commonly don't use subdirectories and
instead encode the ABI specifier as part of the ld.so filename
(e.g. the "hf" part in /lib/ld-linux-armhf.so.3 specifies
hardfloat EABI, and the "n8" part in
/lib64/ld-linux-mipsn8.so.1 specifies a specific MIPS ABI variant),
while RISC-V currently encodes the ABI variant as a subdirectory name.

Stefan O'Rear wrote on the RISC-V sw-dev list that he would prefer to
encode the ABI specifier as part of the ld.so filename and put
everything in /lib instead of differentiating the directory by XLEN,
which would keep things largely similar to the other Linux platforms.
Based on your two examples above that would result in something like:

rv32-ilp32: /lib/ld-linux-rv32ilp32.so.1
rv64-lp64d: /lib/ld-linux-rv64lp64d.so.1

I am happy with any of these variants as long as the resulting
naming scheme encodes both platform and ABI and thereby makes
sure that the dynamic linker path is free of conflicts in a
multiarch installation.  Stefan's proposal is nearer to what
other Linux platforms do, but I assume that Andrew Waterman,
who has introduced the current RISC-V scheme with the ABI
subdirectories, has had a reason to do things the way they are.
Andrew, can you perhaps comment on this?



Regarding encoding the minimum ISA extensions into the ld.so
filename (i.e. the "64imafd" part in your example of
"ld-linux-rv64imafd-lp64d.so.1"): We had a disussion about that
on the RISC-V sw-dev list and the idea didn't find any
supporters.  The result of the discussion was to handle things
similar to other platforms and just define RV{32|64}IMA(C) as the
softfloat baseline and RV{32|64}G(C) as the hardfloat baseline
for running Linux and be done with it.

As some background information for people on the gcc lists who
don't follow the RISC-V development in detail: RISC-V uses a base
ISA (I=integer operations) plus a number of optional ISA
extensions (among them M=hardware multiply, A=atomic operations,
F=single precision float, D=double precision float, C=compressed
instruction set).  The combination of IMAFD is considered the
"general purpose" set and commonly abbreviated as "G".

The ABI identifier specifies the calling conventions, but not the
ISA extensions used by the code.  This means that e.g. binaries
for an RV32I-only CPU and binaries for an RV32IMA CPU that make
use of the additional M+A instructions would use the same ABI
identifier (ilp32), as the calling conventions are the same for
both.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.