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

[Xinliang David Li via llvm-commits]

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.



>
> > > 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).


You are assuming the code base is always small and easy to curate with this
approach.


> Whole program analysis could do that automatically.
>

Yes, I mentioned that with LTO and ThinLTO, this is a non-issue. You don't
expect everyone can use LTO due to the scalabiity issue, but I do agree
with ThinLTO we have a hope of wider deployment and makes this less of a
problem longer term.


> 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.


Can you clarify here what hacks are used?



> 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.
>

Note that some projects are built in different modes for different purpose
-- for instance, static mode for production release, while shared mode in
debug build. Using hidden visiiblity does not work here.

How about globals generated by compiler such as vtables? Do you see a good
way to annotate them?


>
> 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.



Out of necessity? I may miss something here. Using GOT based reference
always works even for executable build too, so why bother ?



> They introduce hidden ABI
> contracts,


Yes, but this is rarely an issue for many users.



> they muddle up ownership, they are the reason why using
> protected symbols in libraries is difficult.


Agree -- there might be some surprises of using protected symbol in library
that is also referenced by the main program.



> They break code using
> symbolic linkage and users of *that* like newer Qt5 programs explicitly
> depend on PIE never using copy relocations.
>

How do they work with GCC which has copyreloc for PIE?


>
> 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.
>

The performance number mentioned are from performance metric of the
programs in warm state (after loading and other program specific setups).
Besides, the hardened binaries already use eager binding.  The number of
relocations does not have anything to do with this. (The performance
improvement mentioned are validated also using perf-events)

David


>
> Joerg
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160508/fd80ae63/attachment.html>