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
