[PATCH] [lld][core] sectionGroup support.
Nick Kledzik
kledzik at apple.com
Thu Feb 27 11:59:38 PST 2014
On Feb 27, 2014, at 11:33 AM, Shankar Easwaran <shankare at codeaurora.org> wrote:
> The group names dont collide with regular symbol names, and the linker keeps the group names in the same namespace too.
But your example below shows the group name colliding with the global variable name. So is the writer supposed to give groups names that won’t collide with regular user symbol names? If so, what about comdat?
>
> Below is an example :-
>
> cat > comdat1.s << \!
> .global g1
> .section .foo,"axG", at progbits,g1,comdat
> g1:
> .word 5
> !
>
> cat > comdat2.s << \!
> .global g1
> .section .foo,"axG", at progbits,g1,comdat
> g1:
> nop
> !
>
> cat > global-g1.c << \!
> int g1 = 1000;
> int fn() { return g1;}
> !
>
> clang -c comdat1.s comdat2.s global-g1.c
> ld comdat1.o comdat2.o global-g1.o --noinhibit-exec
>
> global-g1.o:(.data+0x0): multiple definition of `g1'
> comdat1.o:(.foo[g1]+0x0): first defined here
>
> I get a multiple definition error, that g1 is multiply defined.
>
> Thanks
>
> Shankar Easwaran
>
>
> On 2/27/2014 12:59 PM, Nick Kledzik wrote:
>> The lld model is atom-centric whereas ELF is section-centric. In the example yaml below, you seem to be keeping sections disguised as atoms. I think that intermediate layer is not needed. For example:
>>
>
> The only reason I thought of keeping the intermediate layer is the linker has another mode to generate relocatables/partial linking mode. The partial linking step creates another .o from the set of .o's during the link.
>
> At that point of time, it would be needed to recognize what are the actual group members(section indices) that needs to kept in the .group, could we have another reference kind to keep that info ?
In that mode, it can find all atoms of typeGroup and make a SHT_GROUP for each. For each group it looks at each child, and if each child is in its own section, then just add those section indexes to the parent group’s content. If a child is in a section shared with atoms not in the group, then child will need to be moved to its own section (whose index is added to the parent content).
>
>
>> 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
>> section 4:
>> symbol: name=“d1”, size=4
>> section 5:
>> symbol: name=“f3”, size=30
>
> In the above example, if I want to use partial linking, the partial linking step preserves the group information as is, as in :-
>
> ld -r foo.o -o partiallink.o
>
> The partial link.o would still have :-
>
> section 1: SHT_GROUP , name=“g1”, content=3,4
> section 3:
> symbol: name=“f1”, size=30
> symbol: name=“f2”, size=16
> section 4:
> symbol: name=“d1”, size=4
> section 5:
> symbol: name=“f3”, size=30
>
> Thanks
>
> Shankar Easwaran
>
>>
>> In the above (made up syntax), the file has three functions and once global variable. f1, f2, and d1 are in the the group named g1. The last function f3 is not in any group.
>>
>> I would see the parsed into the lld model as:
>>
>> defined-atoms:
>> - name: g1
>> scope: global
>> type: typeGroup
>> 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
>>
>>
>> On Feb 26, 2014, at 8:38 PM, Shankar Easwaran <shankare at codeaurora.org> wrote:
>>> Hi Nick,
>>>
>>> Thanks for getting back on this and clearing things up.
>>>
>>> Having a group atom with typeSignature is going to really complicate things, that there are two symbol names that need to be dealt with. The additional problem is if there is a relocation relative to the signature atom, it would be hard to figure out what atom to really bind the relocations to also.
>>>
>>> I think the best way to accomodate solving resolution of section groups is not using a group atom with typeSignature, and using the group atom as the signature atom.
>>>
>>> I want to understand a little bit more here.
>>>
>>> As you mentioned on ELF, the group section identified by the signature atom has members that are essentially sections. Are you saying that the signature atom has kindGroupMember references to the section atoms ?
>>>
>>> The atoms that are part of the ELF section know that they are part of the group and they would have a kindSignature reference to the signature atom.
>>>
>>> I am depicting what I mentioned with an example :
>>>
>>> defined-atoms:
>>> - name: mysignature
>>> scope: global
>>> type: typeCode
>>> references:
>>> - kind: group-member
>>> offset: 0
>>> target: L001 /* section */
>>> - kind: group-member
>>> offset: 0
>>> target: L002
>>> # section reference is L001
>>> - ref-name: L001
>>> scope: global
>>> references:
>>> - kind: layout-after
>>> offset: 0
>>> target: foo
>>> - kind: group-signature
>>> offset: 0
>>> target: mysignature
>>> - name: foo
>>> scope: global
>>> references:
>>> - kind: group-signature
>>> offset: 0
>>> target: mysignature
>>> #section reference L002
>>> - ref-name: L002
>>> scope: global
>>> references:
>>> - kind: layout-after
>>> offset: 0
>>> target: bar
>>> - kind: group-signature
>>> offset: 0
>>> target: mysignature
>>> - name: bar
>>> scope: global
>>> references:
>>> - kind: group-signature
>>> offset: 0
>>> target: mysignature
>>>
>>> The reason I just listed the group-members to just sections were just to make sure that we are able to build the group section when we need to start supporting 'partial linking'.
>>>
>>> I have more questions related to symbol resolution after we finalize the design for having the group-signature and group-member references.
>>>
>>> Thanks again.
>>>
>>> Shankar Easwaran
>>>
>>> On 2/26/2014 9:07 PM, Nick Kledzik wrote:
>>>> Shankar,
>>>>
>>>> Getting back to this. The ELF model is that a relocatable file can contain sections of type SHT_GROUP and the content of those sections are indices of other sections. Those other sections must all remain or all be removed. The groups have a name called the signature. A variant of this is when the SHT_GROUP’s section flags has GRP_COMDAT set. The group is now like a weak-definition in that there may be duplicates which a silently discarded.
>>>>
>>>> Your idea is to introduce a new DefinedAtom (with a new ContentType) which represents the group. It is a atom with no content, but has references to all the members of the group. And the members each have a reference back to the group atom.
>>>>
>>>> The problematic areas I see are:
>>>> 1) The group can have a name. Currently all named atoms get added to the output file’s symbol table. Either we need a new attribute on (Defined)Atom that specifies whether or not the name gets added to the symbol table (ld64 has this), or the writer will need to check the contentType() and special case group atoms.
>>>> 2) In the case of group comdat, the group signature will be the the name of one of the atoms. Which means you’d have two atoms with the same name competing to be in the symbol table. Or the symbol table special cases groups, or we need an Atom attribute to ignore the name.
>>>> 3) If groups (non-comdat) are determined to replace one another by name, then they need a name that goes into the symbol table. But that name may need to be prefixed or something to keep if from colliding with real symbol names - or maybe that is considered a bug in the object file??
>>>> 4) This common case (with template instantiation) of group comdat is modeled in ld64 by having the same named atom in the group become the signature atom. So there is no group atom. Each member just has a reference to the signature atom. I don’t know if this optimization would improve ELF groups in lld or make them more complicated.
>>>> 5) We need a way to enforce the references to atoms that are in a group are either from within the group, are to the signature atom, or are indirected in a way that if the group is swapped out that they are properly replaced.
>>>> 6) We need to defined if groups can be nested (a tree of groups) and if not, enforce that.
>>>> 7) If we get this worked out, it may be able to replace the layoutBefore and layoutAfter stuff. Just put everything in a section into the same implicit group…
>>>>
>>>>
>>>> -Nick
>>>>
>>>> On Feb 6, 2014, at 11:27 AM, Shankar Kalpathi Easwaran <shankarke at gmail.com> wrote:
>>>>> ELF does use the COMDAT(SHF_COMDAT) type to discard identical sections which are part of group. Section groups on ELF are modeled by using .group sections. The identical sections are grouped by using a signature symbol that is pointed to by the .group section in the input file.
>>>>>
>>>>> The reason I would like to have the typeSignature property associated with the group is
>>>>>
>>>>> - On ELF, the .group section contains section indices that are part of a group. I think its only ok to say that kindGroupSignature be associated only with the sections that are part of the group. The individual sections that are part of the COMDAT group are converted to atoms and I think those atoms **should not** have //kindGroupSignature //references.
>>>>> - The signature symbol needs to be just discarded in the final executable, there is no need to keep them around in the executable/dynamic library
>>>>> - The signature symbol can be overridden by a defined symbol or an undefined symbol.
>>>>> - At the time of parsing each section by the ELF reader, the ELF reader need not special case that the section was part of which group ?
>>>>>
>>>>> Thoughts/Opinions ?
>>>>>
>>>>> http://llvm-reviews.chandlerc.com/D2710
>>>> _______________________________________________
>>>> llvm-commits mailing list
>>>> llvm-commits at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>>
>>>>
>>>
>>>
>>> --
>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
>>
>
>
> --
> 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/d86ea291/attachment.html>
More information about the llvm-commits
mailing list