Re: Policy: Require new dynamic loader names for entirely new ABIs?

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Mon, 20 Jan 2014, Carlos O'Donell wrote:

> The only thing I can say is that we make it
> policy that entirely new ABI's should always
> use a unique dynamic loader name unless the
> submitter can argue otherwise.

Do you mean "new ABIs that could be used on the same system as an existing 
ABI" (same architecture, same endianness, no incompatibilities of kernel / 
userspace ABI)?  Or any new ABIs for an existing architecture, even if 
simultaneous usability is entirely hypothetical (like the BE/LE case, 
where some architectures support simultaneous operation but the Linux 
kernel has no support for other-endian processes)?  Or any new ABIs at 
all, including the addition of a completely new architecture, because 
hypothetically userspace QEMU could be transparently used to run 
other-architecture processes?

For the first, the proposed MIPS o32 -mfp64 support would need two new 
dynamic linker names (for the two NaN choices), which seems reasonable 
enough.  For the second, it would need four new names, to cover BE/LE 
differences - even though no existing MIPS dynamic linker names vary for 
BE/LE (or hard/soft float, but -mfp64 is a variant of hard float so that 
issue doesn't arise in this case).  MIPS couldn't run BE and LE processes 
on the same kernel anyway since endianness is determined at CPU reset 
(endianness of loads/stores can be reverse, but that would involve new 
ABIs where load/store endianness is different from that used for 
instructions).  For the third, new architectures (such as nios2, hopefully 
to be submitted for glibc 2.20, currently using /lib/ld.so.1) would also 
need unique dynamic linker names not already used by other architectures.

I believe glibc supports the following (architecture, ABI)
combinations, with dynamic linker names as indicated (could
architecture maintainers please correct any errors?) - for a total of
62 incompatible ABIs (24 of them for MIPS).  There may well be uses
cases of configure triplets and --with-fp / --without-fp options
accepted by configure, but I don't expect any such other cases
actually to work.  (The exact extent of support varies - inclusion in
this list means I think the configuration was at one point intended by
the port maintainer to be functional, though some may not currently
build without patches.)

x86 Hurd (32-bit, hard-float): /lib/ld.so (that is, GCC uses that name
with -dynamic-linker so in PT_INTERP; my understanding of
shlib-versions is that it gets the SONAME ld.so.1 by default).

The subsequent entries are for use of glibc with the Linux kernel on
the given architecture.

aarch64 (BE): /lib/ld-linux-aarch64_be.so.1

aarch64 (LE): /lib/ld-linux-aarch64.so.1

(The ILP32 port is not yet in glibc.)

alpha (hard-float): /lib/ld-linux.so.2

(At least, I *think* soft-float isn't in use for this architecture
with glibc.)

am33 (hard-float): /lib/ld.so.1

(At least, I *think* soft-float isn't in use for this architecture
with glibc.)

arm (hard-float ABI, BE32): /lib/ld-linux-armhf.so.3

arm (hard-float ABI, BE8): /lib/ld-linux-armhf.so.3

arm (hard-float ABI, LE): /lib/ld-linux-armhf.so.3

arm (soft-float ABI, BE32): /lib/ld-linux.so.3

arm (soft-float ABI, BE8): /lib/ld-linux.so.3

arm (soft-float ABI, LE): /lib/ld-linux.so.3

(The ARM soft-float ABI can be used with both hard and soft-float
code.  ARM supports two variants of big-endian operation, (on newer
processors) BE8 and (on older processors) BE32, which are the same at
.o level but incompatible for linked executabled and shared
libraries.)

hppa (hard-float): /lib/ld.so.1

(At least, I *think* soft-float isn't in use for this architecture
with glibc.  64-bit is definitely not supported.)

ia64 (hard-float): /lib/ld-linux-ia64.so.2

(Big-endian operation is not supported by glibc (or the Linux kernel?)
on this architecture, and nor is ILP32 operation, although some other
OSes may support these.)

m68k (classic, hard-float): /lib/ld.so.1

m68k (ColdFire, hard or soft float): /lib/ld.so.1

(At least, I *think* soft-float isn't in use for classic m68k with
glibc.  The ColdFire ABI is the same for both hard and soft-float.)

microblaze (hard or soft float, BE): /lib/ld.so.1

microblaze (hard or soft float, LE): /lib/ld.so.1

(At least, I *think* the ABIs are the same for both hard and soft
float, and that both endiannesses are supported.)

mips (classic NaN, o32, hard-float, BE): /lib/ld.so.1

mips (classic NaN, o32, hard-float, LE): /lib/ld.so.1

mips (classic NaN, o32, soft-float, BE): /lib/ld.so.1

mips (classic NaN, o32, soft-float, LE): /lib/ld.so.1

mips (NaN2008, o32, hard-float, BE): /lib/ld-linux-mipsn8.so.1

mips (NaN2008, o32, hard-float, LE): /lib/ld-linux-mipsn8.so.1

mips (NaN2008, o32, soft-float, BE): /lib/ld-linux-mipsn8.so.1

mips (NaN2008, o32, soft-float, LE): /lib/ld-linux-mipsn8.so.1

mips (classic NaN, n32, hard-float, BE): /lib32/ld.so.1

mips (classic NaN, n32, hard-float, LE): /lib32/ld.so.1

mips (classic NaN, n32, soft-float, BE): /lib32/ld.so.1

mips (classic NaN, n32, soft-float, LE): /lib32/ld.so.1

mips (NaN2008, n32, hard-float, BE): /lib32/ld-linux-mipsn8.so.1

mips (NaN2008, n32, hard-float, LE): /lib32/ld-linux-mipsn8.so.1

mips (NaN2008, n32, soft-float, BE): /lib32/ld-linux-mipsn8.so.1

mips (NaN2008, n32, soft-float, LE): /lib32/ld-linux-mipsn8.so.1

mips (classic NaN, n64, hard-float, BE): /lib64/ld.so.1

mips (classic NaN, n64, hard-float, LE): /lib64/ld.so.1

mips (classic NaN, n64, soft-float, BE): /lib64/ld.so.1

mips (classic NaN, n64, soft-float, LE): /lib64/ld.so.1

mips (NaN2008, n64, hard-float, BE): /lib64/ld-linux-mipsn8.so.1

mips (NaN2008, n64, hard-float, LE): /lib64/ld-linux-mipsn8.so.1

mips (NaN2008, n64, soft-float, BE): /lib64/ld-linux-mipsn8.so.1

mips (NaN2008, n64, soft-float, LE): /lib64/ld-linux-mipsn8.so.1

powerpc (32-bit, hard-float, BE): /lib/ld.so.1

powerpc (32-bit, soft-float, BE): /lib/ld.so.1

powerpc (64-bit, hard-float, BE): /lib64/ld64.so.1

powerpc (64-bit, hard-float, LE): /lib64/ld64.so.2

(The GCC distinction for 64-bit is actually ELFv1/ELFv2, but the BE
ELFv2 and LE ELFv1 combinations aren't supported.)

s390 (32-bit, hard-float): /lib/ld.so.1

s390 (64-bit, hard-float): /lib/ld64.so.1

(At least, I *think* soft-float isn't in use for this architecture
with glibc.)

sh (hard-float, BE): /lib/ld-linux.so.2

sh (hard-float, LE): /lib/ld-linux.so.2

sh (soft-float, BE): /lib/ld-linux.so.2

sh (soft-float, LE): /lib/ld-linux.so.2

(At least, I *think* the hard-float and soft-float ABIs are
incompatible, and that both endiannesses are supported.  64-bit is
definitely not supported.)

sparc (32-bit, hard-float): /lib/ld-linux.so.2

sparc (64-bit, hard-float): /lib64/ld-linux.so.2

(At least, I *think* soft-float isn't in use for this architecture
with glibc.)

tilegx (32-bit, hard-float, BE): /lib32/ld.so.1

tilegx (32-bit, hard-float, LE): /lib32/ld.so.1

tilegx (64-bit, hard-float, BE): /lib/ld.so.1

tilegx (64-bit, hard-float, LE): /lib/ld.so.1

tilepro (soft-float, BE): /lib/ld.so.1

tilepro (soft-float, LE): /lib/ld.so.1

x86 (32-bit, hard-float): /lib/ld-linux.so.2

x86_64 (64-bit, hard-float): /lib64/ld-linux-x86-64.so.2

x86_64 (x32, hard-float): /libx32/ld-linux-x32.so.2

-- 
Joseph S. Myers
joseph@codesourcery.com