This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH, rs6000] ELFv2 ABI 1/8: Add options and infrastructure
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 11 Nov 2013 23:04:22 +0000
- Subject: Re: [PATCH, rs6000] ELFv2 ABI 1/8: Add options and infrastructure
- Authentication-results: sourceware.org; auth=none
- References: <201311111440 dot rABEem5T003872 at d06av02 dot portsmouth dot uk dot ibm dot com>
On Mon, 11 Nov 2013, Ulrich Weigand wrote:
> this is the first patch in the series to add support for the ELFv2 ABI.
> 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.
(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 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
> 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.
> (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.
Joseph S. Myers