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

Joseph S. Myers joseph at codesourcery.com
Thu Apr 5 00:07:23 UTC 2012

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

> 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.  But any multiarch support patch 
should presumably define separate multiarch paths for each endianness.

Joseph S. Myers
joseph at codesourcery.com

More information about the cross-distro mailing list