This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Relocations to use when eliding plts
- From: Rich Felker <dalias at libc dot org>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Richard Henderson <rth at redhat dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, IA32 System V Application Binary Interface <ia32-abi at googlegroups dot com>, "x86-64-abi at googlegroups dot com" <x86-64-abi at googlegroups dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Binutils <binutils at sourceware dot org>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Thu, 28 May 2015 16:36:00 -0400
- Subject: Re: Relocations to use when eliding plts
- Authentication-results: sourceware.org; auth=none
- References: <5566232B dot 4080904 at redhat dot com> <CAMe9rOq57A1ksRfn95GTzfc_dFzjPjEzuqswqC8Xu-M62g_Z2g at mail dot gmail dot com> <CAMe9rOpRHqvpJMDSyXk8XrNu04aytCDPnBB03B9A1iSTk=ZhPQ at mail dot gmail dot com> <5567345B dot 5020808 at redhat dot com> <20150528175941 dot GV17573 at brightrain dot aerifal dot cx> <55676146 dot 6040304 at redhat dot com> <20150528192901 dot GW17573 at brightrain dot aerifal dot cx> <20150528194057 dot GS10247 at tucnak dot redhat dot com>
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