I support Nick's option too. I think handling groups is another example of using follow on references. <br><br>One question is how does an atom outside the group refer to the main atom here ? Will not garbage collection cleanup the main atom/signature atom because there are no references ?<br>
<br>Thanks<br><br>-<br><br>Shankar Easwaran<br><br><div class="gmail_quote">On Wed, Dec 19, 2012 at 5:00 PM, Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Dec 19, 2012, at 4:53 PM, Michael Spencer wrote:<br>
> On Wed, Dec 19, 2012 at 4:43 PM, Nick Kledzik <<a href="mailto:kledzik@apple.com">kledzik@apple.com</a>> wrote:<br>
>><br>
>> On Dec 19, 2012, at 4:25 PM, Michael Spencer wrote:<br>
>>> So I was looking into handling ELF groups today in the Atom model. It<br>
>>> appears that we will need to add the concept of a group to the atom<br>
>>> model directly, as modeling it with references fails to capture some<br>
>>> semantics.<br>
>>><br>
>>> <a href="http://www.sco.com/developers/gabi/latest/ch4.sheader.html" target="_blank">http://www.sco.com/developers/gabi/latest/ch4.sheader.html</a><br>
>>><br>
>>> Groups in ELF are collections of sections that must be either included<br>
>>> or excluded as a unit.<br>
>> I thought groups were a collection of symbol - not sections. Is this a case<br>
>> where there is one symbol per section?<br>
><br>
> It's sections. There is no restriction on symbols in a group section.<br>
><br>
>><br>
>>> They also are used to implement COMDAT. Each<br>
>>> group has an "identifying symbol entry" or "group signature". This is<br>
>>> only used in the case of COMDAT groups (which are marked with a flag).<br>
>>> When two COMDAT groups have the same group signature the linker must<br>
>>> select one (not specified how to pick) and discard _all_ members of<br>
>>> the other group.<br>
>>><br>
>>> Correctly implementing this requires knowing the group name for each<br>
>>> group and having the resolver remove the correct set of atoms on<br>
>>> collision. We also need to be able to explicitly track the identifying<br>
>>> symbol entry for the relocatable case.<br>
>><br>
>> In the darwin linker this is solved using references. The "signature" atom in<br>
>> a group has a "group-subordinate" reference to each atom in the group.<br>
>> When an atom is coalesced away, its references are scanned and the<br>
>> target of any group-subordinate reference is also coalesced.<br>
>><br>
>> Conceptually, a group is just a circle around some set of atoms. That same<br>
>> information can be represented as a connected graph. That is, by introducing<br>
>> a zero size "master " atom with reference to each atom in the group. In the special<br>
>> case of group comdat, the signature atom can be used as the master.<br>
>><br>
>> In other words, I'm not convinced of the need to introduce a new top level class<br>
>> (Group) to go along with Atom and Reference. I believe we can encode<br>
>> the same information using references.<br>
>><br>
>> -Nick<br>
><br>
> Ok, I kinda see how this can work. The only thing I'm still confused<br>
> about is conforming to this part of the ELF spec:<br>
><br>
> "This is a COMDAT group. It may duplicate another COMDAT group in<br>
> another object file, where duplication is defined as having the same<br>
> group signature. In such cases, only one of the duplicate groups may<br>
> be retained by the linker, and the members of the remaining groups<br>
> must be discarded."<br>
><br>
> How do we know that a group master is a COMDAT group master as opposed<br>
> to a normal group master?<br>
</div></div>A COMDAT group master has a real, named atom as its master. The other<br>
groups will have a zero size master atom with some special content type<br>
(e.g. typeGroupMaster).<br>
<br>
For COMDAT groups, the "group signature" is the name of the signature<br>
(master) atom. If two .o files each have a COMDAT group with the<br>
same signature, that means they each have a master atom with the same<br>
name.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Nick<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
>>><br>
>>> An idea for implementing this would be to add a list of Groups to each<br>
>>> File. I don't believe a Group should be an atom as it has different<br>
>>> semantics and would have to be treated specially everywhere.<br>
>>><br>
>>> A group would have a name, merge attribute, and a list of atoms it contains.<br>
>>><br>
>>> YAML mockup:<br>
>>><br>
>>> ---<br>
>>> groups:<br>
>>> - name: _Z4funcIiET_S0_<br>
>>> merge: pickAny<br>
>>> members: [_Z4funcIiET_S0_, ".debug._Z4funcIiET_S0_"]<br>
>>><br>
>>> atoms:<br>
>>> - name _Z4funcIiET_S0_<br>
>>> scope: global<br>
>>> merge: asWeak<br>
>>> type: code<br>
>>> ...<br>
>>><br>
>>> The main problem I see with this is that groups are no longer<br>
>>> represented explicitly in the reference graph.<br>
>>><br>
>>> - Michael Spencer<br>
>><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br>