[PATCH] [lld][core] sectionGroup support.
Shankar Easwaram
shankarke at gmail.com
Thu Feb 27 19:45:48 PST 2014
Thanks Nick. Will make the changes for core as per the proposed solution.
Sent from my iPhone
> On Feb 27, 2014, at 21:15, Nick Kledzik <kledzik at apple.com> wrote:
>
>
>> 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/1c0b5e15/attachment.html>
More information about the llvm-commits
mailing list