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

Nick Kledzik kledzik at apple.com
Thu Feb 27 19:15:40 PST 2014


On Feb 27, 2014, at 5:52 PM, Shankar Easwaran <shankare at codeaurora.org> wrote:

> On 2/27/2014 6:34 PM, Michael Spencer wrote:
>> On Thu, Feb 27, 2014 at 4:05 PM, Shankar Easwaran
>> <shankare at codeaurora.org> wrote:
>>> On 2/27/2014 4:45 PM, Nick Kledzik wrote:
>>> 
>>> On Feb 27, 2014, at 2:31 PM, Michael Spencer <bigcheesegs at gmail.com> wrote:
>>> 
>>> On Thu, Feb 27, 2014 at 2:14 PM, Rafael Espíndola
>>> <rafael.espindola at gmail.com> wrote:
>>> 
>>> It appears that the linker needs to deal with two namespaces, and think its
>>> best to consider the group signature separately from the other atoms. We
>>> could have an additional map in the Resolver that would just handle
>>> resolution for groups ?
>>> 
>>> It is probably a good idea. The part of the linker deciding to load or
>>> not a group only needs to checks those symbols. The rest of the linker
>>> never needs to check those symbols. Cases like the simple inline c++
>>> function would just happen to be in both tables.
>>> 
>>> Cheers,
>>> Rafael
>>> 
>>> From what I understand, there is nothing special about signature
>>> symbols. They are just a way to give a name to a group and participate
>>> in linking as normal.
>>> 
>>> Are you saying that we have a separate table that represents groups in
>>> addition to leaving all the symbols in the normal symbol table?
>>> 
>>> Yes, lets have a separate group table from the symbol table.
>>> 
>>> I think we need two special signature atom types
>>> 
>>> a) typeGroup
>>> b) typeGroupComdat
>>> 
>>> These atoms would be inserted into a separate group table as part of symbol
>>> resolution.
>>> 
>>> The signatureAtoms would list all the members, that the group will contain,
>>> like how Nick mentioned earlier.
>>> 
>>> defined-atoms:
>>>   - name:            g1
>>>     scope:           global
>>>     type:            typeGroup/typeGroupComdat
>>> 
>>>     references:
>>>       - kind:            group-child
>>>         target:          f1
>>>       - kind:            group-
>>> child
>>>         target:          f2
>>>       - kind:            group-child
>>>         target:          d1
>>>   - name:            f1
>>>     scope:           global
>>>     type:            typeCode
>>>     references:
>>>       - kind:            group-parent
>>>         target:          g1
>>>   - name:            f2
>>>     scope:           global
>>>     type:            typeCode
>>>     references:
>>>       - kind:            group-parent
>>>         target:          g1
>>>   - name:            d1
>>>     scope:           global
>>>     type:            typeData
>>>     references:
>>>       - kind:            group-parent
>>>         target:          g1
>>>   - name:            f3
>>>     scope:           global
>>>     type:            typeCode
>>> 
>>> 
>>> Atoms within the signature group table will be iterated to make sure groups
>>> contain the same group members by name. If they are not, depending on the
>>> configuration, the new group will be ignored or an error would be thrown.
>>> 
>>> What do you think ?
>>> 
>>> Thanks
>>> 
>>> Shankar Easwaran
>> g1 is a normal symbol. There is nothing special about it to the
>> resolver (according to the spec). This does not correctly model that.
> g1 would just identify the signature here, and it belongs in a separate table(group table) in lld's symboltable. 
Yes.  There would need to be another map<> in the symbol table just for groups, and the symbol table would
need to look at the atom’s contentType to see if it goes into the the new group map or the existing _nameTable.
When there is a collision in the group map, all atoms in one group (the new one?) need to be added to
the _replacementAtoms map to be removed.
 

> 
> I would like the group also to be treated as an atom, as opposed to being explicit, considering everything in lld as Atoms.
> 
> Nick ? 
> 
> This is with the example as below :-
> 
> ELF foo.o contains:
> 
>    section 1: SHT_GROUP , name=“g1”, content=3,4
>    section 3: 
>          symbol: name=“f1”, size=30
>          symbol: name=“f2”, size=16
>          symbol: name=“g1”, size=30
>    section 4: 
>          symbol: name=“d1”, size=4
>    section 5: 
>          symbol: name=“f3”, size=30
>  
> For ELF, where g1 is part of section 3, g1 would also be an atom as below :-
> 
> defined-atoms:
>   - name:            g1
>     scope:           global
>     type:            typeGroupComdat
>     references:
>       - kind:            group-child
>         target:          f1
>       - kind:            group-child
>         target:          f2 
>      - kind:            group-child
>         target:          g1
>       - kind:            group-child
>         target:          d1 
>   - name:            f1
>     scope:           global
>     type:            typeCode
>     references:
>       - kind:            group-parent
>         target:          g1
>   - name:            f2
>     scope:           global
>     type:            typeCode
>     references:
>       - kind:            group-parent
>         target:          g1
>   - name:            g1
>     scope:           global
>     type:            typeCode
>     references:
>       - kind:            group-parent
>         target:          g1
>   - name:            d1
>     scope:           global
>     type:            typeData
>     references:
>       - kind:            group-parent
>         target:          g1
>   - name:            f3
>     scope:           global
>     type:            typeCode
> 
> Do we want to marshall the name for the atom with type typeGroupComdat ?
I don’t know what you mean here.


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140227/9c4265f5/attachment.html>


More information about the llvm-commits mailing list