http://sourceware.org/bugzilla/show_bug.cgi?id=13421
Bug #: 13421
Summary: readelf -u generates output for relocatable ARM
objects
Product: binutils
Version: 2.23 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: binutils
AssignedTo: unassig...@sourceware.org
ReportedBy: dave.mar...@linaro.org
Classification: Unclassified
Observed in binutils CVS 20111121
Host: x86_64-linux-gnu
Target: arm-elf-eabi
(the host should not really matter, and any ARM target should show the same
behaviour)
Readelf's unwind table dumping implementation for ARM appears to make incorrect
assumptions which mean that readelf -u only generates valid output for fully
linked objects (ET_EXEC/ET_DYN).
The reason seems to be that the implementation attempts to convert relocated
unwind table information to absolute address offsets prematutely: this works
when all loadable sections share a common addressing origin (as for fully
linked objects) but not when each section has an independent origin (as for
ET_REL).
This appears to cause the location of both the function body and the unwind
opcodes to be miscalculated.
The erroneous code is in the following functions in binutils/readelf.c:
dump_arm_unwind ()
arm_section_get_word ()
arm_print_vma_and_name ()
To fix this, the code should not be fully applying the R_ARM_PREL31 relocations
at all, since cross-section relocations cannot be applied without a common
addressing origin. Instead, a {section,address} pair should be generated by
applying the relocation addend to the target symbol's {section,address} pair,
with the resultant pair used for locating the unwind opcodes and function
symbol.
Consider refactoring the code when resolving this: the resulting code should
hopefully be simpler than the current code, since it would need to do less
relocation processing.
Testcase:
$ cat <<EOF >unwind.txt
.type f1,%function
f1:
.fnstart
stmfd sp!, {r0-r12,lr}
.save {r0-r12,lr}
bl foo
ldmfd sp!, {r0-r12,pc}
.fnend
.size f1,.-f1
.type f2,%function
f2:
.fnstart
stmfd sp!, {r12,lr}
.save {r12,lr}
stmfd sp!, {r0-r3}
.save {r0-r3}
bl foo
ldmfd sp!, {r0-r3,r12,pc}
.fnend
.size f2,.-f2
.type f3,%function
f3:
.fnstart
stmfd sp!,{r0,lr}
.save {r0,lr}
bl foo
ldmfd sp!,{r0,pc}
.fnend
.size f3,.-f3
.type f4,%function
f4:
.fnstart
stmfd sp!,{r1,lr}
.save {r1,lr}
bl foo
ldmfd sp!,{r1,pc}
.fnend
.size f4,.-f4
.type f5,%function
f5:
.fnstart
stmfd sp!,{r2,lr}
.save {r2,lr}
bl foo
ldmfd sp!,{r2,pc}
.fnend
.size f5,.-f5
.type f6,%function
f6:
.fnstart
stmfd sp!,{r3,lr}
.save {r3,lr}
bl foo
ldmfd sp!,{r3,pc}
.fnend
.size f6,.-f6
EOF
$ as -o unwind.o unwind.s
$ readelf -u unwind.o
Unwind table index '.ARM.exidx' at offset 0xc8 contains 6 entries:
0x0: @0x0
Compact model 1
0xb1 0x0f pop {r0, r1, r2, r3}
0x85 0xff pop {r4, r5, r6, r7, r8, r9, r10, r11, r12, r14}
0xb0 finish
0xb0 finish
0x0: @0x0
Compact model 1
0xb1 0x0f pop {r0, r1, r2, r3}
0x85 0xff pop {r4, r5, r6, r7, r8, r9, r10, r11, r12, r14}
0xb0 finish
0xb0 finish
0x0: @0x0
Compact model 1
0xb1 0x0f pop {r0, r1, r2, r3}
0x85 0xff pop {r4, r5, r6, r7, r8, r9, r10, r11, r12, r14}
0xb0 finish
0xb0 finish
0x0: @0x0
Compact model 1
0xb1 0x0f pop {r0, r1, r2, r3}
0x85 0xff pop {r4, r5, r6, r7, r8, r9, r10, r11, r12, r14}
0xb0 finish
0xb0 finish
0x0: @0x0
Compact model 1
0xb1 0x0f pop {r0, r1, r2, r3}
0x85 0xff pop {r4, r5, r6, r7, r8, r9, r10, r11, r12, r14}
0xb0 finish
0xb0 finish
0x0: @0x0
Compact model 1
0xb1 0x0f pop {r0, r1, r2, r3}
0x85 0xff pop {r4, r5, r6, r7, r8, r9, r10, r11, r12, r14}
0xb0 finish
0xb0 finish
# Linking the .o file allows us to get valid output:
$ ld -shared -o unwind unwind.o
$ readelf -u unwind
Unwind table index '.ARM.exidx' at offset 0x2b8 contains 7 entries:
0x224 <f1>: @0x270
Compact model 1
0xb1 0x0f pop {r0, r1, r2, r3}
0x85 0xff pop {r4, r5, r6, r7, r8, r9, r10, r11, r12, r14}
0xb0 finish
0xb0 finish
0x230 <f2>: @0x27c
Compact model 1
0xb1 0x0f pop {r0, r1, r2, r3}
0x85 0x00 pop {r12, r14}
0xb0 finish
0xb0 finish
0x240 <f3>: @0x288
Compact model 1
0xb1 0x01 pop {r0}
0x84 0x00 pop {r14}
0xb0 finish
0xb0 finish
0x24c <f4>: @0x294
Compact model 1
0xb1 0x02 pop {r1}
0x84 0x00 pop {r14}
0xb0 finish
0xb0 finish
0x258 <f5>: @0x2a0
Compact model 1
0xb1 0x04 pop {r2}
0x84 0x00 pop {r14}
0xb0 finish
0xb0 finish
0x264 <f6>: @0x2ac
Compact model 1
0xb1 0x08 pop {r3}
0x84 0x00 pop {r14}
0xb0 finish
0xb0 finish
0x270 <f6+0xc>: 0x1 [cantunwind]
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- 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
