<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 8, 2016 at 5:26 PM, John McCall <span dir="ltr"><<a href="mailto:rjmccall@gmail.com" target="_blank">rjmccall@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">rjmccall added a comment.<br>
<br>
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.<br>
<br>
RE: the performance impact of relying on the linker to optimize accesses: it certainly can increase register pressure, but it shouldn't in the most common cases where the access sequence ends in putting a new value in a GPR anyway (usually either the address of the variable or something loaded from it).</blockquote><div><br></div><div>Also that linker rewrite may only works for limited simple cases -- after CSE and instruction scheduling, it can be hard to undo the damage already made.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  More importantly, I don't really understand how you can avoid this without compiling code assuming that all globals can be copy-relocated, since the *compiler* doesn't know whether an external symbol is defined as protected or default.  (Unless that's exactly what we're doing — are people really this fast-and-loose in ELF land?)<br></blockquote><div><br></div><div>Unfortunately it seems that the assumption is made by the compiler (gcc, clang)  that external symbol has default visibility. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
RE: the semantic problems with copy relocations exposing the layout of globals: yes, binary compatibility problems usually don't exist when you recompile all the dependent code.  I can understand why system maintainers wouldn't be thrilled with the idea that certain kinds of updates to system libraries can't be made without recompiling the entire user space, though.<br></blockquote><div><br></div><div> If the library write exposes layout of a global in any way to the client programs, it becomes part of the ABI -- so recompilation is needed regardless of copyreloc --except for one special case -- the size of the global remain the same. </div><div><br></div><div>David</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<a href="http://reviews.llvm.org/D19995" rel="noreferrer" target="_blank">http://reviews.llvm.org/D19995</a><br>
<br>
<br>
<br>
</blockquote></div><br></div></div>