[PATCH] sectiongroup support

[Shankar Kalpathi Easwaran]

================
Comment at: lib/Core/SymbolTable.cpp:61
@@ +60,3 @@
+        if (r->kindValue() == Reference::kindGroupParent) {
+          addGroupChild(atom, *(r->target()));
+          return;
----------------
kledzik at apple.com wrote:
> Shankar Kalpathi Easwaran wrote:
> > kledzik at apple.com wrote:
> > > Shankar Kalpathi Easwaran wrote:
> > > > Rui Ueyama wrote:
> > > > > *r->target()
> > > > ok.
> > > Why is addGroupChild() called here, and what does it do? Scanning all references of all atoms will slow things down.
> > > 
> > > Instead, inside addGroup(), if the group name already exists, you choose one of the groups to use (first one?), then mark it to be replaced.   Later in Resolver::removeCoalescedAwayAtoms() you can find the child of coalesced away groups.
> > a) To catch a bug / error in the YAML file / reader that the user forgot to include a group child atom in the group atom.
> > b) When the groupChild atoms appear before the groupComdat atoms.
> > 
> > Do we want to track the groupChild atoms as normal atoms ? If so how do we identify an error that the atom was not included inside a group ?
> > 
> YAML errors should be checked by the YAML Reader.  No need to slow down the core linker.
> 
> I don't see the issue if a child is added to the symbol table before the group is added.  It will just be a regular atom. Later if the group is replaced, the child will be marked replaced too.  
> 
> Any sort of checking for malformed groups should be done in the readers (YAML and ELF).  
> 
We cannot consider the child atom as a regular atom. For example :-

ELF foo.o contains:
   section 1: SHT_GROUP , name=“g1”, content=3
   section 3:
         symbol: name=“global-f1”, size=30
         symbol: name=“weak-f2”, size=16

ELF bar.o contains:
   section 1: SHT_GROUP , name=“g1”, content=3
   section 3:
         symbol: name=“global-f1”, size=30
         symbol: name=“global-f2”, size=16

When the atoms from bar.o are added, 

global-f1 would appear as an error unless the atom global-f1 is regarded as a group child atom. The only way that we could do is by traversing the references ?

Should we traverse the references when handling NCR_Dup* errors from collide then ?


http://llvm-reviews.chandlerc.com/D2961