Multiarch interpreter names for traditional architectures

Multiarch interpreter names for traditional architectures

[Javier Serrano Polo]

[-- Attachment #1: Type: text/plain, Size: 1196 bytes --]

Dear list,

Multiarch systems allow to run programs from other architectures. ELF
executables for traditional architectures depend on interpreter names
that may conflict with each other. For instance, it is complicated to
run alpha programs on x86 systems.

Simpler systems use multiarch interpreter names. I am looking for
consensus since I would like to avoid, e.g., having ld-linux-i386.so.2,
ld-linux-i686.so.2, ld-linux-x86.so.2, and ld-linux-x86-32.so.2 for x86.
What would be the proper multiarch names for the following
architectures? I present suggestions:

alpha	ld-linux-alpha.so.2
arm,soft-float,LE	ld-linux-armsfle.so.3
hppa	ld-linux-hppa.so.1
m68k	ld-linux-m68k.so.1
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
powerpc,32-bit	ld-linux-powerpc.so.1
powerpc SPE	ld-linux-powerpcspe.so.1
powerpc,64-bit,BE	ld-linux-powerpc64.so.1
powerpc,64-bit,LE	ld-linux-powerpc64le.so.2
s390,64-bit	ld-linux-s390-64.so.1
sh,SH4	ld-linux-sh4.so.2
sparc,64-bit	ld-linux-sparc64.so.2
x86	ld-linux-x86.so.2
hurd,x86	ld-hurd-x86.so.1
kfreebsd,x86	ld-kfreebsd-x86.so.1

Thank you.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3386 bytes --]

Re: Multiarch interpreter names for traditional architectures

[Zack Weinberg]

On Sun, Feb 4, 2018 at 11:25 AM, Javier Serrano Polo <javier@jasp.net> wrote:
> Dear list,
>
> Multiarch systems allow to run programs from other architectures. ELF
> executables for traditional architectures depend on interpreter names
> that may conflict with each other. For instance, it is complicated to
> run alpha programs on x86 systems.
>
> Simpler systems use multiarch interpreter names. I am looking for
> consensus since I would like to avoid, e.g., having ld-linux-i386.so.2,
> ld-linux-i686.so.2, ld-linux-x86.so.2, and ld-linux-x86-32.so.2 for x86.
> What would be the proper multiarch names for the following
> architectures? I present suggestions:
...

Debian's version of "multiarch" (see
https://wiki.debian.org/Multiarch) uses /lib/$(CANONICAL_HOST)/ld.so.2
where $(CANONICAL_HOST) is a slightly adjusted version of the GNU
canonical system identifier.  Historical infixes in the name of ld.so
are preserved, but new subarchitectures don't need one. I think this
is better than trying to come up with lname infixes for everything,
since it also gives you somewhere to put all the _other_ files that
are subarchitecture-specific, and it's easy to see how it should be
extended to more complicated scenarios.  There are multiarch
subdirectories of /usr/lib and /usr/include as well as /lib.  I would
like to see it adopted more widely, perhaps even become the GNU-wide
convention.

zw

Re: Multiarch interpreter names for traditional architectures

[Florian Weimer]

On 02/04/2018 05:25 PM, Javier Serrano Polo wrote:
> Multiarch systems allow to run programs from other architectures. ELF
> executables for traditional architectures depend on interpreter names
> that may conflict with each other. For instance, it is complicated to
> run alpha programs on x86 systems.

Not if the kernel invokes the right emulator.  Why isn't it possible to 
arrange for that?

Considering this is an ABI break basically everywhere, you need to 
provide very good justification for doing this.

Thanks,
Florian

Re: Multiarch interpreter names for traditional architectures

[Javier Serrano Polo]

[-- Attachment #1: Type: text/plain, Size: 928 bytes --]

El dg 04 de 02 de 2018 a les 12:06 -0500, Zack Weinberg va escriure:
> Debian's version of "multiarch" (see
> https://wiki.debian.org/Multiarch) uses /lib/$(CANONICAL_HOST)/ld.so.2
> where $(CANONICAL_HOST) is a slightly adjusted version of the GNU
> canonical system identifier.

/lib/i386-linux-gnu/ld.so.2 would be fine for x86.

El dg 04 de 02 de 2018 a les 18:19 +0100, Florian Weimer va escriure:
> Not if the kernel invokes the right emulator.  Why isn't it possible to 
> arrange for that?

It is possible, but complicated. In the example, kernel starts the alpha
emulator, then the emulator looks for the interpreter requested by the
program. A prepared system does not ship the traditional alpha/x86
interpreter, then the emulator looks for the alpha multiarch
interpreter. Otherwise, if the traditional x86 interpreter is installed,
the user must tell the alpha emulator to ignore that interpreter.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3386 bytes --]

Re: Multiarch interpreter names for traditional architectures

[Florian Weimer]

On 02/04/2018 07:16 PM, Javier Serrano Polo wrote:
> El dg 04 de 02 de 2018 a les 18:19 +0100, Florian Weimer va escriure:
>> Not if the kernel invokes the right emulator.  Why isn't it possible to
>> arrange for that?
> It is possible, but complicated. In the example, kernel starts the alpha
> emulator, then the emulator looks for the interpreter requested by the
> program. A prepared system does not ship the traditional alpha/x86
> interpreter, then the emulator looks for the alpha multiarch
> interpreter. Otherwise, if the traditional x86 interpreter is installed,
> the user must tell the alpha emulator to ignore that interpreter.

Please rephrase that in a way which separates what happens today from 
what should happen in the future.  It's hard to tell what you are proposing.

Currently, the kernel maps both the ELF interpreter and the executable. 
Do you intend to change that?

Thanks,
Florian

Re: Multiarch interpreter names for traditional architectures

[Javier Serrano Polo]

[-- Attachment #1: Type: text/plain, Size: 1675 bytes --]

El dl 05 de 02 de 2018 a les 07:01 +0100, Florian Weimer va escriure:
> Please rephrase that in a way which separates what happens today from 
> what should happen in the future.

We are still in the alpha on x86 example. What happens today on your
systems:

     1. Kernel starts the alpha emulator.
     2. The emulator looks for /lib/ld-linux.so.2.
     3. The program fails.

What happens today on my systems:

     1. Kernel starts the alpha emulator.
     2. The emulator looks for /lib/ld-linux.so.2.
     3. User has configured the emulator to redirect all file operations
        to /lib/ld-linux-alpha.so.2.
     4. The program runs, but the path /lib/ld-linux.so.2 will not work
        as expected.

What should happen in the future:

     1. Kernel starts the alpha emulator.
     2. The emulator looks for /lib/ld-linux.so.2.
     3. User has configured the emulator to use /lib/ld-linux-alpha.so.2
        as the interpreter, even if /lib/ld-linux.so.2 exists.
     4. The program runs.

What happens with multiarch binaries:

     1. Kernel starts the alpha emulator.
     2. The emulator looks for /lib/ld-linux-alpha.so.2.
     3. The program runs.

> Currently, the kernel maps both the ELF interpreter and the executable. 
> Do you intend to change that?

The only ability I add to the kernel is to map an alternative
interpreter if the requested one is not found.

But we are deviating from the topic: what should the multiarch
interpreter names be? I like Zack's view. It does not follow the current
practice of using infixes, but multiarch filesystems become cleaner and
interpreter names are unique easily.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3386 bytes --]

Re: Multiarch interpreter names for traditional architectures

[Andreas Schwab]

On Feb 05 2018, Javier Serrano Polo <javier@jasp.net> wrote:

> We are still in the alpha on x86 example. What happens today on your
> systems:
>
>      1. Kernel starts the alpha emulator.
>      2. The emulator looks for /lib/ld-linux.so.2.
>      3. The program fails.
>
> What happens today on my systems:
>
>      1. Kernel starts the alpha emulator.
>      2. The emulator looks for /lib/ld-linux.so.2.
>      3. User has configured the emulator to redirect all file operations
>         to /lib/ld-linux-alpha.so.2.
>      4. The program runs, but the path /lib/ld-linux.so.2 will not work
>         as expected.

Why hasn't the emulator been configured to look in a sysroot first?

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Multiarch interpreter names for traditional architectures

[Javier Serrano Polo]

[-- Attachment #1: Type: text/plain, Size: 269 bytes --]

El dl 05 de 02 de 2018 a les 10:19 +0100, Andreas Schwab va escriure:
> Why hasn't the emulator been configured to look in a sysroot first?

/lib/ld-linux.so.2 -> /lib/ld-linux-alpha.so.2
is essentially the same as
/lib/ld-linux.so.2 -> sysroot/lib/ld-linux.so.2

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3386 bytes --]

Re: Multiarch interpreter names for traditional architectures

[Adhemerval Zanella]

On 05/02/2018 05:33, Javier Serrano Polo wrote:
> El dl 05 de 02 de 2018 a les 07:01 +0100, Florian Weimer va escriure:
>> Please rephrase that in a way which separates what happens today from 
>> what should happen in the future.
> 
> We are still in the alpha on x86 example. What happens today on your
> systems:
> 
>      1. Kernel starts the alpha emulator.
>      2. The emulator looks for /lib/ld-linux.so.2.
>      3. The program fails.
> 
> What happens today on my systems:
> 
>      1. Kernel starts the alpha emulator.
>      2. The emulator looks for /lib/ld-linux.so.2.
>      3. User has configured the emulator to redirect all file operations
>         to /lib/ld-linux-alpha.so.2.
>      4. The program runs, but the path /lib/ld-linux.so.2 will not work
>         as expected.
> 
> What should happen in the future:
> 
>      1. Kernel starts the alpha emulator.
>      2. The emulator looks for /lib/ld-linux.so.2.
>      3. User has configured the emulator to use /lib/ld-linux-alpha.so.2
>         as the interpreter, even if /lib/ld-linux.so.2 exists.
>      4. The program runs.
> 
> What happens with multiarch binaries:
> 
>      1. Kernel starts the alpha emulator.
>      2. The emulator looks for /lib/ld-linux-alpha.so.2.
>      3. The program runs.
> 
>> Currently, the kernel maps both the ELF interpreter and the executable. 
>> Do you intend to change that?
> 
> The only ability I add to the kernel is to map an alternative
> interpreter if the requested one is not found.
> 
> But we are deviating from the topic: what should the multiarch
> interpreter names be? I like Zack's view. It does not follow the current
> practice of using infixes, but multiarch filesystems become cleaner and
> interpreter names are unique easily.
> 

My understanding is the names were defined back then without the idea to
have incompatible ABI to share a common filesystem (which is possible now
through emulation) and as Florian put changing them now is ABI break which
although fixable by user (through relink to adjust INTERP section) is not
an option imho.

I think we can try to push for newer ports an abis to have distinguish
names from now on with this requisite in mind and document that Debian
way is a possible alternative to this issue.

Also, I think Andreas questioning is why emulator has not been configured
to look into sysroot/lib/ instead of /lib/. 

Re: Multiarch interpreter names for traditional architectures

[Javier Serrano Polo]

[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]

El dl 05 de 02 de 2018 a les 09:07 -0200, Adhemerval Zanella va
escriure:
> My understanding is the names were defined back then without the idea to
> have incompatible ABI to share a common filesystem (which is possible now
> through emulation) and as Florian put changing them now is ABI break which
> although fixable by user (through relink to adjust INTERP section) is not
> an option imho.

It is an option to look for an alternative interpreter, but I would
rather use /lib/alpha-linux-gnu/ld.so.2 instead
of /usr/gnemul/qemu-alpha/lib/ld-linux.so.2.

> Also, I think Andreas questioning is why emulator has not been configured
> to look into sysroot/lib/ instead of /lib/. 

I make this amendment:

What happens today on your systems:

     1. Kernel starts the alpha emulator.
     2. The emulator looks for /lib/ld-linux.so.2.
     3. User has configured the emulator to redirect all file operations
        to sysroot/lib/ld-linux.so.2.
     4. The program runs, but the path /lib/ld-linux.so.2 will not work
        as expected.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3386 bytes --]

Re: Multiarch interpreter names for traditional architectures

[Joseph Myers]

On Sun, 4 Feb 2018, Javier Serrano Polo wrote:

> Simpler systems use multiarch interpreter names. I am looking for
> consensus since I would like to avoid, e.g., having ld-linux-i386.so.2,
> ld-linux-i686.so.2, ld-linux-x86.so.2, and ld-linux-x86-32.so.2 for x86.
> What would be the proper multiarch names for the following
> architectures? I present suggestions:

As discussed, changing the interpreter name is an ABI break (apart from 
making new binaries gratuitously not work on old systems, the dynamic 
linker can get confused when a reference to the old name ends up being 
resolved to a symlink to the new path with the new SONAME; this is an 
actual issue that arose with the change to have ARM hard-float ABI use a 
different dynamic linker name from soft-float ABI).  I think doing so for 
any existing ABI has costs that outweigh any benefits.

> m68k	ld-linux-m68k.so.1

Under-specified, since you have classic m68k, ColdFire hard-float and 
ColdFire soft-float.  See <https://sourceware.org/glibc/wiki/ABIList>.

> 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.

> powerpc,32-bit	ld-linux-powerpc.so.1
> powerpc SPE	ld-linux-powerpcspe.so.1

The actual distinction at the glibc ABI level is between the hard-float 
and soft-float ABIs; SPE uses the same glibc ABI as soft-float.

This illustrates an issue with expecting unique interpreter paths in such 
cases.  It's entirely reasonable to have different distribution variants 
for powerpc soft-float and SPE, which might thus use different multiarch 
directory names - but because there isn't a separate ABI, anything which 
is part of the ABI (including the interpreter path) should not be 
different between them.

> powerpc,64-bit,BE	ld-linux-powerpc64.so.1
> powerpc,64-bit,LE	ld-linux-powerpc64le.so.2

The existing paths are /lib64/ld64.so.1 and /lib64/ld64.so.2.  Those paths 
are unique to those ABIs - it's only the path that needs to be unique, 
there should be no problem with one ABI having ld64.so.1 in /lib64 
(powerpc64 BE) and another having it in /lib (s390x).

> s390,64-bit	ld-linux-s390-64.so.1

Again, the path is already unique (/lib/ld64.so.1).

> sh,SH4	ld-linux-sh4.so.2

Under-specified, there are four SH4 ABIs.

> sparc,64-bit	ld-linux-sparc64.so.2

Path already unique, /lib64/ld-linux.so.2.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Multiarch interpreter names for traditional architectures

[Javier Serrano Polo]

[-- Attachment #1: Type: text/plain, Size: 319 bytes --]

It looks like multiarch interpreter names should come from multiarch
distros. I only know about Debian-based ones. The list of tuples that
would form the names is at:
https://wiki.debian.org/Multiarch/Tuples

Using multiarch tuples from Debian is the best answer so far. No one is
advocating names with infixes.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3386 bytes --]

Re: Multiarch interpreter names for traditional architectures

[Joseph Myers]

On Sun, 4 Feb 2018, Zack Weinberg wrote:

> extended to more complicated scenarios.  There are multiarch
> subdirectories of /usr/lib and /usr/include as well as /lib.  I would

Unfortunately, glibc support for this has not been contributed upstream 
and I don't think binutils support has been either (ld knows about lib64 
etc. directories in the form of LIBPATH_SUFFIX settings).  (GCC support 
*is* upstream.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Multiarch interpreter names for traditional architectures

[Zack Weinberg]

On Mon, Feb 5, 2018 at 1:05 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Sun, 4 Feb 2018, Zack Weinberg wrote:
>
>> extended to more complicated scenarios.  There are multiarch
>> subdirectories of /usr/lib and /usr/include as well as /lib.  I would
>
> Unfortunately, glibc support for this has not been contributed upstream
> and I don't think binutils support has been either (ld knows about lib64
> etc. directories in the form of LIBPATH_SUFFIX settings).  (GCC support
> *is* upstream.)

Javier, perhaps that is something you would be interested in working
on?  You would need to coordinate with the Debian maintainers of
binutils and glibc.  It would probably be best to get binutils support
completely upstreamed before doing anything with glibc.

zw

Re: Multiarch interpreter names for traditional architectures

[Javier Serrano Polo]

[-- Attachment #1: Type: text/plain, Size: 334 bytes --]

El dl 05 de 02 de 2018 a les 15:03 -0500, Zack Weinberg va escriure:
> It would probably be best to get binutils support
> completely upstreamed before doing anything with glibc.

I believe the change in glibc is independent. Anyway, current patch for
binutils (129_multiarch_libpath.patch) does not look ready to go
upstream.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3386 bytes --]

Re: Multiarch interpreter names for traditional architectures

[Javier Serrano Polo]

[-- Attachment #1: Type: text/plain, Size: 248 bytes --]

Debian glibc officially supports multiarch interpreter names, even for
traditional architectures. For instance, the multiarch interpreter for
x86_64 is /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 . There is
consensus among Debian-based distros.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3386 bytes --]

Re: Multiarch interpreter names for traditional architectures

[Aurelien Jarno]

On 2018-02-06 01:55, Javier Serrano Polo wrote:
> Debian glibc officially supports multiarch interpreter names, even for
> traditional architectures. For instance, the multiarch interpreter for
> x86_64 is /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 . There is
> consensus among Debian-based distros.

The notion of "multiarch interpreter" doesn't exist. On debian x86_64,
the program interpreter is /lib64/ld-linux-x86-64.so.2 just like any
other x86_64 distribution.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

Re: Multiarch interpreter names for traditional architectures

[Javier Serrano Polo]

[-- Attachment #1: Type: text/plain, Size: 376 bytes --]

El dv 09 de 02 de 2018 a les 15:02 +0100, Aurelien Jarno va escriure:
> The notion of "multiarch interpreter" doesn't exist.

It does exist, but you do not accept it. You are now denying the
official support that exists in Debian.
Use /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 as the program
interpreter and the program will work perfectly in Debian and
derivatives.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3386 bytes --]

Re: Multiarch interpreter names for traditional architectures

[Joseph Myers]

On Fri, 9 Feb 2018, Javier Serrano Polo wrote:

> El dv 09 de 02 de 2018 a les 15:02 +0100, Aurelien Jarno va escriure:
> > The notion of "multiarch interpreter" doesn't exist.
> 
> It does exist, but you do not accept it. You are now denying the
> official support that exists in Debian.
> Use /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 as the program
> interpreter and the program will work perfectly in Debian and
> derivatives.

Doing so is just as incorrect as using /lib64/ld-2.27.so as the 
interpreter name.  The fact that any number of file names happen to 
resolve to the same file as the interpreter does not make them proper 
names to use for it - only one name is correct under the ABI, and it's not 
proper to create inherently distribution-specific binaries rather than 
binaries that would work on any distribution with new-enough libc.

I think your present advocacy is an effective argument *against* any 
additions to multiarch support in the GNU toolchain.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Multiarch interpreter names for traditional architectures

[Javier Serrano Polo]

[-- Attachment #1: Type: text/plain, Size: 656 bytes --]

El dv 09 de 02 de 2018 a les 14:34 +0000, Joseph Myers va escriure:
> Doing so is just as incorrect as using /lib64/ld-2.27.so as the 
> interpreter name.

/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 is guaranteed to exist in
Debian; /lib/x86_64-linux-gnu/ld-2.24.so is not.

> I think your present advocacy is an effective argument *against* any 
> additions to multiarch support in the GNU toolchain.

My ability to implement multiarch solutions, just like I did in the
past, is an argument in favor. Your inability to provide interpreter
names that solve file conflicts in multiarch systems is a proof of your
competence about this matter.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3386 bytes --]

Re: Multiarch interpreter names for traditional architectures

[Aurelien Jarno]

On 2018-02-09 15:20, Javier Serrano Polo wrote:
> El dv 09 de 02 de 2018 a les 15:02 +0100, Aurelien Jarno va escriure:
> > The notion of "multiarch interpreter" doesn't exist.
> 
> It does exist, but you do not accept it. You are now denying the
> official support that exists in Debian.

I love the way you use "official" here.

> Use /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 as the program
> interpreter and the program will work perfectly in Debian and
> derivatives.

I don't care about compatibility within Debian and derivatives. I care
about the compatibility within the whole GNU/Linux ecosystem.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

Re: Multiarch interpreter names for traditional architectures

[Zack Weinberg]

On Fri, Feb 9, 2018 at 9:56 AM, Javier Serrano Polo <javier@jasp.net> wrote:
> El dv 09 de 02 de 2018 a les 14:34 +0000, Joseph Myers va escriure:
>> I think your present advocacy is an effective argument *against* any
>> additions to multiarch support in the GNU toolchain.
>
> My ability to implement multiarch solutions, just like I did in the
> past, is an argument in favor. Your inability to provide interpreter
> names that solve file conflicts in multiarch systems is a proof of your
> competence about this matter.

Both of these statements are pushing the boundary between technical
debate and personal attacks. Please take a step back, both of you, and
calm down a little.

It is true that the ELF psABI for x86-64/linux/glibc specifies
/lib64/ld-linux-x86-64.so.2 as the mandatory name of the program
interpreter, but that doesn't have to be set in stone forever.
Changes are difficult and have to be carefully staged, but I don't see
that it's on the level of, oh, changing libc.so's SONAME.  It seems
more like merging / and /usr, which is a thing at least some groups
are actively working on.

zw

Re: Multiarch interpreter names for traditional architectures

[Javier Serrano Polo]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

El dv 09 de 02 de 2018 a les 16:03 +0100, Aurelien Jarno va escriure:
> I love the way you use "official" here.

Me too. It is precisely your policy not to include any unnecessary file
because "experience shows that users are very imaginative when you
provide a feature". You have taken steps to insure the existence of
multiarch interpreters and they have landed on stable releases.

> I don't care about compatibility within Debian and derivatives.

I do. Strange statement from a Debian developer.

> I care
> about the compatibility within the whole GNU/Linux ecosystem.

I do too. I even care about compatibility with non-Linux systems.

Give a solution like I do instead of complaining about the past.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3386 bytes --]

Re: Multiarch interpreter names for traditional architectures

[Maciej W. Rozycki]

On Mon, 5 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.

  Maciej

Re: Multiarch interpreter names for traditional architectures

[Joseph Myers]

On Fri, 9 Feb 2018, Maciej W. Rozycki wrote:

> On Mon, 5 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.

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.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Multiarch interpreter names for traditional architectures

[Maciej W. Rozycki]

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

Re: Multiarch interpreter names for traditional architectures

[Joseph Myers]

On Fri, 9 Feb 2018, Maciej W. Rozycki wrote:

>  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.

But the execution of both might be supported on the same hardware.  We 
don't consider x86_64 with AVX512 enabled to be a separate ABI from plain 
x86_64 (and indeed some libmvec entry points may require instruction set 
features beyond the base ISA).

Effectively some things are the same ABI in that some hardware might run 
both and if it does, those things are compatible (no need for the dynamic 
linker to reject loading both together, no need for different dynamic 
linker paths since a binary might be built for the common subset).  While 
it would be reasonable for the dynamic linker also to be able to reject 
loading objects that require instruction set features not supported by the 
hardware (modulo being able to build for IFUNCs and other dynamic choice 
of function implementations and not mark the resulting objects as 
requiring those features), even when the ABI is the same.

There's a subjective element there in that it's possible e.g. to build a 
program making no use of floating-point that would thus work with both 
soft-float and hard-float libc, but we still consider those different ABIs 
if the choice affects the function-calling ABI, and for newer 
architectures such as RISC-V make sure to use different dynamic linker 
names for hard-float and soft-float ABIs.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Multiarch interpreter names for traditional architectures

[Maciej W. Rozycki]

On Fri, 9 Feb 2018, Joseph Myers wrote:

> >  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.
> 
> But the execution of both might be supported on the same hardware.  We 
> don't consider x86_64 with AVX512 enabled to be a separate ABI from plain 
> x86_64 (and indeed some libmvec entry points may require instruction set 
> features beyond the base ISA).

 I think this is not a good analogy.  The thing is there is no standalone 
AVX512 ISA -- that is you can't have a piece of hardware that only 
implements AVX512 and not the base x86_64 ISA.  This is analogous to the 
relationship between the regular MIPS ISA and the MIPS16 extension, which 
I have agreed are a part of the same ABI.

 Whereas the microMIPS ISA is standalone and you can have hardware that 
has only the microMIPS ISA implemented and not the regular MIPS ISA (and 
vice versa of course).

> Effectively some things are the same ABI in that some hardware might run 
> both and if it does, those things are compatible (no need for the dynamic 
> linker to reject loading both together, no need for different dynamic 
> linker paths since a binary might be built for the common subset).  While 
> it would be reasonable for the dynamic linker also to be able to reject 
> loading objects that require instruction set features not supported by the 
> hardware (modulo being able to build for IFUNCs and other dynamic choice 
> of function implementations and not mark the resulting objects as 
> requiring those features), even when the ABI is the same.

 Well, if you consider the regular MIPS ISA and the microMIPS ISA a part 
of the same ABI, then ld.so may not be able to run in the first place if 
hardware does not implement the ISA, either of the two, the loader has 
been built for, so it cannot even be considered if it is able to load 
things together.  So this contradicts your assertion that "a binary might 
be built for the common subset", because no such common subset exists 
between the regular MIPS ISA and the microMIPS ISA.

 You need at least a separate regular MIPS loader for regular MIPS 
executables and a separate microMIPS loader for microMIPS executables for 
userland software to be guaranteed to run.  Then either of those loaders 
started will be able to decide what else required can be loaded or not.

 With the above observations in mind do you still think the regular MIPS 
ISA and the microMIPS ISA are a part of the same ABI as far as the choice 
of the dynamic loader is concerned?  Or do you maintain that it's merely 
up to the installer of every individual system to match the ISA of ld.so 
to one supported on given hardware, observing that no single choice can 
serve all systems (and therefore in some configurations the filesystem 
cannot be shared and a copy will have to be made only to hold a different 
ld.so binary)?

  Maciej

Re: Multiarch interpreter names for traditional architectures

[Joseph Myers]

On Mon, 12 Feb 2018, Maciej W. Rozycki wrote:

>  With the above observations in mind do you still think the regular MIPS 
> ISA and the microMIPS ISA are a part of the same ABI as far as the choice 
> of the dynamic loader is concerned?  Or do you maintain that it's merely 

Yes, because my notion of a glibc ABI, as in the list at 
<https://sourceware.org/glibc/wiki/ABIList>, is that "same ABI" must be an 
equivalence relation.  A MIPS binary can use a microMIPS dynamic linker, 
and vice versa, and doing so is fully functional on hardware that supports 
both, so they are the same ABI.  And taking the transitive closure to make 
it an equivalence relation, r6 microMIPS also ends up being the same ABI 
as r3-r5 microMIPS despite different instruction encodings and so not 
being able to execute on the same hardware at all.

-- 
Joseph S. Myers
joseph@codesourcery.com