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] > > Hello everybody, > > 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. > > Changing the linker path is of course an incompatible change, but > RISC-V gcc support as submitted upstream now already incoporates > a number of incompatible changes to the previous development > versions (including a different dynamic linker path than older > riscv-gcc versions), so moving from the previous development > versions to upstream results in incompatible binaries anyway, > therefore IMHO now is the time to get these things sorted out > once for all.
I'm perfectly fine with this approach. We have a policy of not maintaining ABI compatibility until code is upstream and released (so we'll be ABI compatible in binutils when 2.28 comes out soon) because we want to fix these sorts of issues the right way rather than having being stuck with something bad forever. 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 ? 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. Thanks!
