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 3/6: PLT local entry point


On Tue, 2013-11-19 at 02:49 +0100, Ulrich Weigand wrote:
> Steven Munroe wrote:
> > 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.
> 
> Actually, this is about which value is installed into the PLT, so the
> optimization causes the local entry point to be used on *every*
> successive call via the PLT, not just the first.  (I certainly
> agree that if it were for the first call only, it wouldn't be a win.)
> 
Ah excellent! The optimization applies to subsequent intra-module calls.

Ok this patch is fine.



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