This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH 0/9] PowerPC64 ELFv2 ABI support.
- From: Alan Modra <amodra at gmail dot com>
- To: Matt Thomas <matt at 3am-software dot com>
- Cc: binutils at sourceware dot org
- Date: Thu, 31 Oct 2013 23:24:57 +1030
- Subject: Re: [PATCH 0/9] PowerPC64 ELFv2 ABI support.
- Authentication-results: sourceware.org; auth=none
- References: <20131030021905 dot GC20756 at bubble dot grove dot modra dot org> <E54E8164-BC35-45D0-8349-340BDA4697A0 at 3am-software dot com>
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