Re: RFC: COMDAT group names become anonymouse local symbols

[Cary Coutant <ccoutant at google dot com>]

>>> On the other hand, perhaps GCC shouldn't generate code like this.
>
>> If gcc were to generate the local symbol, it looks like gas will do
>> the right thing and set the name of the SHT_GROUP section to ".group"
>> with a link field pointing to the key symbol.
>
> So, do you consider this a GCC bug? ?Or a GAS bug?
>
> I think we can fix the end-user C++ behavior in either way, but I guess
> I feel like this is a GAS bug. ?Why should someone writing assembly code
> have to define "B"? ?Telling the assembler that "B" is the signature of
> the group seems like it should be enough. ?What do you think?

Judging by the responses so far, it sounds like the GAS behavior to
leave the section symbol's name blank is intended behavior, even if
not completely legal according to the ELF spec. But the real issue is
whether using the section symbol as the comdat key is the right thing
to do, rather than creating a local symbol for the purpose. For
consistency, I'd argue that SHT_GROUP sections ought to be named
independently of whether or not a symbol for the comdat key exists,
and that GAS ought to simply generate a new local symbol if necessary.

Since no one has offered any support for my wild guess about this
being an artifact of support for the old HP comdat design, I think
it's safe to discount that and just change GAS.

On the other hand, I wouldn't object to changing both GCC and GAS:
change GCC to generate the symbol in all cases, and change GAS to
complain about a reference to an undefined symbol for the example you
gave.

-cary