[llvm-dev] [lld] avoid emitting PLT entries for ifuncs

Joerg Sonnenberger via llvm-dev llvm-dev at lists.llvm.org
Wed Aug 22 06:20:31 PDT 2018


On Tue, Aug 21, 2018 at 07:50:16PM -0400, Mark Johnston via llvm-dev wrote:
> On Tue, Aug 21, 2018 at 11:14:02PM +0200, Joerg Sonnenberger wrote:
> > On Tue, Aug 21, 2018 at 09:47:41AM -0400, Mark Johnston via llvm-dev wrote:
> > > We've recently started using ifuncs in the x86(_64) FreeBSD kernel.
> > > Currently lld will emit a PLT entry for each ifunc, so ifunc calls are
> > > more expensive that those of regular functions.
> > 
> > If you rewrite the PLT entry to be a plain jump whenever possible, the
> > difference should be pretty small. Have you considered that?
> 
> I considered it, but don't like it as much: for each supported CPU
> architecture we would need code to find the PLT entry referencing the
> GOT entry being relocated, verify that the entry contains the
> instruction(s) that we expect, and write the plain jump.  For my
> approach the kernel linker will just do the right thing for each CPU
> architecture without requiring any magic.  Having support in the static
> linker means that the optimization is less fragile, and we do not incur
> the cost of the extra jump.  It may be that other projects can benefit
> as well, and as I mentioned, I think there are other use-cases for
> similar functionality.

I don't buy that argument. On the linker side, it is a custom hack for
something that is generally considered very bad nowadays: text
relocations. The PLT handling is already platform specific and some
platforms like SPARC do exactly this kind of PLT creation already.
In fact, with the recent popularity of non-lazy binding, it would make
sense to have wider support for it as it removes on one of the
performance penalties with dynamic linking. The cost of the extra jump
should be pretty low in general.

Joerg


More information about the llvm-dev mailing list