<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 11, 2017 at 11:14 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">Reid Kleckner via Phabricator via llvm-commits<br>
<span class=""><<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> writes:<br>
<br>
> rnk added a comment.<br>
><br>
> In <a href="https://reviews.llvm.org/D28481#640798" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D28481#640798</a>, @ruiu wrote:<br>
><br>
>> I wonder if there's a different way to keep them alive. One thing I can think of is to add a dummy relocation (something like R_X86_64_NONE) to a section so that if the section is alive, the other sections will become alive, without actually doing any relocations. Does it work?<br>
><br>
><br>
> Currently, linker GC retains all data in sections referenced by __start_$section __stop_$section. We need to suppress that retention in addition to establishing this inverse reference. How do you propose to do that?<br>
<br>
</span>See my first reply. Using LINK_ORDER might work. Or we might need to<br>
standardize it somehow.<br>
<br>
Since this is a question more about ELF than about lld, I suggest we<br>
move the discussion to<br>
<a href="https://groups.google.com/forum/#!forum/generic-abi" rel="noreferrer" target="_blank">https://groups.google.com/<wbr>forum/#!forum/generic-abi</a>. In particular, I<br>
would like to know the opinion of the developers of other linkers (Cary<br>
Coutant in particular).<br>
<br>
So far the possibilities are:<br>
<br>
* Change lld and gold to be like bfd (and maybe clarify the spec).<br>
* Spec that LINK_ORDER always has a reverse dependency.<br>
* Add a section flag that says that relocation from that section have<br>
  inverse dependency.<br>
<br>
OK if I start that thread and CC folks on this discussion?<br></blockquote><div><br></div><div>Agreed that this would be worth discussing on generic-abi. Please do start the thread.</div><div><br></div><div>Another possibility would be to introduce a section flag that means that a section should *not* be treated as a GC root. Then ASan can emit a R_X86_64_NONE relocation to introduce a dependency from the global section to the metadata section. We could even hypothetically teach LLVM to put that flag on .init_array sections for constructors that are known not to have side effects.</div><div><br></div><div>Thanks,</div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div></div>