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