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

Rafael Espíndola rafael.espindola at gmail.com
Thu Feb 27 13:43:51 PST 2014


On 27 February 2014 15:52, Shankar Easwaran <shankare at codeaurora.org> wrote:
> On 2/27/2014 1:59 PM, Nick Kledzik wrote:
>
>
> 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?
>
> I am not sure here, as it appears the symbol g1 should need to be treated as
> though its living in 2 namespaces(one in the .group section as the
> signature, and the .data section that contains g1 too)
>
> Bigcheese ?
>
> $ cat comdat1.s
>
>         .global g1
>         .section .foo,"axG", at progbits,g1,comdat
>         .section .data, "aw", at progbits
>         .global g1
> g1:
>         .word 10
>
> Here g1, is the signature of the group and we have a global symbol g1(data).
>
> When I dump the symbol table, I find only one symbol g1.
>
> $ objdump -Clx comdat1.o | grep g1
> 0000000000000000 g       .data  0000000000000000 g1

The spec doesn't say anything about it. Symbol names don't even have
to be unique on elf. For a fun example, compiling

int *foo(void) {
  static int c = 0;
  return &c;
}

with clang produces

Symbol table '.symtab' contains 10 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS foo.c
     2: 0000000000000000     4 OBJECT  LOCAL  DEFAULT    4 foo.c
....

Now, from what is allowed to what is common. When compiling an inline
c++ function,  gcc (and clang) just use the name of the function as
the group name. My understanding is that they do it just for
convenience. It saves having another entry in the symbol table. For
example, try

inline void foo() {}
void bar() {  foo(); }

When compiling a class, gcc (but not yet clang) will group the
multiple constructors and destructors in a comdat with an unique name.
For example, compiling

struct bar {
  bar() {}
};q
bar x;

With gcc produces the symbols _ZN3barC1Ev and _ZN3barC2Ev for the
actual functions, but produces a new symbol (_ZN3barC5Ev) for the
comdat. I think this is an ABI compatibility issue. If older version
of gcc would put each constructor in its own comdats, newer versions
that do the optimization of defining them as alias and putting them in
the same comdat have to use a new symbol. I will double check if that
is the case and report back.

Cheers,
Rafael




More information about the llvm-commits mailing list