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. */
next prev 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).