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

[Shankar Easwaran]

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.

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 ?

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/80861cf6/attachment.html>