<div dir="ltr">To be clear, assuming copyrelocs (support in linker) allows compiler to generate efficient code (speculatively) to access external globals which compiler has no idea where they are going to be defined. For most of the cases, the most of globals end up in the main program, so copyrelocs is only a fallback mechanism in case that is not the case. <div><br></div><div>Yes, copy relocs exposes the data layout of shared lib globals -- but this is usually not an issue for programs that are frequently built/released (on the other hand, shared libraries are less likely to change).</div><div><br></div><div>Also note this is not something new introduced by this patch. Non-pie case already does it.</div><div><br></div><div>David</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 6, 2016 at 11:31 AM, 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>
The semantic argument against using copy relocations by default is that they hard-code the size of the variable at link time.  What's the story here for that?<br>
<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>