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

[Shankar Easwaran]

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

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