Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Michael Hope <michael.hope@linaro.org>]

On 4 April 2012 21:06, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Wed, 4 Apr 2012, Michael Hope wrote:
>
>> The tricky one is new GCC with old GLIBC.  GCC may have to do a
>> configure time test and fall back to /lib/ld-linux.so.3 if the hard
>> float loader is missing.
>
> I don't think that's appropriate for ABI issues.  If a different dynamic
> linker name is specified, GCC should use it unconditionally (and require
> new enough glibc or a glibc installation that was appropriately
> rearranged).

OK.  I want GCC 4.7.1 to use the new path.  Does this mean that
released versions of GLIBC and GCC 4.7.1 will be incompatible, or does
GLIBC pick the path up from GCC?

>> > I have no idea whether shlib-versions files naming a file in a
>> > subdirectory will work - but if not, you'd need to send a patch to
>> > libc-alpha to support dynamic linkers in subdirectories, with appropriate
>> > justification for why you are doing something different from all other
>> > architectures.
>>
>> Understood.  For now this is just a path.  There's more infrastructure
>> work needed if the path includes a directory.
>
> Formally it's just a path - but an important feature of GNU/Linux and the
> GNU toolchain is consistency between different architectures and existing
> upstream practice is that the dynamic linker is always in the same
> directory as the other associated libraries and that this has the form
> /lib<something>.  In the absence of a compelling reason, which I have not
> seen stated, to do otherwise for a single case, I think that existing
> practice should be followed with the dynamic linker being in a directory
> such as /libhf.

OK.  This matches Jakub's email.

> The "more infrastructure work needed" makes clear that you need libc-alpha
> buy-in *before* putting any patches into GCC or ports.

OK.  I'm glad we had this discussion as it had to start somewhere.
I'll do a follow up across gcc-patches, libc-alpha, and binutils.

> But maybe if you
> don't try to put the dynamic linker in a different directory from the
> other libraries, it's easier to support via existing mechanisms (setting
> slibdir differently if --enable-multiarch-directories or similar)?

OK.  /libhf may fit that better.

>> Do the MIPS or PowerPC loaders detect the ABI and change the library
>> path based on that?  I couldn't tell from the code.
>
> No, they don't detect the ABI.  Both ABIs (and, for Power, the e500v1 and
> e500v2 variants - compatible with soft-float at the function-calling level
> but with some glibc ABI differences with soft-float and with each other)
> use the same directories.

Sorry, I'm confused.  I had a poke about with MIPS and it uses
different argument registers for soft and hard float.  Soft float uses
$4 and hard float $f0.  Are there shims or similar installed by the
loader?

>> > (e) Existing practice for cases that do use different dynamic linkers is
>> > to use a separate library directory, not just dynamic linker name, as in
>> > lib32 and lib64 for MIPS or libx32 for x32; it's certainly a lot easier to
>> > make two sets of libraries work in parallel if you have separate library
>> > directories like that.
>>
>> Is this required, or should it be left to the distro to choose?  Once
>> the loader is in control then it can account for any distro specific
>> features, which may be the standard /lib and /usr/lib for single ABI
>> distros like Fedora or /usr/lib/$tuple for multiarch distros like
>> Ubuntu and Debian.
>
> I thought Fedora used the standard upstream /lib64 on x86_64 and so would
> naturally use a standard upstream /libhf where appropriate.

Good.  Dennis said the same.

>> > So it would seem more appropriate to define a directory libhf for ARM (meaning you need a binutils patch as well to
>> > handle that directory, I think)
>>
>> I'd like to leave that discussion for now.  The Debian goal is to
>> support incompatible ABIs and, past that, incompatible architectures.
>> libhf is ambiguous as you could have a MIPS hard float library
>> installed on the same system as an ARM hard float library.
>
> If you want both ARM and MIPS hard-float then I'd think you want both
> big-endian and little-endian ARM hard-float - but your patch defines the
> same dynamic linker name for both of those.

Big endian is extremely uncommon on ARM and I'd rather define it when
needed.  For strictness sake I'll change the patch to use the new path
for hard float little endian only.

So:
 * Big endian: undefined, defaults to /lib/ld-linux.so.3
 * Little endian, soft float: /lib/ld-linux.so.3
 * Little endian, hard float: /libhf/ld-linux.so.3

> Standard upstream practice supports having multiple variants that
> plausibly run on the same system at the same time, such as /lib and
> /lib64, and it seems reasonable to support hard and soft float variants
> that way via a directory such as /libhf.  The Debian-style paths are not
> the default on any other architecture and I don't think it's appropriate
> to make them the default for this particular case only.

OK.  Debian multiarch covers libraries and headers but not
executables.  As a MIPS hard float /usr/bin/ls would collide with an
ARM hard float /usr/bin/ls then it's fine for the loader names to
potentially collide as well.

In practice they wouldn't as most architecture has a subtily different
loader name (cf. ld.so.1 for MIPS, ld-linux.so.2 for i386, and
ld-linux.so.3 for ARM).

>> > and these different Debian-style names
>> > could be implemented separately in a multiarch patch if someone submits
>> > one that properly accounts for my review comments on previous patch
>> > versions (failure to produce such a fixed patch being why Debian multiarch
>> > directory support has not got into GCC so far).
>>
>> Agreed.  Note that this loader path discussion is unrelated to
>> multiarch.  It came from the same people so there's a family
>> resemblance.
>
> I think it's directly related, and that such a path is inappropriate by
> default; that ARM should be consistent with other architectures, and that
> if you want to support paths in such subdirectories that would be a
> separate multiarch patch series for GCC, binutils and glibc (but the
> PT_INTERP would still use /lib<whatever>/<name> without subdirectories in
> any case).

OK.  I'll ping the Debian guys to see if there's an advantage that I'm missing.

-- Michael