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

[Shankar Easwaran]

I tested on by using the SPARC linker as well, and it has the same 
behavior as the GNU linker.

On 2/20/2014 10:43 PM, Shankar Easwaran wrote:
> 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