[RFC][PATCH] powerpc/64be: use ELFv2 ABI for big endian kernels

[Nicholas Piggin]

On Fri, 25 Nov 2016 13:08:19 +1100
Michael Ellerman <mpe at ellerman.id.au> wrote:

> Nicholas Piggin <npiggin at gmail.com> writes:
> 
> > On Thu, 24 Nov 2016 17:17:16 -0600
> > Segher Boessenkool <segher at 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