This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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@codesourcery.com

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]