This is the mail archive of the
mailing list for the glibc project.
Re: Multiarch interpreter names for traditional architectures
On Fri, 9 Feb 2018, Joseph Myers wrote:
> > > > mips,classic NaN,o32,BE ld-linux-mips.so.1
> > > > mips,classic NaN,o32,LE ld-linux-mipsle.so.1
> > > > mips,classic NaN,n64,LE ld-linux-mips64le.so.1
> > >
> > > Under-specified, since you have hard-float and soft-float.
> > And also MIPS16 and microMIPS, R6 (with its own microMIPS variant), 2008
> > NaN, never mind n32.
> I didn't think MIPS16 and microMIPS meant different ABIs; I thought a
> MIPS16 binary could use either MIPS16 or non-MIPS16 libc, etc.
Well, regular MIPS code will run on MIPS16 hardware, so no separate ld.so
is needed and I think we may indeed treat it as an ABI extension rather
than a different ABI.
However microMIPS hardware may not support regular MIPS code execution
(and vice versa) and therefore I think it has to be treated as a different
ABI. Placing microMIPS ld.so where regular MIPS ld.so is expected will
break if the installation is shared via NFS between pure regular MIPS and
pure microMIPS hardware.
> R6 is indeed a tricky case for defining what is or is not a different ABI
> - does removing instructions make something a different ABI? Or if it's
> the same ABI, it illustrates (as with powerpc soft-float / SPE) how
> distributions may wish to build for different variants that have the same
> ABI, and so you necessarily have multiarch directory variants that share
> an ABI and thus share a dynamic linker name even if every different ABI
> has a different dynamic linker name.
Good point. There is a large overlap between the instruction sets of R6
and earlier ISAs, so I am fairly sure it is possible to craft a subset of
MIPS I and MIPS III instructions respectively for the 32-bit and 64-bit
architecture variants and use it to create software that is functional.
So at the high level we could consider MIPS I/III and MIPS32r6/MIPS64r6
both as extensions to a fictious MIPS32r0/MIPS64r0 ISA and therefore the
two former actual ISAs as ABI extensions to the same baseline ABI.
Implementing a toolchain command-line option that targets this fictious
ISA might be an interesting project BTW.
And then R6 microMIPS uses an instruction encoding that is entirely
different from R3-R5 microMIPS, so I am pretty firm it has to be
considered a different ABI.