<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 8, 2016 at 7:46 AM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="">On Sat, May 07, 2016 at 05:39:15PM -0700, Xinliang David Li wrote:<br>
> On Sat, May 7, 2016 at 11:52 AM, Joerg Sonnenberger via llvm-commits <<br>
> <a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br>
><br>
> > On Sat, May 07, 2016 at 10:58:51AM -0700, Xinliang David Li via<br>
> > llvm-commits wrote:<br>
> > > To be clear, assuming copyrelocs (support in linker) allows compiler to<br>
> > > generate efficient code (speculatively) to access external globals which<br>
> > > compiler has no idea where they are going to be defined. For most of the<br>
> > > cases, the most of globals end up in the main program, so copyrelocs is<br>
> > > only a fallback mechanism in case that is not the case.<br>
> ><br>
> > I think your reasoning is confusing cause and effect. Copy relocations<br>
> > exist, because people didn't want to change things when shared linkage<br>
> > was introduced.<br>
><br>
><br>
> What do you mean by 'people didn't want to change things'?<br>
<br>
</span>Exactly what I wrote. Static linkage was the default, then patching with<br>
XCOFF. ELF's mechanism are late to the game. Copy relocations are a<br>
result of wanting to mix non-position independent main binaries with<br>
shared libraries.<br>
<span class=""><br>
> For executable, copy reloc is introduced so that global access without GOT<br>
> can be used without requiring text relocation when the reference is truly<br>
> external.  Are you saying this is not the case?  History aside, this is<br>
> certainly how copyreloc is used today.<br>
<br>
</span>Code generated without -fPIC on most architectures doesn't use the GOT.<br>
That means the link editor has to be patch things up as best as it can<br>
to make it use shared libraries. Two direct results from this are:<br>
(1) Variables defined in shared objects must be relocated to the main<br>
binary, when referenced from this.<br>
(2) The identify of functions is the PLT slot of the main binary, when<br>
referenced.<br>
<br>
Both issues have a long history of creating compatibility and<br>
performance issues.<br></blockquote><div><br></div><div>Let's keep the discussion on topic -- we are not discussing how shared linkage should be handled vs what is available today.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<span class=""><br>
> > It is a horrible hack and everyone seriously involved<br>
> > with ELF acknowledges that it is a horrible hack only comparible to text<br>
> > relocatiions<br>
><br>
><br>
> You can certainly feel this way, but making claims about 'everyone involved<br>
> ..' seems to have no basis and is not relevant here.<br>
<br>
</span>I don't see anyone disagreeing... I'm still surprised that binutils is<br>
willing to restore this crap, but given their history of I shouldn't be.<br></blockquote><div><br></div><div>The above statement is contradicting itself.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
I would certainly hope that Rui et al have a difference stance on repeat<br>
the mistakes of the past here.</blockquote><div><br></div><div>Do you mean let lld to not support copyreloc? How do you expect this to work with non-PIE executable (linked with shared libs)? Or do you expect compiler also to change in this direction?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> If you want to see a good example of why<br>
copy relocations are bad, look for the recent "libc++'s cout getting<br>
aligned differently" bug in clang. That's a wonderful example of the<br>
kind of issues copy relocations and where they hurt performance much<br>
more than any advantage they ever produce.<br></blockquote><div><br></div><div>It is certainly possible to come up with a scenario that copyrelocs can hurt performance. For instance, shared lib has lots of hot globals that are properly laid out (manually or via PGO). Using copyreloc can make it work. However this is mostly an implementation quality issue. It is also *not* general as you claimed.   On the other hand, the link time optimizer can actually take advantage this to enable optimal data layout across shared library boundaries, but this is slightly off-topic.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
So let me repeat: if you want to get the performance benefits of<br>
non-interposable references, work on making protected actually usable. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
This includes the more important dllimport side. That's useful not just<br>
for the special case of the main binary, but can be used for shared<br>
libraries as well. It is something where code in the wild is already<br>
known to exploit the lack of copy relocations for PIE. Do not add copy<br>
relocations back.<br></blockquote><div><br></div><div>It seems to me the main motivation of your objection is that there is  dependence on the current implementation specific behavior of PIE (not using copyreloc) which is not reasonable. Do not rely on something that is not specified. </div><div><br></div><div>It is true that copyreloc is not perfect and has  its own limitations and problems, but do not deny its benefits because you do not like it. If you feel really strongly about this, I think you should propose alternatives and make it generally accepted as well standard.  (So far It is not even clear to me what your proposal is: asking user to change source to annotate with protected visibility? making all linkers to automatic rewrite (without additional overhead, size/icache etc)? or something else? )  When the alternative is ready, we can talk about getting rid of copyreloc (even for non-PIE usage).<br></div><div><br></div><div><br></div><div>thanks,</div><div><br></div><div>David</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div class=""><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>