This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [committed, PATCH] PR ld/18289: Support copy relocation in PIE
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Binutils <binutils at sourceware dot org>
- Date: Wed, 22 Apr 2015 16:24:06 -0700
- Subject: Re: [committed, PATCH] PR ld/18289: Support copy relocation in PIE
- Authentication-results: sourceware.org; auth=none
- References: <20150422123523 dot GA26347 at intel dot com> <20150422230805 dot GK12627 at bubble dot grove dot modra dot org>
On Wed, Apr 22, 2015 at 4:08 PM, Alan Modra <amodra@gmail.com> wrote:
> On Wed, Apr 22, 2015 at 05:35:23AM -0700, H.J. Lu wrote:
>> This patch allows copy relocs for R_386_GOTOFF relocations in PIE. For
>>
>> extern int glob_a;
>> int foo ()
>> {
>> return glob_a;
>> }
>>
>> compiler now can optimize it from
>>
>> call __x86.get_pc_thunk.ax
>> addl $_GLOBAL_OFFSET_TABLE_, %eax
>> movl glob_a@GOT(%eax), %eax
>> movl (%eax), %eax
>> ret
>>
>> to
>>
>> call __x86.get_pc_thunk.ax
>> addl $_GLOBAL_OFFSET_TABLE_, %eax
>> movl glob_a@GOTOFF(%eax), %eax
>> ret
>
> Did you consider doing this code transformation in the linker? I
> guess it's not so easy with variable length instructions, and you
> would be left with a couple of nops.
There can be
movl optopt@GOT(%ecx), %eax
addl $4, (%eax,%edx,4)
or
movl optopt@GOT(%ecx), %eax
movl $4, (%eax,%edx,4)
...
There are so many variants and there also can be instructions
between them.
> There are quite a few advantages of doing this in the linker:
> - Optimization becomes available to people who must use an older gcc
> for some reason.
> - No need to make gcc or glibc changes.
No glibc change is needed.
> - No need to update all of ld, gcc, and glibc simultaneously for
> correctness. A partial update will cause some testcases that worked
> correctly with an older toolchain to misbehave.
GCC optimization is enabled only if linker supports it.
> - People can choose to use protected visibility in shared libraries to
> get an identical speedup in the shared library to that you show
> above. With your gcc changes, protected visibility variables in
> shared libraries no longer have a speed advantage, which is a
> regression.
Protected data isn't an issue here since protected data in PIE is treated
the same as normal data.
--
H.J.