This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] PowerPC64 ELFv2 ABI 3/6: PLT local entry point optimization
- From: Steven Munroe <munroesj at linux dot vnet dot ibm dot comcom>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 18 Nov 2013 19:44:07 -0600
- Subject: Re: [PATCH] PowerPC64 ELFv2 ABI 3/6: PLT local entry point optimization
- Authentication-results: sourceware.org; auth=none
- References: <201311122122 dot rACLMDlI018949 at d06av02 dot portsmouth dot uk dot ibm dot com>
- Reply-to: munroe at us dot ibm dot com
On Tue, 2013-11-12 at 22:22 +0100, Ulrich Weigand wrote:
> Hello,
>
> this is a follow-on to the previous patch to support the ELFv2 ABI in the
> dynamic loader, split off into its own patch since it is just an optional
> optimization.
>
> In the ELFv2 ABI, most functions define both a global and a local entry
> point; the local entry requires r2 to be already set up by the caller
> to point to the callee's TOC; while the global entry does not require
> the caller to know about the callee's TOC, but it needs to set up r12
> to the callee's entry point address.
>
> Now, when setting up a PLT slot, the dynamic linker will usually need
> to enter the target function's global entry point. However, if the
> linker can prove that the target function is in the same DSO as the
> PLT slot itself, and the whole DSO only uses a single TOC (which the
> linker will let ld.so know via a DT_PPC64_OPT entry), then it is
> possible to actually enter the local entry point address into the
> PLT slot, for a slight improvement in performance.
>
Would it simplify things if the dynamic linker always transferred to
control to the global entry point. As this is only first call to each
PLT entry, and only for self calls, it is not clear that calling the
local entry point actually saves cycles considering the extra logic in
pc64_local_entry_offset.
> Note that this uncovered a problem on the first call via _dl_runtime_resolve,
> because that routine neglected to restore the caller's TOC before calling
> the target function for the first time, since it assumed that function
> would always reload its own TOC anyway ...
>
> Tested on powerpc64-linux and powerpc64le-linux.
>
> OK for mainline?
Otherwise OK.