<div dir="ltr"><br><div>In essence, this patch is basically providing a way for user to make assertion that global declarations are either defined in the main program or they are truly external (defined DSO), but there is a way to access them without using GOT via linker magic.  Such assertion is on by default for non-PIE build. copyreloc is simply an implementation detail.</div><div><br></div><div>David</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 9, 2016 at 4:04 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</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 8 May 2016 at 20:26, John McCall <<a href="mailto:rjmccall@gmail.com">rjmccall@gmail.com</a>> wrote:<br>
> 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).  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>
><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>
<br>
</span>I agree with all remarks.<br>
<br>
Using this email to note that I think there is a point that was missed<br>
in some messages in this thread:<br>
<br>
Using copy relocations is *not* what is making the program faster.<br>
<br>
What is making the program faster is that it is not accessing its own<br>
variables with a got. The way copy relocations come into the picture<br>
is that they allow the compiler guess to be wrong in the case of the<br>
main program. If it is, the dynamic linker produces a copy.<br>
<br>
So you could get the same (even a bit better maybe) performance by either<br>
<br>
* Marking every decl in the main program protected (or hidden if<br>
doesn't take plugins)<br>
* Marking every library decl with dllimport and keeping the default of<br>
assuming externals are local to this DSO.<br>
<br>
Copy relocations are just an easy enabler. Another easy one that might<br>
produce close results is building the main program with<br>
-fvisibility=protected. That will mark every definition protected and<br>
avoid some got uses. The linker will hopefully optimize the others.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>