From: Nicholas Piggin <npiggin@gmail.com>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: Segher Boessenkool <segher@kernel.crashing.org>,
Oliver O'Halloran <oohall@gmail.com>,
linuxppc-dev@lists.ozlabs.org, Alan Modra <amodra@gmail.com>
Subject: Re: [RFC][PATCH] powerpc/64be: use ELFv2 ABI for big endian kernels
Date: Fri, 25 Nov 2016 13:35:59 +1100 [thread overview]
Message-ID: <20161125133559.21461ca1@roar.ozlabs.ibm.com> (raw)
In-Reply-To: <8737igtip8.fsf@concordia.ellerman.id.au>
On Fri, 25 Nov 2016 13:08:19 +1100
Michael Ellerman <mpe@ellerman.id.au> wrote:
> Nicholas Piggin <npiggin@gmail.com> writes:
>
> > On Thu, 24 Nov 2016 17:17:16 -0600
> > Segher Boessenkool <segher@kernel.crashing.org> wrote:
> >
> >> On Fri, Nov 25, 2016 at 09:22:16AM +1100, Michael Ellerman wrote:
> >> > >> >> Question, are there any fundamental reasons we shouldn't use the ELFv2
> >> > >> >> ABI to build big endian kernels if the compiler supports it?
> >> > >> >
> >> > >> > No one uses ELFv2 for BE in production, and it isn't thoroughly tested
> >> > >> > at all, not even regularly tested. "Not supported", as far as GCC is
> >> > >> > concerned (or any of the distros AFAIK).
> >> > >>
> >> > >> Is this actually unsupported by gcc?
> >> > >
> >> > > It may or may not work. We of course try to keep it working, or make
> >> > > it work if it doesn't now. But it isn't regularly tested, and it isn't
> >> > > a target that is considered for the release criteria (see
> >> > > https://gcc.gnu.org/gcc-7/criteria.html -- powerpc64{,le}-linux, i.e.
> >> > > ABIv1 for BE, ABIv2 for LE).
> >> >
> >> > It doesn't actually say that though. It just says
> >> > powerpc64-unknown-linux-gnu. So how is someone, say the musl folks,
> >> > supposed to know that BE ABIv2 is not supported?
> >>
> >> Because their target is powerpc64*-*-linux-musl instead? It is not on
> >> the release criteria list, it is not something we make any claims about.
> >>
> >> How would you know -m32 -mlittle is not well tested at all? It is in much
> >> the same boat: unusual combinations of options, and unusual configurations,
> >> are not well tested. You have to build a separate C library just to get
> >> started with it, that should tell you there are some rough waters ahead!
> >>
> >> Which isn't to say you should not do this -- just think twice before
> >> doing so. And wear a life vest.
> >
> > Other than curiosity, only two reasons for the kernel to enable it:
> > either it helps end users, or it allows us to get rid of elfv1 support
> > (eventually). Both would require gcc to have some base amount of testing.
>
> I think it might be worth adding as option, as long as it's not too
> intrusive. We could then put it in our CI and at least keep an eye on
> whether it continues to work.
If you're willing to take it, sure. I'll resubmit it with a default-n
config option hidden away somewhere.
>
> Using ABIv1 does have user visible effects, ie. dot symbols show up in
> traces and so on. So getting rid of that would be nice.
>
> Having said that, perf and other tools are currently built to assume
> BE==ABIv1, so breaking that assumption would possibly cause more
> trouble.
We can make it clear it's experimental/not supported, but things like
that could probably be cleaned up slowly. They should depend on elf
version rather than endian anyway.
>
> I guess the other question is when did ABIv2 land in the toolchain, ie.
> how many years do we have to wait until we can mandate it.
I think gcc 4.9, binutils 2.24, early 2014.
But if we've never been testing with those older toolchains we're a bit
behind the 8 ball. Still, the second best time to plant the tree is now...
Thanks,
Nick
next prev parent reply other threads:[~2016-11-25 2:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-23 13:08 [RFC][PATCH] powerpc/64be: use ELFv2 ABI for big endian kernels Nicholas Piggin
2016-11-23 14:20 ` Balbir Singh
2016-11-23 14:38 ` Segher Boessenkool
2016-11-24 4:42 ` Nicholas Piggin
2016-11-24 5:37 ` Oliver O'Halloran
2016-11-24 12:27 ` Segher Boessenkool
2016-11-24 22:22 ` Michael Ellerman
2016-11-24 23:17 ` Segher Boessenkool
2016-11-25 1:13 ` Nicholas Piggin
2016-11-25 2:08 ` Michael Ellerman
2016-11-25 2:35 ` Nicholas Piggin [this message]
2016-11-25 3:35 ` Michael Ellerman
2016-11-25 2:02 ` Michael Ellerman
2016-11-25 14:59 ` Segher Boessenkool
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=20161125133559.21461ca1@roar.ozlabs.ibm.com \
--to=npiggin@gmail.com \
--cc=amodra@gmail.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=oohall@gmail.com \
--cc=segher@kernel.crashing.org \
/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 NNTP newsgroup(s).