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

[Michael Spencer]

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.

- Michael Spencer