This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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: Relocations to use when eliding plts


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.

> 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.

	Jakub


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