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

[Shankar Easwaran]

Hi Nick,

With the GNU linker, this is what I observe :-

a) the group that appears first is always preferred, no matter what the 
type of the symbol that represents the group.

I created a set of examples and I observe the following :-

Case 1
-----------
Consider two files a.o, b.o each contain group identified by Signature 
symbol 'S'

The group signature in a.o is identified by an undefined symbol 'S' (the 
signature symbol is a undefined symbol!)
The group signature in b.o is identified by an defined symbol 'S'

Behavior : The linker *doesnot* coalesce the undefined symbol 'S' from 
a.o with b.o!

Case 2
-----------
Consider two files a.o, b.o each contain group identified by Signature 
symbol 'S'

The group signature in a.o is identified by an weak symbol 'S' (the 
signature symbol is a weak symbol!)
The group signature in b.o is identified by an defined symbol 'S'

Behavior : The linker *doesnot* coalesce the weak symbol 'S' from a.o 
with b.o!

Case 3
-----------
Consider two files a.o, b.o each contain group identified by Signature 
symbol 'S'

a.o has a undefined symbol 'S'
The group signature in b.o is identified by an undefined symbol 'S'

Behavior : The linker coalesces the undefined symbol from a.o with b.o!

How should we approach solving these usecases with lld ?

Thanks

Shankar Easwaran



On 2/6/2014 1:04 PM, kledzik at apple.com wrote:
>    My understanding of ELF groups (I think it is call group COMDAT) is that there is a set of symbols that are "grouped" together, and one of them is the "signature" for the group.  The linker's rule is that either everything in a group is kept or everything in the group is tossed.  The signature symbol is important because it determines if the group is kept or not.  For instance:
>
>    File A:
>      int foo() { return 0; }
>
>    File B;
>      __attribute__((weak)) int foo() { static int r = get(); return r; }
>
>    And for file A, the compiler generates a group that contains just "foo" which is also the signature for the group.  For file B, the compiler generates a group that contains "foo" and "r" and the signature is "foo".
>
>    When linking these together, if the linker chooses the "foo" from A (and it should because non-weak trumps weak), then the linker needs to toss the "foo" from B *and* the "r' from B because it was part of the group that was tossed.
>
>
>    If this model is correct, I don't see the need for a group atom (typeSignature).  All we need is two Reference Kinds: kindGroupMember and kindGroupSignature.  The atom for the signature symbol has kindGroupMember references to each other atom in the group and each other atom have one kindGroupSignature reference to the signature atom.
>
>    When coalescing, the Resolver looks at each atom it is about to remove (coalesced away) and if it has kindGroupMember references, then each of those atoms are coalesced away too.
>
> http://llvm-reviews.chandlerc.com/D2710
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation