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

[Joerg Sonnenberger via llvm-commits]

On Mon, May 09, 2016 at 05:13:35AM +0000, John McCall via llvm-commits wrote:
> rjmccall added a comment.
> 
> In http://reviews.llvm.org/D19995#424356, @joerg wrote:
> 
> > In http://reviews.llvm.org/D19995#424345, @rjmccall wrote:
> >
> > > It seems reasonable to me to have an option enabling the use of copy relocations for globals,
> > >  and I agree with David that that option should logically be applicable to PIE.  I would also tend
> > >  to agree with Joerg that that option should default to off, even in non-PIC modes, but it's not my call.
> >
> >
> > Non-PIC use of copy relocations is practically unavoidable
> 
> 
> This is not even slightly true.  There is absolutely nothing preventing
> you from using a GOT-style relocation in non-PIC mode.  Even if you
> didn't have linker support for a non-relative relocation to a GOT entry
> (on platforms where it matters), you can easily fake one up with weak symbols.

The original ABI design was static linking and dynamic linking of the
main program from exactly the same object files. Using GOT-style
relocations is prohibitive on all platforms without cheap PC-relative
addressing. This includes for example i386. I don't know why amd64
didn't start effectively using PIC from the beginning, the difference is
small enough and following the PPC example would have avoided a lot of
problems. That's sadly a historic mistake that can't be corrected
easily

> > The (sane) default behavior for PIC and PIE code is to access external symbols with default visibility
> >  via the GOT.
> 
> I completely agree.  I don't see why this should even be specific to
> PIC, but like I've said before, that's not really my call to make.

As written above, I would strongly prefer to always access globals via
the GOT by default, but that's quite a significant break in the ABI.
I'm not yet ready for writing support code for that, especially since it
requires rejecting copy relocations in the link editor. The latter is
something I want to add anyway at some point, so maybe the former
becomes a reality as well :)

> My general take on copy relocations is that they're a very useful
> feature that should have been reserved for specific use cases as
> opposed to being generally exploited to optimize executables over
> libraries.  (Interesting use case for copy relocations: libraries that
> export version-specific constant values that are frequently accessed
> by clients. For example, you could imagine libc exporting the system page size.)

I don't understand the final example. It can be done with indirect
functions easily, the result is not stored in a variable, but as the
address in the GOT. When linking different libc versions for different
page sizes, it can also be done by declaring the appropiate symbols as
absolute?

Joerg