Re: [PATCH, rs6000] ELFv2 ABI 1/8: Add options and infrastructure

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Joseph Myers wrote:
> On Mon, 11 Nov 2013, Ulrich Weigand wrote:
> > The ELFv2 ABI is the intended ABI for the new powerpc64le-linux port.
> > However, it is not inherently tied to the byte order; it it possible
> > in principle to use the ELFv2 ABI in big-endian mode too.
> 
> I'd rather, from a glibc perspective, keep down the number of variant ABIs 
> available - and in particular, disallow the (ELFv1, little-endian 
> combination) - have a compiler error given for it.  And, similarly, have 
> the (ELFv2, big-endian) combination only if the plan is for it to obsolete 
> the old ABI and for support for the old ABI for powerpc64-linux to be 
> removed from GCC and glibc in a few years' time (similarly to how the ARM 
> EABI superseded the old arm-linux-gnu ABI).  If you don't have such errors 
> in GCC, then you should have configure-time errors in glibc to disallow 
> the unsupported combinations.

Right now, we're only planning to support the existing ELFv1 big-endian
and the new ELFv2 little-endian versions.  The others are really only
present for testing purposes; note that rs6000 GCC already has a number
of ABI options that are really not intended for the end-user to play with.

It's indeed probably better to move the options to the formally undefined
category so that every use gets you a warning ...

> (Any new supported glibc configuration should of course set minimum symbol 
> version to GLIBC_2.19, or whatever the version is of the first release 
> supporting it - and the dynamic linker / ldconfig should distinguish 
> shared libraries for the two variants.)

I've just posted the ELFv2 ABI glibc patch set to libc-alpha.
 
> I didn't see anything in this series regarding the ELFv1 ABI feature 
> that's the greatest pain from a glibc perspective - the use of IBM long 
> double.  The idea of moving to IEEE binary128 was floated in 
> <https://sourceware.org/ml/libc-alpha/2013-10/msg00597.html> - have you 
> abandoned that idea?  Obviously it would be bad to end up having two 
> variants of ELFv2 with different long double formats.  (Though we can't 
> actually eliminate IBM long double support from glibc unless all ABIs with 
> it are obsoleted, including 32-bit.)  If you do move to IEEE binary128 I'd 
> advise simply using soft-fp in libgcc for the functions that normally go 
> in libgcc, given that 64-bit implies hard float, rather than the 
> arrangements some targets have of putting their binary128 functions in 
> glibc.

Well, we had been thinking about this, but right now it seems we're not
going to be able to make that change throughout the ecosystem quickly
enough, so for now, it'll probably have to remain the IBM long double.

> > Therefore, it is introduces via a new pair of options
> >    -mabi=elfv1 / -mabi=elfv2
> > where -mabi=elfv1 select the current Linux ABI, and -mabi=elfv2
> > selects the new one.
> 
> New command-line options need invoke.texi documentation.

As mentioned above, it's probably best to mark it undocumented.

> > (Of course, patches to binutils, glibc, and libffi to support the
> > new ELFv2 ABI are also required.)
> 
> And GDB - GDB needs to know how to call functions, how to pass arguments 
> to them and how to find the return value.

Yes, of course; GDB is next on the list, once the core toolchain is
operational :-)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com