<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 8, 2016 at 5:04 PM, Joerg Sonnenberger via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sun, May 08, 2016 at 04:31:08PM -0700, Xinliang David Li wrote:<br>
> Do not expect people to agree with you because of the strong words used<br>
> throughout the discussions: horrible, everyone dislikes etc.<br>
<br>
</span>Copy relocations are pretty much universally agreed to be one of the<br>
biggest historic problems in ELF. Period. Just because they are a<br>
necessary evil for "old-style" main binaries doesn't mean they should be<br>
ever extended beyond that. The situation is really as simple as that.<br></blockquote><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> > It is also<br>
> > clear that you do not even want to look at the *existing* alternatives.<br>
> ><br>
><br>
> Wrong assertion. If we can get back to technical discussions without<br>
> resorting to attacking, that will be great. You can lay down your<br>
> proposals in more details and compare pros/cons of different alternatives.<br>
> We need a solution that is generally good and easy for users (including the<br>
> lazy programmers you referred ) to use. Also what are the main pain points<br>
> of copyreloc to you? slower startup time or something else?<br>
<br>
</span>I already gave you the better alternatives. Mark the relevant symbol as<br>
hidden (works in the majority of the cases) or protected (works in the<br>
remaining cases). </blockquote><div><br></div><div>You are assuming the code base is always small and easy to curate with this approach.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Whole program analysis could do that automatically.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It would be nice if library headers where using visibility pragmas<br>
consistently, so that -fvisibility=hidden as default worked without<br>
wrapper hacks like those used by Firefox. </blockquote><div><br></div><div>Can you clarify here what hacks are used?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Even without that, it is<br>
normally quite easy to change even larger projects to consistently<br>
define variables in the main binaries as static or hidden in the<br>
corresponding headers.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>How about globals generated by compiler such as vtables? Do you see a good way to annotate them?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Copy relocations have never been about performance, they exist purely<br>
out of necessity. They are the little brother of text relocations -- one<br>
is the kind of the fix for the other. </blockquote><div><br></div><div><br></div><div>Out of necessity? I may miss something here. Using GOT based reference always works even for executable build too, so why bother ?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">They introduce hidden ABI<br>
contracts,</blockquote><div><br></div><div>Yes, but this is rarely an issue for many users.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> they muddle up ownership, they are the reason why using<br>
protected symbols in libraries is difficult. </blockquote><div><br></div><div>Agree -- there might be some surprises of using protected symbol in library that is also referenced by the main program.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">They break code using<br>
symbolic linkage and users of *that* like newer Qt5 programs explicitly<br>
depend on PIE never using copy relocations.<br></blockquote><div><br></div><div>How do they work with GCC which has copyreloc for PIE?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I am highly suspicious of the one number mentioned so far in this thread<br>
to justify the patch. The overead of PIE goes beyond the unfoldable<br>
address access. Especially for shorter test cases, the pure number of<br>
additional relocations is enough to easily explain 4% performance<br>
difference.<br></blockquote><div><br></div><div>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)</div><div><br></div><div>David</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
Joerg<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div></div>