[PATCH] D28481: Respect section groups in GC

[Peter Collingbourne via llvm-commits]

On Wed, Jan 11, 2017 at 11:14 AM, Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:

> Reid Kleckner via Phabricator via llvm-commits
> <llvm-commits at lists.llvm.org> writes:
>
> > rnk added a comment.
> >
> > In https://reviews.llvm.org/D28481#640798, @ruiu wrote:
> >
> >> 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?
> >
> >
> > 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?
>
> See my first reply. Using LINK_ORDER might work. Or we might need to
> standardize it somehow.
>
> Since this is a question more about ELF than about lld, I suggest we
> move the discussion to
> https://groups.google.com/forum/#!forum/generic-abi. In particular, I
> would like to know the opinion of the developers of other linkers (Cary
> Coutant in particular).
>
> So far the possibilities are:
>
> * Change lld and gold to be like bfd (and maybe clarify the spec).
> * Spec that LINK_ORDER always has a reverse dependency.
> * Add a section flag that says that relocation from that section have
>   inverse dependency.
>
> OK if I start that thread and CC folks on this discussion?
>

Agreed that this would be worth discussing on generic-abi. Please do start
the thread.

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.

Thanks,
-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170111/2f66dc44/attachment.html>