<div dir="ltr">Guys.<div>This thread seems to be massively derailed at this point.</div><div>Rafael and John seems to have a set of questions that Sri attempted to answer, and that seemed to be going in a productive direction with other commenting on the patch itself.</div><div><br></div><div>Then was a comment "<span style="font-size:12.8px">This looks like a huge step in the wrong direction to me. Copy relocations are one of the worst misfeatures of ELF. Please do not add any new dependencies.</span>".</div><div><br></div><div>I'll be blunt here.  This is generally not a good way to start a discussion, or be constructive towards a patch..  If people have some vision and  want to move the world forward in whatever vision they have, that's awesome. Really.  However, if you want to get others to go along, you need to convince others, and move the world forward yourself, not just try to block them from doing something you don't necessarily like, unless it's also going to cause something for LLVM itself (IE serious maintenance burden, etc). Staring at this patch, it's about 10 lines of real change, and seems to simply add something we already support to another mode in a sane way.    Without any comment on copy relocs themselves, i can't see why this is not sane way to do this.   I also see absolutely no movement towards getting rid of it in other modes, etc.</div><div><br></div><div>So my suggestion would be to try to get back to making sure John, Rafael, etc have the info they need to effectively review this patch, and not debating the merits of copy relocations themselves *in this thread*. If folks want to start a larger discussion where gcc, lld, gold, etc decide they think they are sucky enough they want to avoid them, great!</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 9, 2016 at 8:28 AM, H.J. Lu 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">On Mon, May 9, 2016 at 8:09 AM, Joerg Sonnenberger via llvm-commits<br>
<span class=""><<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br>
> On Mon, May 09, 2016 at 08:08:28AM -0700, H.J. Lu wrote:<br>
>> On Mon, May 9, 2016 at 7:53 AM, Joerg Sonnenberger via llvm-commits<br>
>> <<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br>
>> > On Mon, May 09, 2016 at 07:30:20AM -0700, H.J. Lu wrote:<br>
>> >> > The original ABI design was static linking and dynamic linking of the<br>
>> >> > main program from exactly the same object files. Using GOT-style<br>
>> >> > relocations is prohibitive on all platforms without cheap PC-relative<br>
>> >> > addressing. This includes for example i386. I don't know why amd64<br>
>> >><br>
>> >> You can use the new R_386_GOT32X relocation to access the<br>
>> >> GOT in executable with the base register, like<br>
>> >><br>
>> >> movl $foo@GOT, %eax<br>
>> >> movl foo@GOT, %eax<br>
>> >><br>
>> >> But not all linkers can relocate it properly.<br>
>> ><br>
>> > But that still requires the base register to be set up?<br>
>><br>
>> The same as x86-64.<br>
><br>
> Huh? AMD64 can address data explicitly via (%rip). i386 has no such<br>
> index register, so normally uses %ebx for that?<br>
><br>
<br>
</span>See my example above.  There is no base register at all.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
H.J.<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<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>