[PATCH] D19995: Optimize access to global variable references in PIE mode when linker supports copy relocations for PIE

[Cary Coutant via llvm-commits]

On Sun, May 8, 2016 at 5:56 PM, Xinliang David Li <xinliangli at gmail.com> wrote:
>
> On Sun, May 8, 2016 at 5:04 PM, Joerg Sonnenberger via llvm-commits
> <llvm-commits at lists.llvm.org> wrote:
>>
>> On Sun, May 08, 2016 at 04:31:08PM -0700, Xinliang David Li wrote:
>> > Do not expect people to agree with you because of the strong words used
>> > throughout the discussions: horrible, everyone dislikes etc.
>>
>> Copy relocations are pretty much universally agreed to be one of the
>> biggest historic problems in ELF. Period. Just because they are a
>> necessary evil for "old-style" main binaries doesn't mean they should be
>> ever extended beyond that. The situation is really as simple as that.
>
> You are repeating yourself without references.  Just to verify, I have cc'ed
> Ian and Cary who have been in this area for long time who may know history
> -- not that debating the history really is relevant here.

I agree that copy relocations are a big problem. I wouldn't go so far
as to say that it's an "ELF" problem, though -- it's just an ABI
problem. We managed to avoid them on PA-RISC and Itanium by generating
"half-PIC" code for any reference not known to be local to the main
program, and the linker could replace the extra load with a copy or
no-op instruction, eliminating most of the performance penalty of the
PIC code.

That said, they are something we have to live with on many platforms,
at least for the present. You seem to have touched on some of the
alternatives, but I don't really see enough context here to be able to
respond fully.

It sounds like Joerg is objecting to your LLVM patch that makes
generate direct references to data symbols in PIE mode (just like
non-PIE-non-PIC mode), on the grounds that there are applications that
expect apps built in PIE mode to never have copy relocations. I can
sympathize with that, but I don't know of any good rationale for that
expectation other than an accident of implementation -- PIE means that
the code is being compiled for a main executable, which means symbols
are non-preemptible, and there's no reason why the compiler shouldn't
take advantage of that just as it does in non-PIE mode. I don't think
there's any other real difference between code gen for PIE and PIC, so
it seems to me that anyone who wants to avoid copy relocations should
compile with PIC -- they can still link with PIE even when compiling
with PIC.

(Maybe I'm missing some other critical difference between PIE and PIC,
but I'm about to head out of town, and I'm typing hastily. I'll try to
reply more in depth when I return on Wednesday. In the meantime, a
little more context would help!)

-cary