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

[Joerg Sonnenberger via llvm-commits]

On Sat, May 07, 2016 at 05:39:15PM -0700, Xinliang David Li wrote:
> On Sat, May 7, 2016 at 11:52 AM, Joerg Sonnenberger via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
> 
> > On Sat, May 07, 2016 at 10:58:51AM -0700, Xinliang David Li via
> > llvm-commits wrote:
> > > To be clear, assuming copyrelocs (support in linker) allows compiler to
> > > generate efficient code (speculatively) to access external globals which
> > > compiler has no idea where they are going to be defined. For most of the
> > > cases, the most of globals end up in the main program, so copyrelocs is
> > > only a fallback mechanism in case that is not the case.
> >
> > I think your reasoning is confusing cause and effect. Copy relocations
> > exist, because people didn't want to change things when shared linkage
> > was introduced.
> 
> 
> What do you mean by 'people didn't want to change things'?

Exactly what I wrote. Static linkage was the default, then patching with
XCOFF. ELF's mechanism are late to the game. Copy relocations are a
result of wanting to mix non-position independent main binaries with
shared libraries.

> For executable, copy reloc is introduced so that global access without GOT
> can be used without requiring text relocation when the reference is truly
> external.  Are you saying this is not the case?  History aside, this is
> certainly how copyreloc is used today.

Code generated without -fPIC on most architectures doesn't use the GOT.
That means the link editor has to be patch things up as best as it can
to make it use shared libraries. Two direct results from this are:
(1) Variables defined in shared objects must be relocated to the main
binary, when referenced from this.
(2) The identify of functions is the PLT slot of the main binary, when
referenced.

Both issues have a long history of creating compatibility and
performance issues. 

> > It is a horrible hack and everyone seriously involved
> > with ELF acknowledges that it is a horrible hack only comparible to text
> > relocatiions
> 
> 
> You can certainly feel this way, but making claims about 'everyone involved
> ..' seems to have no basis and is not relevant here.

I don't see anyone disagreeing... I'm still surprised that binutils is
willing to restore this crap, but given their history of I shouldn't be.
I would certainly hope that Rui et al have a difference stance on repeat
the mistakes of the past here. If you want to see a good example of why
copy relocations are bad, look for the recent "libc++'s cout getting
aligned differently" bug in clang. That's a wonderful example of the
kind of issues copy relocations and where they hurt performance much
more than any advantage they ever produce.

So let me repeat: if you want to get the performance benefits of
non-interposable references, work on making protected actually usable.
This includes the more important dllimport side. That's useful not just
for the special case of the main binary, but can be used for shared
libraries as well. It is something where code in the wild is already
known to exploit the lack of copy relocations for PIE. Do not add copy
relocations back.

Joerg