bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug binutils/13421] New: readelf -u generates output for relocatable AR


From: dave.martin at linaro dot org
Subject: [Bug binutils/13421] New: readelf -u generates output for relocatable ARM objects
Date: Mon, 21 Nov 2011 15:29:37 +0000

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: address@hidden
        ReportedBy: address@hidden
    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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]