This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH 0/9] PowerPC64 ELFv2 ABI support.
- From: Jack Carter <Jack dot Carter at imgtec dot com>
- To: "amodra at gmail dot com" <amodra at gmail dot com>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Mon, 4 Nov 2013 20:32:27 +0000
- Subject: Re: [PATCH 0/9] PowerPC64 ELFv2 ABI support.
- Authentication-results: sourceware.org; auth=none
Could you point me to the ELFv2 ABI documentation and has it been
registered anywhere official? My googling doesn't seem to be finding
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
> 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