[PATCH] [lld][core] sectionGroup support.

[Nick Kledzik]

Shankar,

Getting back to this.  The ELF model is that a relocatable file can contain sections of type SHT_GROUP and the content of those sections are indices of other sections.  Those other sections must all remain or all be removed.  The groups have a name called the signature.  A variant of this is when the SHT_GROUP’s section flags has GRP_COMDAT set.  The group is now like a weak-definition in that there may be duplicates which a silently discarded.

Your idea is to introduce a new DefinedAtom (with a new ContentType) which represents the group.  It is a atom with no content, but has references to all the members of the group.  And the members each have a reference back to the group atom.

The problematic areas I see are:
1) The group can have a name.  Currently all named atoms get added to the output file’s symbol table.  Either we need a new attribute on (Defined)Atom that specifies whether or not the name gets added to the symbol table (ld64 has this), or the writer will need to check the contentType() and special case group atoms.
2) In the case of group comdat, the group signature will be the the name of one of the atoms.  Which means you’d have two atoms with the same name competing to be in the symbol table.  Or the symbol table special cases groups, or we need an Atom attribute to ignore the name.  
3) If groups (non-comdat) are determined to replace one another by name, then they need a name that goes into the symbol table.  But that name may need to be prefixed or something to keep if from colliding with real symbol names - or maybe that is considered a bug in the object file??
4) This common case (with template instantiation) of group comdat is modeled in ld64 by having the same named atom in the group become the signature atom.  So there is no group atom.  Each member just has a reference to the signature atom.  I don’t know if this optimization would improve ELF groups in lld or make them more complicated.
5) We need a way to enforce the references to atoms that are in a group are either from within the group, are to the signature atom, or are indirected in a way that if the group is swapped out that they are properly replaced.
6) We need to defined if groups can be nested (a tree of groups) and if not, enforce that.
7) If we get this worked out, it may be able to replace the layoutBefore and layoutAfter stuff.  Just put everything in a section into the same implicit group…


-Nick

On Feb 6, 2014, at 11:27 AM, Shankar Kalpathi Easwaran <shankarke at gmail.com> wrote:
>  ELF does use the COMDAT(SHF_COMDAT) type to discard identical sections which are part of group. Section groups on ELF are modeled by using .group sections. The identical sections are grouped by using a signature symbol that is pointed to by the .group section in the input file.
> 
>  The reason I would like to have the typeSignature property associated with the group is
> 
>  - On ELF, the .group section contains section indices that are part of a group. I think its only ok to say that kindGroupSignature be associated only with the sections that are part of the group. The individual sections that are part of the COMDAT group are converted to atoms and I think those atoms **should not** have //kindGroupSignature //references.
>  - The signature symbol needs to be just discarded in the final executable, there is no need to keep them around in the executable/dynamic library
>  - The signature symbol can be overridden by a defined symbol or an undefined symbol.
>  - At the time of parsing each section by the ELF reader, the ELF reader need not special case that the section was part of which group ?
> 
>  Thoughts/Opinions ?
> 
> http://llvm-reviews.chandlerc.com/D2710