Re: [PATCH 0/9] PowerPC64 ELFv2 ABI support.

Re: [PATCH 0/9] PowerPC64 ELFv2 ABI support.

[Jack Carter]

Alan,

Could you point me to the ELFv2 ABI documentation and has it been 
registered anywhere official? My googling doesn't seem to be finding
it.

Thanks,

Jack

On 10/29/2013 07:19 PM, Alan Modra wrote:> This patch series makes the changes necessary in binutils to support
> the updated PowerPC64 ABI, which we're calling ELFv2.  Two major
> changes from the previous ABI are
> 
> - No function descriptors.
>    Functions set up their got/toc pointer as necessary on entry.  The
>    plt consists of single dword addresses.  Function pointers point at
>    the function code.  To make this work efficiently with static
>    linking, functions have *two* entry points, one we call the "global
>    entry" and another we call the "local entry".  The global entry
>    point is the address stored in function pointers, and it is a
>    requirement that calls to the global entry point have that address
>    in r12.  This is no hardship since calls via function pointers or
>    the plt will always use a sequence that loads the address into a
>    general purpose register, moves it to the count register, then
>    branches to the count register.  We just needed to make sure r12 was
>    the gpr used.  The "local entry" is used when the toc pointer is
>    known to already be valid for the function, typically true for
>    static linking, allowing the toc pointer setup to be skipped.
> 
> - Reduced stack frame size.
>    We removed the compiler and linker save words, and removed the
>    parameter save area for most functions.  This means the minimum
>    stack frame overhead is reduced from 112 bytes to 32 bytes (for
>    functions that need a frame), and many functions will used just the
>    minimum.  After some debate, we decided to keep the stack back-chain
>    word.
> 
> The ABI's are incompatible.  It won't be possible to link old objects
> with new except in rare cases, or to use old shared libraries with new
> executables at run time.
> 
> The first two patches in this series make changes that affect the old
> ABI too, the first one fixing a hole in the PowerPC64 ABI, and the
> second one makes all stubs conform with the ELFv2 ABI requirement on
> r12.
> 

Re: [PATCH 0/9] PowerPC64 ELFv2 ABI support.

[Alan Modra]

On Mon, Nov 04, 2013 at 08:32:27PM +0000, Jack Carter wrote:
> Could you point me to the ELFv2 ABI documentation and has it been 
> registered anywhere official? My googling doesn't seem to be finding
> it.

As I said in a previous email, the updated ABI document isn't ready
for general release yet.  I expect it will appear on power.org
eventually.

-- 
Alan Modra
Australia Development Lab, IBM

Re: [PATCH 0/9] PowerPC64 ELFv2 ABI support.

[Joseph S. Myers]

On Thu, 31 Oct 2013, Alan Modra wrote:

> On Wed, Oct 30, 2013 at 05:25:25PM +0000, Joseph S. Myers wrote:
> > On Wed, 30 Oct 2013, Alan Modra wrote:
> > 
> > > This patch series makes the changes necessary in binutils to support
> > > the updated PowerPC64 ABI, which we're calling ELFv2.  Two major
> > > changes from the previous ABI are
> > 
> > Is there an actual ABI document for this (or one with the old/new 
> > variations tagged appropriately like in the 32-bit unified ABI)?
> 
> There is, but it's not ready for general release yet, I think.

Thanks.  FWIW, in the Power.org ABI TSC there was a suggestion we should 
work on updating the 64-bit ABI (for things such as VSX) having got the 
32-bit one done, but nothing ever came of it.  (There was some work on 
adding VSX to the 32-bit ABI - on the vsx branch of 
git://github.com/ryanarn/powerabi - though this tailed off without us 
getting a 1.1 release out.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH 0/9] PowerPC64 ELFv2 ABI support.

[Alan Modra]

On Thu, Oct 31, 2013 at 12:49:58AM -0700, Matt Thomas wrote:
> 
> On Oct 29, 2013, at 7:19 PM, Alan Modra <amodra@gmail.com> wrote:
> 
> > This patch series makes the changes necessary in binutils to support
> > the updated PowerPC64 ABI, which we're calling ELFv2.  Two major
> > changes from the previous ABI are
> > 
> > - No function descriptors.
> 
> It would be nice if there was a similar ppc32 ABI which would make
> sharing code between ppc32 and ppc64 easier.

Well, yes..

> > The global entry
> >  point is the address stored in function pointers, and it is a
> >  requirement that calls to the global entry point have that address
> >  in r12.  
> 
> This sounds similar to ABICALLS on mips (where the function pointer
> is stored in $25 (t9) upon call entry).  That value is used to derive
> the $gp value by adding a constant (done by the linker) to the value
> in $25.

Yes.

>  One nice thing about the existing PPC64 ABI is that the toc 
> pointer is independent of the PC and thus you can the text and 
> non-text parts of a shareable library in independent parts of the 
> address space.  One shared segment can have  all the read-only text 
> segments and each process can have a private segment with the 
> read-write segments.  If you switch to add value to r12 to get the 
> toc, you can't share segments anymore.  

Another thing that was nice was no need for trampolines on the stack,
but we lose that when throwing out function descriptors.

> Unlike ABICALLS, I assume a plt is still used instead of fetching
> the address of each function from the GOT and doing an indirect call.

Right, but I'd like to try something like that on ELFv2 some day.
Since the code to do an indirect call shrinks a little with ELFv2,
inlining is more attractive.  I envisage a scheme where the compiler
emits the indirect call insns suitably marked so the linker can either
create a .plt entry (what we call .plt others call .got.plt), or edit
the indirect call back to a direct call as appropriate.

-- 
Alan Modra
Australia Development Lab, IBM

Re: [PATCH 0/9] PowerPC64 ELFv2 ABI support.

[Matt Thomas]

On Oct 29, 2013, at 7:19 PM, Alan Modra <amodra@gmail.com> wrote:

> This patch series makes the changes necessary in binutils to support
> the updated PowerPC64 ABI, which we're calling ELFv2.  Two major
> changes from the previous ABI are
> 
> - No function descriptors.

It would be nice if there was a similar ppc32 ABI which would make
sharing code between ppc32 and ppc64 easier.

> The global entry
>  point is the address stored in function pointers, and it is a
>  requirement that calls to the global entry point have that address
>  in r12.  

This sounds similar to ABICALLS on mips (where the function pointer
is stored in $25 (t9) upon call entry).  That value is used to derive
the $gp value by adding a constant (done by the linker) to the value
in $25.  One nice thing about the existing PPC64 ABI is that the toc 
pointer is independent of the PC and thus you can the text and 
non-text parts of a shareable library in independent parts of the 
address space.  One shared segment can have  all the read-only text 
segments and each process can have a private segment with the 
read-write segments.  If you switch to add value to r12 to get the 
toc, you can't share segments anymore.  

Unlike ABICALLS, I assume a plt is still used instead of fetching
the address of each function from the GOT and doing an indirect call.

Re: [PATCH 0/9] PowerPC64 ELFv2 ABI support.

[Alan Modra]

On Wed, Oct 30, 2013 at 05:25:25PM +0000, Joseph S. Myers wrote:
> On Wed, 30 Oct 2013, Alan Modra wrote:
> 
> > This patch series makes the changes necessary in binutils to support
> > the updated PowerPC64 ABI, which we're calling ELFv2.  Two major
> > changes from the previous ABI are
> 
> Is there an actual ABI document for this (or one with the old/new 
> variations tagged appropriately like in the 32-bit unified ABI)?

There is, but it's not ready for general release yet, I think.

> Are things changing that don't affect binutils (such as long double format 
> as suggested for little-endian in 
> <https://sourceware.org/ml/libc-alpha/2013-10/msg00597.html> - or the 

Long double is remaining as is for the time being, but I believe the
intent is to change to ieee128 at some point in the future.  More than
anything, it was time and resource constraints that prevented us
changing immediately.

> places where the function calling ABI is based on accidents of how GCC 
> assigned machine modes to structures, rather than being anything that was 
> particularly logically designed)?

The new ABI generally keeps the same conventions as the old one,
except that homgenous floating point or vector aggregates passed by
value will be passed in registers, and returned in registers if they
fit into 8 or fewer register.  We'll also return other structs up to a
certains size in general purpose registers.  So, yes, we'll be keeping
some accidents.

-- 
Alan Modra
Australia Development Lab, IBM

Re: [PATCH 0/9] PowerPC64 ELFv2 ABI support.

[Joseph S. Myers]

On Wed, 30 Oct 2013, Alan Modra wrote:

> This patch series makes the changes necessary in binutils to support
> the updated PowerPC64 ABI, which we're calling ELFv2.  Two major
> changes from the previous ABI are

Is there an actual ABI document for this (or one with the old/new 
variations tagged appropriately like in the 32-bit unified ABI)?

Are things changing that don't affect binutils (such as long double format 
as suggested for little-endian in 
<https://sourceware.org/ml/libc-alpha/2013-10/msg00597.html> - or the 
places where the function calling ABI is based on accidents of how GCC 
assigned machine modes to structures, rather than being anything that was 
particularly logically designed)?

-- 
Joseph S. Myers
joseph@codesourcery.com

[PATCH 0/9] PowerPC64 ELFv2 ABI support.

[Alan Modra]

This patch series makes the changes necessary in binutils to support
the updated PowerPC64 ABI, which we're calling ELFv2.  Two major
changes from the previous ABI are

- No function descriptors.
  Functions set up their got/toc pointer as necessary on entry.  The
  plt consists of single dword addresses.  Function pointers point at
  the function code.  To make this work efficiently with static
  linking, functions have *two* entry points, one we call the "global
  entry" and another we call the "local entry".  The global entry
  point is the address stored in function pointers, and it is a
  requirement that calls to the global entry point have that address
  in r12.  This is no hardship since calls via function pointers or
  the plt will always use a sequence that loads the address into a
  general purpose register, moves it to the count register, then
  branches to the count register.  We just needed to make sure r12 was
  the gpr used.  The "local entry" is used when the toc pointer is
  known to already be valid for the function, typically true for
  static linking, allowing the toc pointer setup to be skipped.

- Reduced stack frame size.
  We removed the compiler and linker save words, and removed the
  parameter save area for most functions.  This means the minimum
  stack frame overhead is reduced from 112 bytes to 32 bytes (for
  functions that need a frame), and many functions will used just the
  minimum.  After some debate, we decided to keep the stack back-chain
  word.

The ABI's are incompatible.  It won't be possible to link old objects
with new except in rare cases, or to use old shared libraries with new
executables at run time.

The first two patches in this series make changes that affect the old
ABI too, the first one fixing a hole in the PowerPC64 ABI, and the
second one makes all stubs conform with the ELFv2 ABI requirement on
r12.

-- 
Alan Modra
Australia Development Lab, IBM

  Report overflow on PowerPC64 @h and @ha relocations.
  Change plt stubs to have destination in r12.
  Add .abiversion related support for ELFv2
  Add ELFv2 .localentry support.
  ELFv2 stub, plt and glink changes
  Support ELFv2 stack frame.
  Replace DT_PPC_TLSOPT with DT_PPC_OPT.
  Add PowerPC64 ELFv2 tests.
  PowerPC64 ELFv2 support for gold.

 bfd/ChangeLog                       |   82 ++++
 bfd/bfd-in2.h                       |    6 +
 bfd/elf32-ppc.c                     |    2 +-
 bfd/elf64-ppc.c                     |  884 +++++++++++++++++++++++++----------
 bfd/libbfd.h                        |    6 +
 bfd/reloc.c                         |   12 +
 binutils/ChangeLog                  |   14 +
 binutils/readelf.c                  |   30 +-
 elfcpp/ChangeLog                    |   13 +
 elfcpp/powerpc.h                    |   61 ++-
 gas/ChangeLog                       |   27 ++
 gas/config/tc-ppc.c                 |  284 +++++++++--
 gas/config/tc-ppc.h                 |    3 +
 gold/ChangeLog                      |   47 ++
 gold/powerpc.cc                     |  668 +++++++++++++++++++-------
 include/elf/ChangeLog               |   24 +
 include/elf/ppc.h                   |    3 +-
 include/elf/ppc64.h                 |   73 ++-
 ld/testsuite/ChangeLog              |   29 ++
 ld/testsuite/ld-powerpc/elfv2.s     |   32 ++
 ld/testsuite/ld-powerpc/elfv2exe.d  |   40 ++
 ld/testsuite/ld-powerpc/elfv2so.d   |   82 ++++
 ld/testsuite/ld-powerpc/powerpc.exp |    2 +
 ld/testsuite/ld-powerpc/relbrlt.d   |    8 +-
 ld/testsuite/ld-powerpc/tls.d       |    4 +-
 ld/testsuite/ld-powerpc/tls.g       |    6 +-
 ld/testsuite/ld-powerpc/tls.s       |    7 +-
 ld/testsuite/ld-powerpc/tlsexe.d    |   23 +-
 ld/testsuite/ld-powerpc/tlsexe.g    |    2 +-
 ld/testsuite/ld-powerpc/tlsexe.r    |   56 +--
 ld/testsuite/ld-powerpc/tlsexetoc.d |   23 +-
 ld/testsuite/ld-powerpc/tlsexetoc.g |    2 +-
 ld/testsuite/ld-powerpc/tlsexetoc.r |   58 +--
 ld/testsuite/ld-powerpc/tlsso.d     |   25 +-
 ld/testsuite/ld-powerpc/tlsso.g     |    2 +-
 ld/testsuite/ld-powerpc/tlsso.r     |   60 +--
 ld/testsuite/ld-powerpc/tlstoc.d    |    4 +-
 ld/testsuite/ld-powerpc/tlstoc.g    |   12 +-
 ld/testsuite/ld-powerpc/tlstoc.s    |    7 +-
 ld/testsuite/ld-powerpc/tlstocso.d  |   25 +-
 ld/testsuite/ld-powerpc/tlstocso.g  |    2 +-
 ld/testsuite/ld-powerpc/tlstocso.r  |   62 +--
 42 files changed, 2166 insertions(+), 646 deletions(-)
 create mode 100644 ld/testsuite/ld-powerpc/elfv2.s
 create mode 100644 ld/testsuite/ld-powerpc/elfv2exe.d
 create mode 100644 ld/testsuite/ld-powerpc/elfv2so.d