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 Wed, Apr 04, 2012 at 02:39:58PM +1200, Michael Hope wrote:
> On 4 April 2012 10:56, Joseph S. Myers <joseph@codesourcery.com> wrote:
> > On Tue, 3 Apr 2012, Michael Hope wrote:
> >
> >> +#define GLIBC_DYNAMIC_LINKER \
> >> + ? "%{mhard-float:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
> >> + ? ?%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
> >> + ? ?%{!mfloat-abi=hard:%{!mhard-float:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}}"
> >
> > (a) -mhard-float is a .opt Alias for -mfloat-abi=hard so does not need to
> > be handled in specs.
> 
> Fixed.
> 
> > (b) You need to handle compilers configured with --with-float=hard, so
> > make the specs depend on the default ABI the compiler was configured with.
> 
> GCC seems to take configure time options into account when evaluating
> a spec file.
> 
> Tested by building a default, --with-float=hard, and
> --with-float=softfp compiler then checking the loader path for all
> combinations of {,-mglibc,-mbionic,-muclibc} x
> {,-mhard-float,-msoft-float,-mfloat-abi=hard,-mfloat-abi=softfp}.
> 
> > (c) Please include libc-ports on future submissions and provide both the
> > GCC patch and the glibc ports patch that have been tested to work together
> > to build and install the library in the given path; a patch to one
> > component like this cannot sensibly be considered in isolation. ?I imagine
> > you'll need appropriate ARM preconfigure support to detect what ABI the
> > compiler is using, much like the support for MIPS, so that the right
> > shlib-versions files are used.
> 
> Agreed.
> 
> > ?I try to follow all ARM glibc discussions
> > on libc-ports closely, as the ARM glibc maintainer; was there a previous
> > discussion of the dynamic linker naming issue there that I missed?
> 
> Steve McIntyre is driving this inside Debian.  I'll ping him on the
> GLIBC support.
> 
> 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.
> 
> > ?(The only previous relevant discussion that I recall is one on
> > patches@eglibc.org starting at
> > <http://www.eglibc.org/archives/patches/msg01017.html>, regarding how the
> > dynamic linker should check that a library has the right ABI, and there
> > was no real followup on that after I indicated what would seem to be the
> > appropriate implementation approaches and places for subsequent
> > discussion.)
> 
> The patch above changes the loader to catch a mixed installation and
> reject mixing incompatible libraries.  The static linker does this
> currently but it's not essential.
> 
> > 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.
> 
> > (d) Existing practice for Power Architecture and MIPS at least is that
> > hard-float and soft-float *don't* use different library directories /
> > dynamic linkers.
> 
> The goal is to have a standard loader path for all hard float distros
> and, similar to how you can have a mixed 32/64 bit installation, allow
> mixed softfp/hard float installations for distros that want it.  This
> is a new requirement and ARM is the first one exposed to it.  I assume
> Debian would push for similar changes on MIPS and PowerPC.
> 
> Do the MIPS or PowerPC loaders detect the ABI and change the library
> path based on that?  I couldn't tell from the code.
> 
> > (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.
> 
> > 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.
> 
> > 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.
> 
> (BTW Dann, apologies for stealing your patch)

 s/stealing/improving upon/  :)

No worries, it is appreciated.

> -- Michael
> 
> 2012-04-03  Michael Hope  <michael.hope@linaro.org>
> 
>        * config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define.
>        (GLIBC_DYNAMIC_LINKER): Redefine to use the hard float path.
> 
> diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
> index 80bd825..8c9d2e7 100644
> --- a/gcc/config/arm/linux-eabi.h
> +++ b/gcc/config/arm/linux-eabi.h
> @@ -62,7 +62,11 @@
>  /* Use ld-linux.so.3 so that it will be possible to run "classic"
>     GNU/Linux binaries on an EABI system.  */
>  #undef  GLIBC_DYNAMIC_LINKER
> -#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.3"
> +#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "/lib/ld-linux.so.3"
> +#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT
> "/lib/arm-linux-gnueabihf/ld-linux.so.3"
> +#define GLIBC_DYNAMIC_LINKER \
> +   "%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
> +    %{!mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}"
> 
>  /* At this point, bpabi.h will have clobbered LINK_SPEC.  We want to
>     use the GNU/Linux version, not the generic BPABI version.  */


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