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

Michael Spencer bigcheesegs at gmail.com
Thu Feb 27 14:54:43 PST 2014


On Thu, Feb 27, 2014 at 2:45 PM, Nick Kledzik <kledzik at apple.com> 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?
> That was my question:
>
>>> A fundamental question I have is: are group names in the same namespace as global symbols?  That is, is the ELF .o writer responsible for making sure group names do not collide with regular symbol names?  Or the linker supposed to keep group names separate from regular symbol names?
>
>
>
>>
>> Group resolution seems to only matter for comdat groups. Non-comdat
>> groups just need references to properly model dead stripping.
> So, for non-comdat groups, the name does not matter and can be discarded?

The spec says nothing about the name or multiple non-comdat groups
with the same name. So, according to the spec, the name does not
matter.

>
> For comdat groups, the name is always the name of one of the symbols in the group?

No. "The referenced signature symbol is not restricted. Its containing
symbol table section need not be a member of the group, for example."

- Michael Spencer

>
> -Nick
>




More information about the llvm-commits mailing list