CODEWITHSUNDEEP
c++carmobjdump
tdao
tdao

Reputation: 17713

Library function objdump output

I have the following objdump output when debugging a crash. I could narrow down the issue to the following function LanManager::Interface() library function, but with my little experience with object code I haven't been able to work out much more sense from the objdump output.

Below is the beginning part of that library function. I'd like to know:

I won't expect a complete answer, just anything that sheds some light would be appreciated.

0003629c <LanManager::Interface()>:
   3629c:   e1a0c00d    mov ip, sp
   362a0:   e92dd9f0    push    {r4, r5, r6, r7, r8, fp, ip, lr, pc}
   362a4:   e59f40b8    ldr r4, [pc, #184]  ; 36364 <LanManager::Interface()+0xc8>
   362a8:   e24cb004    sub fp, ip, #4  ; 0x4
   362ac:   e24dd004    sub sp, sp, #4  ; 0x4
   362b0:   e59f70b0    ldr r7, [pc, #176]  ; 36368 <LanManager::Interface()+0xcc>
   362b4:   e08f4004    add r4, pc, r4
   362b8:   e59f50ac    ldr r5, [pc, #172]  ; 3636c <LanManager::Interface()+0xd0>
   362bc:   e7940007    ldr r0, [r4, r7]
   362c0:   ebff6dc9    bl  119ec <_init+0x10e4>
   362c4:   e7942005    ldr r2, [r4, r5]
   362c8:   e5923000    ldr r3, [r2]
   362cc:   e3530000    cmp r3, #0  ; 0x0
   362d0:   0a000005    beq 362ec <LanManager::Interface()+0x50>
   362d4:   e7943005    ldr r3, [r4, r5]
   362d8:   e7940007    ldr r0, [r4, r7]
   362dc:   e5934000    ldr r4, [r3]

Upvotes: 0

Views: 2100

Answers (1)

Tryke
Tryke

Reputation: 800

I'll try to shed a little light here, but for more depth you may want to check out a text on assembly programming in ARM or reverse engineering.

You're looking at the disassembly for LanManager::Interface. Yes, 0003629c is the value of the function pointer itself. Your three columns look like:

| address | opcodes | disassembly |

_init is another symbol somewhere in the file you disassembled. It seems kinda weird that LanManager::Interface would branch to some location a whole page away from the start of another function.

When a binary has had its symbols stripped, and objdump is trying to determine the symbolic name for an address, it will keep scanning backwards until it eventually finds one. Likely that _init is just the entry point or something, I've forgotten the names emitted by the compiler off the top of my head.

You can poke around in gdb and disassemble specific addresses with (gdb) disas *0x119ec. However you really never say what sort of crash you're looking at in the first place... if you wrote a program that's dying on a library call I would spend more time looking at arguments you passed in.

Upvotes: 1

Related Questions