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

[Steve McIntyre <steve dot mcintyre at linaro dot org>]

On Tue, Jan 21, 2014 at 10:42:11PM -0500, Carlos O'Donell wrote:
>
>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.

That's a good point, yes, and one I've been meaning to raise for a
while! At the moment, ldconfig is also specifically built to only
support individual (native) architectures, so cache maintenance and
access is an *interesting* topic. As far as I can see right now, to
work sensibly you'd really want to run ldconfig for each of the
architectures/ABIs that you have on your system. I don't know if qemu
does anything special about this, but I doubt it. Then, all the cache
information would be placed into a single cache with potential for
collisions.

>From looking at the ldconfig and cache code a while back, a couple of
ideas came to mind:

 * Could/should we change ldconfig to deal with all the ELF libraries
   it finds in the system search paths, regardless of architecture and
   ABI? I see nothing inherently difficult with this: all the ELF
   header parsing code is already portable and AFAICS it shouldn't
   care at all about the platform of the libraries it finds.

 * Should we then split the cache up into multiple files, one per
   arch/ABI? (In fact, one per distinct loader?) This would remove any
   potential issues with collisions and should make things simpler and
   maybe faster as far as I can see - in multiple-ABI cases each
   loader will have a smaller search space when looking for libraries.

Maybe I've missed something obvious here - please tell me? :-)

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

Definitely - thanks Joseph!

Cheers,
-- 
Steve McIntyre                                steve.mcintyre@linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs