[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 11:53:40AM -0700, Daniel Berlin wrote:
> Then was a comment "This looks like a huge step in the wrong direction to
> me. Copy relocations are one of the worst misfeatures of ELF. Please do not
> add any new dependencies.".
> 
> I'll be blunt here.  This is generally not a good way to start a
> discussion, or be constructive towards a patch..  If people have some
> vision and  want to move the world forward in whatever vision they have,
> that's awesome. Really.  However, if you want to get others to go along,
> you need to convince others, and move the world forward yourself, not just
> try to block them from doing something you don't necessarily like, unless
> it's also going to cause something for LLVM itself (IE serious maintenance
> burden, etc).

There are few constructive ways to really oppose an idea. Even in the
context of LLVM, we have been burned by copy relocations. See the
mailing list archive for the issues with cout alignment on FreeBSD.
Issues like that are the real maintainance burden of copy relocations
and they tend to be paid by those that (have to) care about long term
compatibility. The issues tend to be obscure, not obvious from reading
code and difficult to debug. But the price will generally not be paid by
those who just want an easy switch to get a bit more performance.

> Staring at this patch, it's about 10 lines of real change,
> and seems to simply add something we already support to another mode in a
> sane way.    Without any comment on copy relocs themselves, i can't see why
> this is not sane way to do this.   I also see absolutely no movement
> towards getting rid of it in other modes, etc.

The reason why there are few visible moves to getting rid of them
for good is simple. It involves coordination between different groups
and it is almost guaranteed to effectively involve a flag day. That
makes it quite difficult to retrofit it into an existing environment.
Consider the problem of the stack alignment on i386 for the problems.

> So my suggestion would be to try to get back to making sure John, Rafael,
> etc have the info they need to effectively review this patch, and not
> debating the merits of copy relocations themselves *in this thread*. If
> folks want to start a larger discussion where gcc, lld, gold, etc decide
> they think they are sucky enough they want to avoid them, great!

That argument structure is not logical. It's like having a discussion
about the best cocktail holders in a car and asking everyone to move discussions
about drunken driving elsewhere. It makes no sense to discuss the best
way to use copy relocations for PIE binaries, when they should not be
using copy relocations in first place.

Joerg