<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 21, 2017 at 9:19 AM, Rafael Avila de Espindola <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">Joerg Sonnenberger via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>><br>
writes:<br>
<span class=""><br>
> On Mon, Feb 20, 2017 at 06:16:08PM -0800, Rui Ueyama via llvm-commits wrote:<br>
>> Are you suggesting I bring it up to the LLVM blog? This comment is my<br>
>> opinion, and I guess not everybody agrees we should avoid exporting globals<br>
>> from DSOs.<br>
><br>
> Sadly, the accessor approach is expensive and often not a choice. A<br>
> better way would be to provide an attribute to force GOT-based access<br>
> even in non-PIC mode. We are slowly getting the necessary relocations on<br>
> the modern platforms at least.<br>
<br>
</span>I have adding a -fno-copy-reloc to clang in my todo list. But a library<br>
author should at least document that copy relocations are not guaranteed<br>
to work after an upgrade.<br></blockquote><div><br></div><div>How does that -fno-copy-reloc option work? </div></div></div></div>