5

I'm trying to figure out what all of the elements of this objdump -d mean.

for example i have:

08048b50 <phase_1>:
8048b50:    83 ec 1c                sub    $0x1c,%esp
 8048b53:   c7 44 24 04 68 a2 04    movl   $0x804a268,0x4(%esp)
 8048b5a:   08 
 8048b5b:   8b 44 24 20             mov    0x20(%esp),%eax
 8048b5f:   89 04 24                mov    %eax,(%esp)
 8048b62:   e8 63 04 00 00          call   8048fca <strings_not_equal>
 8048b67:   85 c0                   test   %eax,%eax
 8048b69:   74 05                   je     8048b70 <phase_1+0x20>
 8048b6b:   e8 f5 06 00 00          call   8049265 <explode_bomb>
 8048b70:   83 c4 1c                add    $0x1c,%esp
 8048b73:   c3                      ret

specifically im not sure what the 1st and center columns are telling me

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Ted
  • 487
  • 2
  • 12
  • 23

2 Answers2

6

The first column tells you the memory addresses where the code will be located at runtime.

The second column has the hex version of the executable instruction.

The third (and forth) columns, have a disassembled version of the second column. i.e. opcode and operands.

imreal
  • 10,178
  • 2
  • 32
  • 48
  • ok thanks -- is it possible to get a string representation of the values in the registers? for example, i step through my program to the line 8048b67: 85 c0 test %eax,%eax i want to know the string that %eax is testing against – Ted Feb 13 '14 at 00:29
  • If you are using gdb: `info registers` to see all of them or `info registers [register name]` for a specific one. Which debugger are you using? – imreal Feb 13 '14 at 00:31
  • ok thanks again -- one more question -- what do the last two columns mean when i do info registers? ex: eax 0x804c800 134531072 – Ted Feb 13 '14 at 00:33
  • 1
    The second column is hex representation of the stored value and the third one is decimal of the same number. – imreal Feb 13 '14 at 00:36
  • is there any way to get a string representation? (yes, im using gdb) – Ted Feb 13 '14 at 00:37
  • I can't remember it that well, but after getting the address, use `print /s [address]` – imreal Feb 13 '14 at 00:43
  • Technically, the first column is only the *default* load address. The operating system can usually move it to a different address by offsetting everything when it is actually loaded. – ughoavgfhw Feb 13 '14 at 02:39
  • @ughoavgfhw Isn't that true only for libraries? – imreal Feb 13 '14 at 18:07
  • @Nick With [ASLR](http://en.wikipedia.org/wiki/ASLR), it can happen for programs too. – ughoavgfhw Feb 13 '14 at 18:58
  • Regarding the second column of `objdump` output: what does it mean that it's a, "... hex version of the executable instruction?" For example, in the above with respect to the `mov` instructions, the "second" column begins with **8b** for the first and **89** for the other. Why wouldn't they both be the same? – Andrew Falanga May 19 '16 at 22:54
  • @AndrewFalanga Different instructions, see https://pdos.csail.mit.edu/6.828/2006/readings/i386/MOV.htm – imreal May 20 '16 at 00:01
1

first : address, hex. The difference between two adjacent addresses is the number of machine codes.

second : Machine code, hex.

third : Assembler code, disassembled from machine code.

execute 'objdump -no-leading-addr -S **.o', the first column will be hidden.

objdump --version Apple LLVM version 11.0.0 (clang-1100.0.33.17)

Sodino
  • 587
  • 6
  • 16
  • Note that most systems other than MacOS will have `objdump` being the GNU Binutils version, where the corresponding option is `--no-addresses`. (And there's also a `--no-show-raw-insn` option). On non-MacOS, if it's installed at all, LLVM's objdump is often installed as `llvm-objdump`. – Peter Cordes May 20 '21 at 15:45