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

["Carlos O'Donell" <carlos at redhat dot com>]

On 01/21/2014 05:33 PM, Joseph S. Myers wrote:
> 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?

I had intended to mean "any new ABIs for an existing architecture, even if 
simultaneous usability is entirely hypothetical" This does include potentially
incompatible runtimes that may require a reboot to switch endianness. Since
it's entirely feasible for users to want a single rootfs that can be used
in either mode without tricks that include switching disks, chroots, or
other things.

You raise a very good point about QEMU, I had not considered a policy for
all new ABIs, but I'm always happy when we can make simple rules that
mean we don't repeat the same problems as before.

A table of loader names and collisions was written up by Linaro here,
though it is not as thorough as your list below, it does appear to consider
emulation: https://wiki.linaro.org/RikuVoipio/LdSoTable

It seems excessive to force all new ABIs to have a unique name, but it's
entirely possible to use /lib/ld1.so.1 through /lib/ld62.so.1 to represent
the 62 unique ABIs with a /lib/ld.so.1 symlink to a default (as determined
by the distribution) loader. The symlink is only for the convenience of
the developers who might not remember which libN.so.1 is the right one.

Do we also need to require that each ABI be distinguishable in the loader
cache? Like we did for ARM e.g. unknown, soft float, hard float. Since all
N loaders would share a single cache file?

It would be unfortunate to have distinct loader names, but the cache is
filled with undistinguishable objects of both ABIs.

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

Are you suggesting we change the dynamic loader names for the various
MIPS ABIs, and tell users to use symlinks as the workaround?

I'm not against that. As it stands you can't use any of these ABIs
on a single rootfs since the dyanmic loader conflicts. Thus a compat
symlink is an easy solution. Future builds would use the new loader
name and would be compatible to run under emulation via QEMU.

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

OK.

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

Is that a bug?

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

Thank you for the list!
 
> 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
> 

Cheers,
Carlos.