[PATCH] sectiongroup support

[Nick Kledzik]

On Mar 13, 2014, at 8:24 PM, Shankar Kalpathi Easwaran <shankarke at gmail.com> wrote:
>  I dont think the multithreaded model of processing all the object files first is going to work with the ELF linker, as resolution happens in the way input files are processed from command line.
> 
>  This is what I see with the GNU linker :-
> 
>  a) The groups are being resolved as and when input files are processed by the resolver. We cannot delay processing the group members after the resolver has processed all files.
>  b) Consider the below example :-
...

>  With the command line ld foo.o bar.o libarchive.a, when symbols from bar.o are processed, **global-f3 becomes a undefined symbol** and pulls the global-f3 from libarchive.a
> 
>  How do we handle all these cases with lld ?
> 
> http://llvm-reviews.chandlerc.com/D2961

Given that the ELF linker needs those semantics, it seems that the Resolver and symbol table building must be done serially, in command line order.  The object files could still be parsed in parallel, but the results would need to be buffered and added to the symbol table in command line order.  Given that, here are two possible algorithms:

1) Groups are like static libraries
a) group child atoms are not returned in the defined() atoms collection, but group parents are.
b) files are added to the symbol table in command line order
c) when a group parent atom is added to the symbol table, its name is checked to see if that group name has been seen yet by the symbol table.  If not, the group name is added and all its children are also added.  If the group name has already been seen, then the group’s child remain unseen by the symbol table.
Problem: uses of any atom in a group from outside the group would require the ELF reader to synthesized UndefinedAtom and have that be referenced. In a way this is good because it enforces that groups can be removed.

2) Groups are hints for which copy to use when there is a collision
a) group parent and child atoms are both seen in the defined() atoms collection.
b) when an atom is added to the symbol table and that causes a name collision, the atom is checked to see if it is in a group.  If so, the group parent is checked to see if it was the first seen by its name.  If not, the colliding atoms is marked to be replaced by the one it collides with.  If is is the first, we have a warning/error that a group member collides with a non-group member.
Problem: if there are two groups with the same name but wildly different content, the link may just work and you’ll never know.

-Nick