From: "Joseph S. Myers" <joseph@codesourcery.com>
To: Michael Hope <michael.hope@linaro.org>
Cc: dann frazier <dann.frazier@canonical.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 00:07:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.64.1204050003140.26727@digraph.polyomino.org.uk> (raw)
In-Reply-To: <CANLjY-mj8CHmxGoAt5Z3jOoFyA3O4-dxVZ9RRb78K57K-wssWg@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1938 bytes --]
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
next prev parent reply other threads:[~2012-04-05 0:07 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 [this message]
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
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=Pine.LNX.4.64.1204050003140.26727@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=cross-distro@lists.linaro.org \
--cc=dann.frazier@canonical.com \
--cc=gcc-patches@gcc.gnu.org \
--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).