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.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
