https://sourceware.org/bugzilla/show_bug.cgi?id=33489
Bug ID: 33489
Summary: elf32-arm: missing EXIDX_CANTUNWIND added to unrelated
section
Product: binutils
Version: 2.46 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: chigot at adacore dot com
Target Milestone: ---
Created attachment 16388
--> https://sourceware.org/bugzilla/attachment.cgi?id=16388&action=edit
sample with good-unwinding.s / wrong-unwinding.s
Hello there,
When a text section doesn't provide an associated `.ARM.exidx`, the linker will
add an `EXIDX_CANTUNWIND` entry in the closest `.ARM.exidx` (see [1]). This
means that this ARM.exidx section will get information (unwinding entry and
relocation) towards a symbol unrelated to it.
This could mess up the binary produced on some rare cases. I'm not exactly sure
which combination could lead to them (see [2]) but the attached sample shows
the difference when `ARM.exixd` are missing [3].
As to the resolution, I think the linker should create the missing `ARM.exidx`
section before adding `EXIDX_CANTUNWIND` within. We could also make the
assembler detect the missing unwind markers and create the section. But before
anything I'd like some ARM maintainers to bring their point of view.
Clément
---
[1] in bfd/elf32-arm.c
```
elf32_arm_fix_exidx_coverage (asection **text_section_order,
...
for (i = 0; i < num_text_sections; i++)
{
asection *sec = text_section_order[i];
exidx_sec = arm_data->u.text.arm_exidx_sec;
if (exidx_sec == NULL)
{
...
insert_cantunwind_after (last_text_sec, last_exidx_sec);
```
---
[2] I had this issue with `__cxa_end_cleanup` symbol created by the libstdc++
(see libstdc++-v3/libsupc++/eh_arm.cc) which doesn't have the unwinding
markers.
Our binary was a relocatable executable produced after another partial linking.
The first partial linking was a classic -r. The second was with a linker script
merging all `ARM.exidx` together.
I think that merge somehow modifies the order of `ARM.exidx` and creates holes
within their relocation. Those holes happening only on Windows, but I wasn't
able to find out why (there is probably another bug behind it...)
Anyway, I've tried to come up with a complete reproducer creating a broken
binary. But that's not an easy task. Hence I've decided to push the simple
samples first as there are showing the linker weirdness.
---
[3] sample.s contains both good-cantunwind.s / wrong-cantunwind.s
$ arm-eabi-as good-cantunwind.s -o good-cantunwind.o
$ arm-eabi-ld -r good-cantunwind.o -o good-cantunwind-r
$ arm-eabi-as wrong-cantunwind.s -o wrong-cantunwind.o
$ arm-eabi-ld -r wrong-cantunwind.o -o wrong-cantunwind-r
$ arm-eabi-readelf -u wrong-cantunwind-r
Unwind section '.ARM.exidx.text.foo' at offset 0x40 contains 2 entries:
0x0: 0x80b0b0b0
Compact model index: 0
0xb0 finish
0xb0 finish
0xb0 finish
0x4: 0x1 [cantunwind]
Unwind section '.ARM.exidx' at offset 0x50 contains 1 entry:
0x0: 0x80b0b0b0
Compact model index: 0
0xb0 finish
0xb0 finish
0xb0 finish
$ arm-eabi-readelf -u good-cantunwind-r
Unwind section '.ARM.exidx.text.foo' at offset 0x40 contains 1 entry:
0x0: 0x80b0b0b0
Compact model index: 0
0xb0 finish
0xb0 finish
0xb0 finish
Unwind section '.ARM.exidx.text.bar' at offset 0x48 contains 1 entry:
0x0: 0x1 [cantunwind]
Unwind section '.ARM.exidx' at offset 0x50 contains 1 entry:
0x0: 0x80b0b0b0
Compact model index: 0
0xb0 finish
0xb0 finish
0xb0 finish
--
You are receiving this mail because:
You are on the CC list for the bug.
