[lld] r227711 - [test] Add test for section groups and deadstrip
rafael.espindola at gmail.com
Fri Feb 6 07:55:48 PST 2015
> Please point to the part of the ELF spec that supports your statement.
> The resolver regards the group as one unit and the garbage collection should
> also treat them as one unit.
Sorry, I don't see it. The resolver and the garbage collector are
doing different things. The resolver indeed has to look at the comdat.
It there is an undefined symbol anywhere in the comdat we have to
fetch archive members for example.
> The message from Cary here has the snip.
> Even better, to my mind, we could use (both COMDAT and non-COMDAT)
> group sections to tie the code and debug info (and static data, and
> eh_frame info, etc.) together into a single group. Garbage collection
> could then treat each such group as an atomic unit: any reference to a
> group member section makes the whole group reachable. Back when we
> added COMDAT group sections to the ELF format, we had in mind
> something like this, which is why each group section begins with a
> flag word with GRP_COMDAT set to identify a COMDAT group.
Bringing Cary into the discussion.
Some context (more detail is available in
Once comdats have been resolved, the dead stripper in gold is able to
remove unused sections in the comdats that are kept. That is useful
in the real world given how D5 is defined.
My understanding is that it should also work with debug info. Consider
a comdat C with sections foo, bar and corresponding debug info foo.dbg
and bar.dbg. The relocations go from debug to non debug, but we add
inverted links to the gc links so that foo keeps foo.dbg alive.
Now, if we find that foo is used but bar is not:
* foo will keep foo.dbg alive.
* If foo.dbg corresponds to debug info of only foo, it will not keep
bar alive and bar is gced.
* On the other hand, if foo.dbg is actually a single merged section
that also refers to bar, the linker has to do the old hack of zeroing
fields to avoid debug info changing the code content.
More information about the llvm-commits