[Bug binutils/19938] objcopy breaks sh_link and sh_info of SHT_SUNW_LDYNSYM and SHT_SUNW_symsort sections

[thopre01 at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=19938

Thomas Preud'homme <thopre01 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thopre01 at gcc dot gnu.org

--- Comment #17 from Thomas Preud'homme <thopre01 at gcc dot gnu.org> ---
Hi Nick,

I traced a gdb try_catch test regression to this commit. The reason is that
objcopy breaks the sh_link for .ARM.exidx sections. I believe this is due to
the set of fields checked by section_match not identifying a section uniquely.
The case I'm seeing (ctype.o from libstdc++ compiled for arm-none-eabi) has the
following section table extract before running objcopy:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf
Al
(...)
  [10] .text._ZNKSt5ctypeIcE8do_widenEc PROGBITS        00000000 000084 000004
00 AXG  0   0  4
  [11] .ARM.extab.text._ZNKSt5ctypeIcE8do_widenEc PROGBITS        00000000
000088 000000 00  AG  0   0  1
  [12] .ARM.exidx.text._ZNKSt5ctypeIcE8do_widenEc ARM_EXIDX       00000000
000088 000008 00 ALG 10   0  4
  [13] .rel.ARM.exidx.text._ZNKSt5ctypeIcE8do_widenEc REL             00000000
01144c 000008 08   I 141  12  4
  [14] .text._ZNKSt5ctypeIcE9do_narrowEcc PROGBITS        00000000 000090
000004 00 AXG  0   0  4
  [15] .ARM.extab.text._ZNKSt5ctypeIcE9do_narrowEcc PROGBITS        00000000
000094 000000 00  AG  0   0  1
  [16] .ARM.exidx.text._ZNKSt5ctypeIcE9do_narrowEcc ARM_EXIDX       00000000
000094 000008 00 ALG 14   0  4
  [17] .rel.ARM.exidx.text._ZNKSt5ctypeIcE9do_narrowEcc REL            
00000000 011454 000008 08   I 141  16  4
(...)

As is required for .ARM.exidx sections, they link back to the code section they
are related to. Now after running a straight objcopy without any option, I get:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf
Al
(...)
  [10] .text._ZNKSt5ctypeIcE8do_widenEc PROGBITS        00000000 000084 000004
00 AXG  0   0  4
  [11] .ARM.extab.text._ZNKSt5ctypeIcE8do_widenEc PROGBITS        00000000
000088 000000 00  AG  0   0  1
  [12] .ARM.exidx.text._ZNKSt5ctypeIcE8do_widenEc ARM_EXIDX       00000000
000088 000008 00 ALG 14   0  4
  [13] .rel.ARM.exidx.text._ZNKSt5ctypeIcE8do_widenEc REL             00000000
01144c 000008 08   I 141  12  4
  [14] .text._ZNKSt5ctypeIcE9do_narrowEcc PROGBITS        00000000 000090
000004 00 AXG  0   0  4
  [15] .ARM.extab.text._ZNKSt5ctypeIcE9do_narrowEcc PROGBITS        00000000
000094 000000 00  AG  0   0  1
  [16] .ARM.exidx.text._ZNKSt5ctypeIcE9do_narrowEcc ARM_EXIDX       00000000
000094 000008 00 ALG 10   0  4
  [17] .rel.ARM.exidx.text._ZNKSt5ctypeIcE9do_narrowEcc REL            
00000000 011454 000008 08   I 141  16  4
(...)

See how wideenc .ARM.exidx section now link to narrowEcc code section. You'll
notice that the code section both have the same type (PROGBIGS which is logical
for 2 text sections), flags (AXG, expected for 2 code sections), alignment (4,
expected for 2 text sections), size (4, quite likely when compiling a big file
with -ffunction-sections) and entry size (0, expected for 2 text sections).

I therefore believe that the set of fields tested in not enough to identify a
section uniquely. We could add address and offset which is more likely to yield
correct results (I don't know if two sections can share the same address and
offset but I guess if they do they would have different type and flags).

Best regards,

Thomas

-- 
You are receiving this mail because:
You are on the CC list for the bug.