Re: Multiarch interpreter names for traditional architectures

["Maciej W. Rozycki" <macro at mips dot com>]

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.

  Maciej