public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
From: dann frazier <dann.frazier@canonical.com>
To: Michael Hope <michael.hope@linaro.org>
Cc: "Joseph S. Myers" <joseph@codesourcery.com>,
	Richard Earnshaw <rearnsha@arm.com>,
	"cross-distro@lists.linaro.org" <cross-distro@lists.linaro.org>,
	"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	libc-ports@sourceware.org
Subject: Re: [PATCH] ARM: Use different linker path for hardfloat ABI
Date: Thu, 05 Apr 2012 01:32:00 -0000	[thread overview]
Message-ID: <20120405013238.GF29588@dannf.org> (raw)
In-Reply-To: <CANLjY-kc0g753QNDSO28QOFdfDBuG=yC91K49p+d874-sTHXaw@mail.gmail.com>

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.  */

  parent reply	other threads:[~2012-04-05  1:32 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20120329193401.GA14860@dannf.org>
     [not found] ` <4F75F2E2.3030909@arm.com>
     [not found]   ` <20120402210653.GC28152@dannf.org>
     [not found]     ` <CANLjY-nk7ML5QMBd0bKRJBA9stUOdvu1tWZqmFHxpRzObzFw1Q@mail.gmail.com>
2012-04-03 22:56       ` Joseph S. Myers
2012-04-04  2:40         ` Michael Hope
2012-04-04  9:06           ` Joseph S. Myers
2012-04-04 12:10             ` Dennis Gilmore
2012-04-05 13:30               ` Konstantinos Margaritis
2012-04-05 14:13                 ` Niels de Vos
2012-04-05 15:08                 ` Mike Frysinger
2012-04-05 15:24                   ` Konstantinos Margaritis
2012-04-05 15:55                     ` Mike Frysinger
2012-04-05 16:25                       ` Konstantinos Margaritis
2012-04-10  4:10                         ` Mike Frysinger
2012-04-05 16:16                   ` Steve McIntyre
2012-04-05 17:36                     ` Mike Frysinger
2012-04-04 23:33             ` Michael Hope
2012-04-05  0:07               ` Joseph S. Myers
2012-04-05  1:17                 ` Michael Hope
2012-04-05 16:05                   ` Steve McIntyre
2012-04-05 16:03               ` Steve McIntyre
2012-04-05  1:32           ` dann frazier [this message]
2012-04-05 14:57         ` Steve McIntyre
2012-04-10 20:31         ` Carlos O'Donell
     [not found] <4F7AC2E1.6010000@redhat.com>
     [not found] ` <4F7AD4CA.8010000@arm.com>
     [not found]   ` <20120403110140.GG16117@tyan-ft48-01.lab.bos.redhat.com>
     [not found]     ` <4F7B20D2.8060608@arm.com>
     [not found]       ` <4F7B227F.7060905@redhat.com>
     [not found]         ` <CANLjY-mDvnn8NcVQfYoUUGZD72GbH7mgYjxWOGOzLMiUwNyp2Q@mail.gmail.com>
     [not found]           ` <20120403231133.GI16117@tyan-ft48-01.lab.bos.redhat.com>
     [not found]             ` <CANLjY-=dGK05kzvHVkuo3o7p_iE1cxfTi0f+t-RMmGW+37WSEg@mail.gmail.com>
     [not found]               ` <CAHAq8pE48=eY77adiKz3PEBapXwkPn6rjr3viMoUKpJq4x-G_A@mail.gmail.com>
     [not found]                 ` <CANLjY-k-sC86gmaTH+h-5o4_D2MOnQHB4ihhDhoPt1HbUzJp9w@mail.gmail.com>
     [not found]                   ` <20120404065412.GJ16117@tyan-ft48-01.lab.bos.redhat.com>
2012-04-04  9:16                     ` Joseph S. Myers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120405013238.GF29588@dannf.org \
    --to=dann.frazier@canonical.com \
    --cc=cross-distro@lists.linaro.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    --cc=libc-ports@sourceware.org \
    --cc=michael.hope@linaro.org \
    --cc=rearnsha@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).