<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 8, 2016 at 2:19 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 02:10:55PM -0700, Xinliang David Li wrote:<br>
> It is true that copyreloc is not perfect and has  its own limitations and<br>
> problems, but do not deny its benefits because you do not like it. If you<br>
> feel really strongly about this, I think you should propose alternatives<br>
> and make it generally accepted as well standard.  (So far It is not even<br>
> clear to me what your proposal is: asking user to change source to annotate<br>
> with protected visibility? making all linkers to automatic rewrite (without<br>
> additional overhead, size/icache etc)? or something else? )  When the<br>
> alternative is ready, we can talk about getting rid of copyreloc (even for<br>
> non-PIE usage).<br>
<br>
</span>It is clear to me that any further discussion is pointless as you don't<br>
want to accept that copy relocations are a horrible idea.</blockquote><div><br></div><div><br></div><div>Do not expect people to agree with you because of the strong words used throughout the discussions: horrible, everyone dislikes etc.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> It is also<br>
clear that you do not even want to look at the *existing* alternatives.<br></blockquote><div><br></div><div>Wrong assertion. If we can get back to technical discussions without resorting to attacking, that will be great.  You can lay down your proposals in more details and compare pros/cons of different alternatives.  We need a solution that is generally good and easy for users (including the lazy programmers you referred ) to use.  Also what are the main pain points of copyreloc to you? slower startup time or something else?</div><div><br></div><div>thanks,</div><div><br></div><div>David</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My objection stands: do not add copy relocations for a code path that<br>
never used or needed them before. It is not a question of "get rid of<br>
them later". The long history of ELF has proven one thing beyond doubt:<br>
if a feature has introduced once, it is extremely difficult to get rid<br>
of it later, even and especially if it is broken. "But it is optional"<br>
hasn't worked for the mess of DT_RPATH vs DT_RUNPATH either.<br>
<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>