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: Richard Henderson <rth at redhat dot com>
- Cc: "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 15:29:02 -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>
On Thu, May 28, 2015 at 11:41:10AM -0700, Richard Henderson wrote:
> On 05/28/2015 10:59 AM, Rich Felker wrote:
> >Am I missing something?
>
> 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);
Would having separate handling of the address-for-call and
address-for-function-pointer result in the compiler emitting 2
separate GOT loads (and consuming 2 registers) here in an effort to
avoid the possibility of inefficiency from a PLT thunk in the main
program?
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.
Rich