This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] PowerPC64 ELFv2 ABI 2/6: Remove function descriptors


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]