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: Jakub Jelinek <jakub at redhat dot com>
- To: Rich Felker <dalias at libc dot org>
- 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 21:40:57 +0200
- 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>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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