This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] PowerPC64 ELFv2 ABI 2/6: Remove function descriptors
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: joseph at codesourcery dot com (Joseph S. Myers), amodra at gmail dot com
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 13 Nov 2013 16:30:28 +0100 (CET)
- Subject: Re: [PATCH] PowerPC64 ELFv2 ABI 2/6: Remove function descriptors
- Authentication-results: sourceware.org; auth=none
Joseph Myers wrote:
> On Tue, 12 Nov 2013, Ulrich Weigand wrote:
>
> > In addition, the dynamic linker now verifies that the dynamic libraries
> > it loads match its own ABI.
>
> Could you confirm that all old (ELFv1) binaries, regardless of what
> vintage binutils generated them, will have the EF_PPC64_ABI bits set to 1,
> so that they will be rejected by your check?
Well, binaries generated by vintage binutils will have EF_PPC64_ABI
bits set to 0, unfortunately.
We went back-and-forth a bit on this issue during development. The problem
is that really only the compiler explicitly makes a choice (whether by
default or due to command line option) on the ELFv1/ELFv2 ABI version.
Assembler and linker need to deduce the ABI from information they find
in the assembler source / object file. In some cases that's obvious:
if .opd is used, it must be ELFv1; if .localentry is used, it must
be ELFv2. And of course, an explicit .abiversion will enforce a
particular version.
However, there are assembler files where none of this applies. This is
typically files that define only data objects. We had thought to maybe
force these to use .abiversion, but it turns out that this would have
required annoying changes (even in glibc we have platform-independent
assembler source files defining data --- these would have had to be
patched with powerpc-specific code), for no real good reason: such
files (data only) are actually compatible with either ABI anyway!
So in the end we decided to make EF_PPC64_ABI tri-state, with state 0
indicating files compatible with either ABI.
This does mean that in theory, binaries generated with an old linker
will have EF_PPC64_ABI 0 and will not be rejected by the check above.
I don't think this should be a big issue in practice, since we will
only support ELFv1 on BE and ELFv2 on LE, so the architecture check
will reject them already anyway ...
(CC'ing Alan in case he has additional comments on the binutils side.)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com