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

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

On 5 April 2012 12:07, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Thu, 5 Apr 2012, Michael Hope wrote:
>
>> > 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?
>
> Released versions would be incompatible (you could make GCC check at
> configure time for too-old glibc if --with-float=hard); the path needs
> hardcoding in both places.
>
>> >> 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?
>
> No.  A system is either purely hard-float or purely soft-float, and the
> same paths are used for both so they can't coexist.  (Mismatches at
> *static* link time are detected through object attributes.)

Ah, the same as ARM then.  The MIPS community would need something
similar to this patch if they wanted to support soft and hard float
side by side.

>> 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.
>
> I don't think that's correct; the new path should be used independent of
> endian, just as the existing path is.

OK.

> But any multiarch support patch
> should presumably define separate multiarch paths for each endianness.

That's up to Debian.  I've asked for documentation on the final tuples
and what they mean as the one at:
 http://wiki.debian.org/Multiarch/Tuples

is out of date.  I prefer defining what is needed now and doing others
as needed.

-- Michael