[PATCH] D28481: Respect section groups in GC

Evgenii Stepanov via llvm-commits llvm-commits at lists.llvm.org
Mon Jan 9 14:42:53 PST 2017


On Mon, Jan 9, 2017 at 2:36 PM, Rafael Avila de Espindola
<rafael.espindola at gmail.com> wrote:
> Evgeniy Stepanov via Phabricator via llvm-commits
> <llvm-commits at lists.llvm.org> writes:
>
>> eugenis created this revision.
>> eugenis added reviewers: pcc, rnk, ruiu.
>> eugenis added a subscriber: llvm-commits.
>> eugenis set the repository for this revision to rL LLVM.
>>
>> Treat sections that are part of a group as a unit in GC.
>
> I think we should keep this as is.
>
> GC should be independent of comdat. At gc time the linker should know
> all the dependencies and be able to remove parts of a comdat that is not
> used.

Why? When is this beneficial?
Note that comdats in LLVM IR are associative when targeting COFF and
ELF/bfd, and non-associative in ELF/gold and ELF/lld. This change
makes the behavior more consistent.

>
>>This effectively makes ELF section groups behave as associative comdats in COFF.
>>
>> The current implementation uses section groups for selection (i.e. discard duplicate definitions), but then ignores them in GC, potentially discarding parts of a section group.
>>
>> - The new implementation matches the BFD linker behavior, while the current implementation matches Gold.
>>
>> This is also necessary for proper GC of globals in AddressSanitizer. To give some context, ASan emits a "metadata global" for each application global, and needs to iterate over them at runtime. Metadata globals should not affect the liveness of original globals, and they need to be preserved if and only if the corresponding global is preserved.
>
> There are a few cases of these inverse dependencies:
>
> * .eh_frame entries.
> * SHF_LINK_ORDER (.ARM.exidx).
> * debug info, which we detect as non-alloca pointing to alloca. In this
>   case we just don't gc the non-alloca ones.
>
> Could the metadata global be in a section with SHF_LINKs to the global?
> At some point we should propose some flag for making these inverse
> dependencies explicit.
>
> Cheers,
> Rafael


More information about the llvm-commits mailing list