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

Rafael Espíndola rafael.espindola at gmail.com
Tue May 15 12:00:49 PDT 2012


On 15 May 2012 05:45, Dmitri Shubin <sbn at tbricks.com> wrote:
> Hello Rafael!
>
> There are actually 2 (related) questions.

Yes, sorry, I was confusing the two.

> So if the section with function code (.text._Z3barIiEiT_) is discarded there
> is no point to have corresponding reloc section.
> So it makes sense to put it in the same COMDAT group as .text._Z3barIiEiT_
> This is what Sun CC does:
>
> $ CC -V
> CC: Sun C++ 5.11 SunOS_i386 145731-02 2011/02/11
> usage: CC [ options ] files.  Use 'CC -flags' for details
> $ CC -c a.cpp
> $ elfdump -g a.o
>
> Group Section:  .group%__1cDbar4Ci_6FTA_i_
>
>     index    flags / section         signature symbol
>       [0]   [ COMDAT ]               __1cDbar4Ci_6FTA_i_
>       [1]   .text%__1cDbar4Ci_6FTA_i_ [4]
>       [2]   .rel.text%__1cDbar4Ci_6FTA_i_ [18]
> $ echo __1cDbar4Ci_6FTA_i_ | c++filt
> int bar<int>(__type_0)
>
> Compare with clang:
>
> $ /opt/clang/bin/clang++ -c a.cpp
> $ elfdump -c a.o | grep ^Section
> Section Header[1]:  sh_name: .group
> Section Header[2]:  sh_name: .text
> Section Header[3]:  sh_name: .rel.text
> Section Header[4]:  sh_name: .data
> Section Header[5]:  sh_name: .bss
> Section Header[6]:  sh_name: .text._Z3barIiEiT_
> Section Header[7]:  sh_name: .rel.text._Z3barIiEiT_
> Section Header[8]:  sh_name: .note.GNU-stack
> Section Header[9]:  sh_name: .eh_frame
> Section Header[10]:  sh_name: .rel.eh_frame
> Section Header[11]:  sh_name: .shstrtab
> Section Header[12]:  sh_name: .symtab
> Section Header[13]:  sh_name: .strtab
>
> $ elfdump -g a.o
>
> Group Section:  .group
>     index    flags / section         signature symbol
>       [0]   [ COMDAT ]               _Z3barIiEiT_
>       [1]   .text._Z3barIiEiT_ [6]
>
> This is the first question -- why clang doesn't put both sections to COMDAT
> group?

Good point. We can probably move it there (assuming gold and gnu ld
are OK with it). Would you mind opening a bug about just this bit?

> The second question is about relocation against .eh_frame section which
> Solaris ld is complaining about.
>
> What I'm trying to do:
>
> $ /opt/clang/bin/clang++ -c a.cpp
> $ /opt/clang/bin/clang++ -c b.cpp
> $ ld -Dsections -r -o all.o a.o b.o
> debug:
> debug: Solaris Linkers: 5.10-1.1505
> debug:
> debug: section=[1].group; input from file=a.o
> debug: section=[1].group; input from file=a.o; defines COMDAT group:
> signature symbol: _Z3barIiEiT_
> debug: section=.group; added to segment=extra (created)
> ...
> debug: section=[6].text._Z3barIiEiT_; input from file=a.o
> debug: section=[6].text._Z3barIiEiT_; input from file=a.o; member of COMDAT
> group: signature symbol: _Z3barIiEiT_
> debug: section=.text._Z3barIiEiT_; added to segment=text (created)
> ...
> debug: section=[9].eh_frame; input from file=a.o
> debug: section=.eh_frame; added to segment=data (created)
> ...
> debug: section=[1].group; input from file=b.o
> debug: section=[1].group; input from file=b.o; defines COMDAT group:
> signature symbol: _Z3barIiEiT_
> debug: section=[1].group; input from file=b.o; discarded in favor of group:
> signature symbol: _Z3barIiEiT_: file=a.o
> ...
> debug: section=[6].text._Z3barIiEiT_; input from file=b.o
> debug: section=[6].text._Z3barIiEiT_; input from file=b.o; member of COMDAT
> group: signature symbol: _Z3barIiEiT_
> debug: section=[6].text._Z3barIiEiT_; input from file=b.o; discarded in
> favor of group: signature symbol: _Z3barIiEiT_: file=a.o
> ...
> debug: section=[9].eh_frame; input from file=b.o
> debug: section=.eh_frame; added to segment=data
> debug:
>
> 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_
>
> So the linker successfully discarded .text._Z3barIiEiT_ in b.o in favor of
> the one in a.o
>
> But it got problems when processing relocations for .eh_frame section in b.o
>
> $ elfdump -r -N .rel.eh_frame b.o
> Relocation Section:  .rel.eh_frame
>    type                       offset             section        symbol
>  R_386_32                       0x20             .rel.eh_frame  .text
> (section)
>  R_386_32                       0x3c             .rel.eh_frame
>  .text._Z3barIiEiT_ (section)
>
> $ dump -r b.o
> b.o:
>    **** RELOCATION INFORMATION ****
> ...
> .rel.eh_frame:
> Offset      Symndx              Type
> 0x20        2                   1
> 0x3c        5                   1
>
> $ elfdump -l -s b.o
>
> Symbol Table Section:  .symtab
>     index    value      size      type bind oth ver shndx / name
>       [0]  0x00000000 0x00000000  NOTY LOCL  D    0 UNDEF
>       [1]  0x00000000 0x00000000  FILE LOCL  D    0 ABS            b.cpp
>       [2]  0x00000000 0x00000000  SECT LOCL  D    0 .text
>       [3]  0x00000000 0x00000000  SECT LOCL  D    0 .data
>       [4]  0x00000000 0x00000000  SECT LOCL  D    0 .bss
>       [5]  0x00000000 0x00000000  SECT LOCL  D    0 .text._Z3barIiEiT_
>       [6]  0x00000000 0x00000000  SECT LOCL  D    0 .note.GNU-stack
>       [7]  0x00000000 0x00000000  SECT LOCL  D    0 .eh_frame
>       [8]  0x00000000 0x00000000  SECT LOCL  D    0 .group
>       [9]  0x00000000 0x00000030  FUNC WEAK  D    0 .text._Z3barIiEiT_
> _Z3barIiEiT_
>      [10]  0x00000000 0x00000022  FUNC GLOB  D    0 .text          _Z3foov
>      [11]  0x00000000 0x00000000  NOTY GLOB  D    0 UNDEF          _ZN1SD1Ev
>
> The second relocation entry in .rel.eh_frame references section symbol
> [5].text._Z3barIiEiT_ which is LOCAL and thus is discarded with discarded
> section .text._Z3barIiEiT_
>
> Of course, this is my understanding of what linker is saying.

OK, I understand this too now. It looks like the problem is coming
from the relocations for "FDE initial location". They are easy to see
with

$ clang -S  a.cpp -fno-dwarf2-cfi-asm

We have something like

_Z3bazv:                                # @_Z3bazv
.Ltmp2:
	.long	.Ltmp2                  # FDE initial location

It would probably be OK to use the symbol directly. Would that fix the
link for you?

Cheers,
Rafael




More information about the cfe-dev mailing list