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

[Michael Spencer]

On Thu, Feb 27, 2014 at 3:46 PM, Shankar Easwaran
<shankare at codeaurora.org> wrote:
> On 2/27/2014 4:31 PM, Michael Spencer 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?
>>
>> Group resolution seems to only matter for comdat groups. Non-comdat
>> groups just need references to properly model dead stripping.
>
> The group signature symbols participate in symbol resolution in a different
> way,
>
> Taking the previous example that Nick mentioned here, consider two files
> foo.o and bar.o
>
> ELF foo.o contains:
>
>    section 1: SHT_GROUP , name=“g1”, content=3,4(SHF_COMDAT)
>
>    section 3:
>          symbol: name=“f1”, size=30
>          symbol: name=“f2”, size=16
>    section 4:
>          symbol: name=“d1”, size=4
>
> ELF bar.o contains:
>
>    section 1: SHT_GROUP , name=“g1”, content=3,4 (SHF_COMDAT)
>
>    section 3:
>          symbol: name=“f1”, size=30
>          symbol: name=“f2”, size=16
>    section 4:
>          symbol: name=“d1”, size=4
>
> If the link line was ld foo.o bar.o -o exec,
>
> We would get a multiple defined error if the resolution happens if they are
> not treated as a group.
>
> Were you seeing something else different ?

This is comdat, where the name does matter. The groups here aren't
influencing symbol resolution directly. The linker first removes
bar.o's g1. Then symbol resolution proceeds as normal. If they were
not comdat, this would be a multiple definition error (of g1, f1, f2,
and d1).

- Michael Spencer