On Tue, Jan 17, 2017 at 12:48 PM, Karsten Merker <mer...@debian.org> wrote:
> On Mon, Jan 16, 2017 at 09:37:15PM -0800, Palmer Dabbelt wrote:
>> On Sat, 14 Jan 2017 02:05:27 PST (-0800), mer...@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?
Thanks for taking the time to ponder this. I agree that the important
point is that the ABI (hence XLEN) is encoded somewhere in the
filename--and that once is enough :-).
We went with the /libXX/YY/ approach because, on a multilib system,
the system libraries also need to be distinguished by ABI. It seemed
most natural to us to handle ld.so and e.g. libc.so in a consistent
manner. However, something along the lines of your proposal, like
/lib/ld-linux-riscvXX-YY.so.1, is also perfectly serviceable, and has
the advantage of looking more similar to other Linux systems.
>
>
>
> 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.
Also, ld.so can be compiled to the least-common denominator ISA that
can implement the corresponding ABI. lp64d implies that the F and D
extensions must be present, whereas C (and V and ...) can be omitted
altogether for ld.so's purposes.
>
> 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.
