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

[Joerg Sonnenberger via llvm-commits]

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.

> > It is also
> > clear that you do not even want to look at the *existing* alternatives.
> >
> 
> Wrong assertion. If we can get back to technical discussions without
> resorting to attacking, that will be great.  You can lay down your
> proposals in more details and compare pros/cons of different alternatives.
> We need a solution that is generally good and easy for users (including the
> lazy programmers you referred ) to use.  Also what are the main pain points
> of copyreloc to you? slower startup time or something else?

I already gave you the better alternatives. Mark the relevant symbol as
hidden (works in the majority of the cases) or protected (works in the
remaining cases). Whole program analysis could do that automatically. 
It would be nice if library headers where using visibility pragmas
consistently, so that -fvisibility=hidden as default worked without
wrapper hacks like those used by Firefox. Even without that, it is
normally quite easy to change even larger projects to consistently
define variables in the main binaries as static or hidden in the
corresponding headers.

Copy relocations have never been about performance, they exist purely
out of necessity. They are the little brother of text relocations -- one
is the kind of the fix for the other. They introduce hidden ABI
contracts, they muddle up ownership, they are the reason why using
protected symbols in libraries is difficult. They break code using
symbolic linkage and users of *that* like newer Qt5 programs explicitly
depend on PIE never using copy relocations.

I am highly suspicious of the one number mentioned so far in this thread
to justify the patch. The overead of PIE goes beyond the unfoldable
address access. Especially for shorter test cases, the pure number of
additional relocations is enough to easily explain 4% performance
difference. 

Joerg