[committed, PATCH] PR ld/18289: Support copy relocation in PIE
H.J. Lu
hjl.tools@gmail.com
Wed Apr 22 23:24:00 GMT 2015
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.
More information about the Binutils
mailing list