[Bug binutils/10263] objdump does not disassemble ARM code entered with .word directives

[mikpe at it dot uu dot se]

------- Additional Comments From mikpe at it dot uu dot se  2009-06-12 15:31 
-------
Nick,

(In reply to comment #1)
> >         mov     r0, r1
> >         .word   0xe1a00001
> >         bx      lr
> 
> >    0:   e1a00001        mov     r0, r1
> >    4:   e1a00001        .word   0xe1a00001
> >    8:   e12fff1e        bx      lr
> 
> This is actually the intended behaviour.  The .word directive is used to 
> enter data not instructions and the ARM port of GAS makes a note of this 
> by emitting a local mapping symbol.  For example if you run:
> 
>    armv5tel-unknown-linux-gnueabi-readelf --syms test.o
> 
> You will see:
> 
>    Symbol table '.symtab' contains 9 entries:
>     Num:    Value  Size Type    Bind   Vis      Ndx Name
>       0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
>       1: 00000000     0 SECTION LOCAL  DEFAULT    1
>       2: 00000000     0 SECTION LOCAL  DEFAULT    3
>       3: 00000000     0 SECTION LOCAL  DEFAULT    4
>       4: 00000000     0 NOTYPE  LOCAL  DEFAULT    1 $a
>       5: 00000004     0 NOTYPE  LOCAL  DEFAULT    1 $d
>       6: 00000008     0 NOTYPE  LOCAL  DEFAULT    1 $a
> 
> 
> It is the $d symbol, entry number 5 in the symbol table, which is 
> telling the disassemble that the word at 0x00000004 is not an 
> instruction but data and so it should not attempt to disassemble it.

>From my perspective, the interpretation of a binary value should primarily be a
function of the type of the section it occurs in, not the mechanism used to put
it there (in this case, .word or symbolic "mov r0, r1"). However, I do realise
that ARM's use of literals pools embedded in .text segments makes it appealing
to not disassembe data values in .text segments.

> It would be possible to add a new pseudo-op, say ".insn", to insert a 
> numeric value into the output and have it be labelled as in instruction, 
> but why bother ?  Do you really need this functionality.  Why not just 
> assemble the instruction normally ?

There are debugging situations where all one gets is some raw object code, and
as a first step one wants to determine the corresponding symbolic form. A
standard way to do that is to

> cat > test.s
        .text
        .globl foo
foo:
        .word 0x...
^D
> as -o test.o test.s; objdump -d test.o

That approach works on pretty much any arch I've ever used, except for recent
binutils releases on ARM.

Here are two recent real-life situations where I've needed this feature:

1. Two months ago I was rebuilding lots of user-space source packages on my ARM
boxes and noticed many "alignment trap" warnings in the kernel log from one
specific package. The kernel log only lists the instruction opcodes in hex, so I
used the above-mentioned recipe to convert the hex values to symbolic form,
except objdump refused to do so. That left me thoroughly confused, and for a
while I wondered if the toolchain had generated invalid object code.

One could try starting the program with gdb and using gdb's disassembler to
inspect those instruction, but that won't work if the addresses of those
instructions vary from run to run (think JITs or .so loading + randomisation).

2. I've been involved with the development of a dynamic binary instrumentation
tool for x86. Occasionally the tool would find an application instruction that
it could decode but not translate/instrument. In those cases it would include
the binary representation of the instruction in the error log. Again, to debug
this one wants to map that binary representation back to symbolic form, and the
above-mentioned recipe is a practical way to do that (with s/.word/.byte/g).

An .insn or .cword (for code .word) directive would solve debugging problems
like mine.

/Mikael


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10263

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.