[LLVMdev] llvm-objdump

[Kevin Enderby]

Hi Steve,

For the labeltest.s I get:

% llvm-mc -triple x86_64-apple-darwin10 -filetype=obj -o x86_labeltest.o labeltest.s

First with just -v that produces disassembly (without verbose operands):
% otool -tv x86_labeltest.o 
x86_labeltest.o:
(__TEXT,__text) section
foo:
0000000000000000	nop
bar:
0000000000000001	nop
0000000000000002	jmp	0x7
0000000000000007	jmp	0x1
0000000000000009	jmp	0xe
000000000000000e	nop
baz:
000000000000000f	nop


And second with -V that produces “verbose operands”:

% otool -tV x86_labeltest.o 
x86_labeltest.o:
(__TEXT,__text) section
foo:
0000000000000000	nop
bar:
0000000000000001	nop
0000000000000002	jmp	bar
0000000000000007	jmp	bar
0000000000000009	jmp	baz
000000000000000e	nop
baz:
000000000000000f	nop

And third adding -j that prints the opcode bytes:
% otool -tVj x86_labeltest.o 
x86_labeltest.o:
(__TEXT,__text) section
foo:
0000000000000000	90              	nop
bar:
0000000000000001	90              	nop
0000000000000002	e900000000      	jmp	bar
0000000000000007	ebf8            	jmp	bar
0000000000000009	e900000000      	jmp	baz
000000000000000e	90              	nop
baz:
000000000000000f	90              	nop

For me, operands of -3, -5 and 1 are of little use.  If I think the target is assembled wrong I want to see where it thinks it is going (the hex address in the object file) and the opcode bytes so I can hand decode what is going on (more important in things like arm that don’t have simple displacements).

Also if I’m printing symbolic operands like “bar” I don’t want to see the address of bar or the displacement in that case.  Basically I want to see as close to real assembly code as possible.

Also note for Mach-O, we work hard to not have symbols at the same address and not using symbols that are not assembly temporary names.  We use things like 1f, 2b or L21 because we break sections into “atoms” at the symbol addresses by default (when the assembly has the directive .subsections_via_symbols which produces the flag in the header SUBSECTIONS_VIA_SYMBOLS).

Kev

P.S. We also display raw text bytes with just -t and no -v or -V which is useful when debugging very broken objects:

% otool -t x86_labeltest.o 
x86_labeltest.o:
(__TEXT,__text) section
0000000000000000 90 90 e9 00 00 00 00 eb f8 e9 00 00 00 00 90 90


On Aug 26, 2014, at 12:43 PM, Steve King <steve at metrokings.com> wrote:

> Hi Kev,
> I'm glad to hear llvm-objdump is getting attention.  I'm unclear on
> how much output specialization one could (or should) do for ELF vs.
> Mach-O.  If you're game, let's compare an example:
> 
> $ cat labeltest.s
> .text
> foo:
>    nop
> bar:
> bum:
>    nop
>    jmp   bar
>    jmp   bum
>    jmp   baz
>    nop
> baz:
>    nop
> 
> Assembling for x86 and llvm-objdump'ing, i get
> 
> $ llvm-mc -arch=x86 -filetype=obj labeltest.s -o x86_labeltest.o
> $ llvm-objdump -d  x86_labeltest.o
> 
> x86_labeltest.o: file format ELF32-i386
> 
> Disassembly of section .text:
> foo:
>       0: 90                                           nop
> 
> bum:
>       1: 90                                           nop
>       2: eb fd                                         jmp -3
>       4: eb fb                                         jmp -5
>       6: eb 01                                         jmp 1
>       8: 90                                           nop
> 
> baz:
>       9: 90                                           nop
> 
> I get the dump above with or without -symbolize.
> 
> My personal golden reference, GNU objdump, does this:
> 
> $ objdump -dw x86_labeltest.o
> 
> x86_labeltest.o:     file format elf32-i386
> 
> 
> Disassembly of section .text:
> 
> 00000000 <foo>:
>   0: 90                   nop
> 
> 00000001 <bar>:
>   1: 90                   nop
>   2: eb fd                 jmp    1 <bar>
>   4: eb fb                 jmp    1 <bar>
>   6: eb 01                 jmp    9 <baz>
>   8: 90                   nop
> 
> 00000009 <baz>:
>   9: 90                   nop
> 
> What does otool produce?
> 
> 
> On Tue, Aug 26, 2014 at 11:16 AM, Kevin Enderby <enderby at apple.com> wrote:
>> For branch targets my preference is to print the target’s address (not the displacement of the branch), and preferably in hex.
> 
> I like this too.
> 
>> I don’t think having multiple addresses for a target is a real problem with the exception of the address 0 (which is often an unrelocated no addend value).  So the trick is to not print the symbol name in the object with the address of zero in those cases
> 
> Right, relocations are a special case.

The trick here is with otool(1) and -V we will “guess” at operands symbolic value.  That is even if there is no relocation entry and we have a target address that matches a symbol table value we will use that.  And special case the zero value to try to print zero and not the symbol with the zero address the best we can.  I can dig out the logic I came up with that if you want it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140826/e79401e9/attachment.html>