Relocations to use when eliding plts
Rich Felker
dalias@libc.org
Thu May 28 20:36:00 GMT 2015
On Thu, May 28, 2015 at 09:40:57PM +0200, Jakub Jelinek wrote:
> On Thu, May 28, 2015 at 03:29:02PM -0400, Rich Felker wrote:
> > > You're not missing anything. But do you want the performance of a
> > > library to depend on how the main executable is compiled?
> >
> > Not directly. But I'd rather be in that situation than have
> > pessimizations in library codegen to avoid it. I'm worried about cases
> > where code both loads the address of a function and calls it, such as
> > this (stupid) example:
> >
> > a((void *)a);
>
> That can be handled by using just one GOT slot, the non-.got.plt one;
> only if there are only relocations that guarantee that address equality is
> not important it would use the faster (*_JUMP_SLOT?) relocations.
How far would this extend, e.g. in the case of LTO or compiling the
whole library at once?
> > In my vision, main programs are always or almost-always (e.g. just
> > exceptions for stuff like emacs) PIE and the PLT-in-main-program issue
> > is a non-issue, so I don't want to risk hurting codegen on the library
> > side just to make a legacy usage (non-PIE) mildly more efficient.
>
> Calling non-PIEs legacy is maybe your vision, but there will always be a very
> good reason for non-PIEs. And, even PIEs don't really help you, there is no
> reason why even in PIEs code couldn't use (if it doesn't already) RIP
> relative relocations for functions not known to be defined in the current
> TU; it can just refer to the PLT slots like it does in non-PIE binaries.
I agree completely. I don't think support for non-PIE should be
removed for anything, just that if there are tradeoffs between
optimizing non-PIE and optimizing PIE/PIC, we should opt for the
latter since it's the direction things should take moving forward.
Rich
More information about the Binutils
mailing list