[cfe-dev] Why clang creates ELF section group with only one section in it?

[Dmitri Shubin]

On 11.05.2012 07:16, Rafael Espíndola wrote:
>> But, I found that I can workaround this error by avoiding creating
>> .group section in object files:
>>
>> $ elfdump -g a.o
>>
>> Group Section:  .group
>>       index    flags / section         signature symbol
>>         [0]   [ COMDAT ]               _Z3barIiEiT_
>>         [1]   .text._Z3barIiEiT_ [6]
>>
>> This group contains only one section, is it really needed?
>>
>> GCC (4.5.1, 4.7.0) doesn't create one.
>> Sun C++ 5.11 creates group with 2 sections: bar<int>() text and relocs.
> gcc 4.6 on linux produces an output very similar to what clang does.
> The groups (comdats) are a generic way to let the linker discard
> sections very quickly. In this case it is used for discarding  a
> method instantiated in two files.

But then it makes sense to put relocs against this section in the same 
group also so they can be discarded together (as Sun C++ does).

The problem is that discarded section is referenced from the section 
outside of the discarded group (.rela.eh_frame) via discarded section 
symbol.

If I understand correctly wording of ELF std this is not allowed:
(http://www.sco.com/developers/gabi/latest/ch4.sheader.html#section_groups)

> A symbol table entry with |STB_LOCAL| binding that is defined relative 
> to one of a group's sections, and that is contained in a symbol table 
> section that is not part of the group, must be discarded if the group 
> members are discarded. References to this symbol table entry from 
> outside the group are not allowed. 

And here this discarded symbol is referenced via relocation against 
.eh_frame section.

$ ld -r -o all.o a.o b.o
ld: fatal: relocation error: R_386_32: file b.o: section 
[10].rel.eh_frame: symbol .text._Z3barIiEiT_ (section): symbol has been 
discarded with discarded section: [6].text._Z3barIiEiT_

> Just dropping the group would probably create an executable with two
> copies of the method. Is that what you get?
Yes, this is exactly what I get. But at least I can link :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120514/3dbce092/attachment.html>