Re: [committed, PATCH] PR ld/18289: Support copy relocation in PIE

["H.J. Lu" <hjl dot tools at gmail dot com>]

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.