[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