Inspecting Obj-C parameters in gdb
Since the addition of i386 and x86_64 to the Mac OS’s repertoire several years back, remembering which registers are used for what has become difficult, and this can complicate the debugging of code for which you have no symbols. So here is my cheat-sheet (posted here, mostly so that I can find it again without google-ing for old mailing list posts; but, I figure someone else may find it useful as well):
arm (before prolog)
$r0âž¡ arg0 (self)$r1âž¡ arg1 (_cmd)$r2âž¡ arg2$r3âž¡ arg3*($sp)âž¡ arg4*($sp+4)âž¡ arg5*($sp+8)âž¡ arg6
ppc/ppc64
$r3âž¡ arg0 (self)$r4âž¡ arg1 (_cmd)$r5âž¡ arg2$r6âž¡ arg3$r7âž¡ arg4$r8âž¡ arg5
i386 (before prolog)
*($esp+4n)âž¡ arg(n)*($esp)âž¡ arg0 (self)*($esp+4)âž¡ arg1 (_cmd)*($esp+8)âž¡ arg2*($esp+12)âž¡ arg3*($esp+16)âž¡ arg4*($esp+20)âž¡ arg5
i386 (after prolog)
*($ebp+8+4n)âž¡ arg(n)*($ebp+4)âž¡ Return addr*($ebp+8)âž¡ arg0 (self)*($ebp+12)âž¡ arg1 (_cmd)*($ebp+16)âž¡ arg2*($ebp+20)âž¡ arg3*($ebp+24)âž¡ arg4*($ebp+28)âž¡ arg5*($ebp)âž¡ Previous $ebp
x86_64
$rdiâž¡ arg0 (self)$rsiâž¡ arg1 (_cmd)$rdxâž¡ arg2$rcxâž¡ arg3$r8âž¡ arg4$r9âž¡ arg5
So, if you have a method defined as:
-(id)method:(id)foo bar:(id)bar baz:(id)baz
you can print each of the parameters with:
| arm | ppc/ppc64 | x86_64 | i386 (before prolog) | i386 (after prolog) | |
|---|---|---|---|---|---|
| self | po $r0 |
po $r3 |
po $rdi |
po *(id*)($esp) |
po *(id*)($ebp+8) |
| _cmd | p (SEL)$r1 |
p (SEL)$r4 |
p (SEL)$rsi |
p *(SEL*)($esp+4) |
p *(SEL*)($ebp+12) |
| foo | po $r2 |
po $r5 |
po $rdx |
po *(id*)($esp+8) |
po *(id*)($ebp+16) |
| bar | po $r3 |
po $r6 |
po $rcx |
po *(id*)($esp+12) |
po *(id*)($ebp+20) |
| baz | po *(id*)($sp) |
po $r7 |
po $r8 |
po *(id*)($esp+16) |
po *(id*)($ebp+24) |
As Blake mentioned in his comment, on i386, if you’re at the beginning of a function or method, before the prolog has executed (i.e. the bit of code responsible for saving registers, adjusting the stack pointer, etc.), then ebp won’t have been set up for you yet.
So, I’ve amended the above table.
That complexity is another reason I long for the simplicity of PowerPC asm, not to mention M68k asm; at least x86_64 has made the step towards using registers for parameters where possible.
Edited to add: In case it isn’t obvious, these particular stack offsets and registers assignments only make sense when dealing with pointer and integer parameters and return values. When structures and floating point values come into the mix, things can get more complicated.
Edited to add: I’ve added registers/stack offsets for arm. But note that these are for before the prolog has executed. Arm code seems much looser about what happens in its function prologs, so there really isn’t a standard layout post-prolog
Those stack offsets in i386 assume that the prolog has executed. It might be useful to have another list that references %esp, for when someone sets a breakpoint on the function or method symbol.
Indeed, by the time I care about inspecting values, I’m usually well into a function, so I can usually assume that the prolog has already executed.
Clark, great table. I rely on a bunch of really nifty PPC macros I’ve written to inspect parameters, etc. And one of the big hesitations I have to moving to i386 for full-time development/debugging is having to tackle the i386 ABI(s). I feel ya when you say that PPC was so much simpler ;)
Oh, G-d do I miss 68k assembler. Yes, I completely understand that the move to PowerPC was necessary, but the 68k was designed on purpose so that humans could understand it. If you had told me ten years ago that either 68k or x86 would survive into the indefinite future, I’d have thought you a lunatic if you’d insisted it would be x86. PowerPC’s certainly far better than x86, but I’d argue that not even it is nearly as nice for the developer as 68k was (at least at an ISA level).
For as long as I can for the same reason Daniel Jalkut does, I’ll continue using my G5 for development. Hopefully by the time I switch, the significantly less disgusting x86_64 ISA will be standard enough that I can bypass ever having to really learn about the 32-bit API.
thanks a lot for the list!! that’s really helpful!
even after so many years of Intel Macs, i still can’t get my head around to understand this annoying stack stuff…. ppc with its registers is so much easier to understand…
that’s why i still keep my old powerbook around, its really a lifesaver!
x86 assembly isn’t so bad. I wrote a blog post about it:
http://www.drissman.com/blog/archives/2009/05/16/reverseengineering_in_os_x_on_x86.html
thanks for this comparisons!! that’s exactly what I was looking for.
[…] about x86. Despite the present and future of the Mac being x86, it seems like people have lots of anxiety about having to work with it.I think the problem is not a lack of documentation on x86 assembly, […]
It’s been a while since I’ve had to deal with PPC, but from what I remember, the arguments often got shoved into high-numbered registers so the argument registers can be reused to call other functions. This means that, if you’ve gone a little ways into the PPC function, you usually have to inspect the assembly to figure out what register you really need to inspect to find the original arguments. Because of that, I actually prefer x86 for debugging as I can just use gdb user-defined functions to inspect the stack.
[…] è¿™æ˜¯ä¸€ç¯‡å¾ˆå¥½çš„æ–‡ç« ï¼Œå®ƒè®²è§£äº†åœ¨ä¸åŒçš„体系结构下，å‚数是如何å˜å‚¨çš„。ä¸è¿‡å®ƒå¹¶æ²¡æœ‰è®²åˆ°ARM（= =）。所幸ARMçš„å˜å‚¨å¾ˆç®€å•ï¼Œå‚æ•°åªæ˜¯æŒ‰é¡ºåºè¢«å˜å‚¨åœ¨$r0, $r1, $r2, $r3寄å˜å™¨é‡Œã€‚è®°ä½ï¼Œåœ¨æ‰€æœ‰é€šè¿‡å¯„å˜å™¨ä¼ 递å‚数的体系结构里（i386ä¸æ˜¯ï¼‰ï¼Œåªæœ‰åœ¨å‡½æ•°å¼€å¤´çš„一å°æ®µé‡Œï¼Œå¯„å˜å™¨é‡Œå˜çš„æ‰æ˜¯å‚æ•°ã€‚å› ä¸ºåœ¨ç¨‹åºè¿›è¡Œçš„过程ä¸ï¼Œå®ƒä»¬éšæ—¶éƒ½å¯èƒ½è¢«å…¶ä»–å˜é‡æ›¿æ¢æŽ‰ã€‚ […]
[…] compiler translates source code into corresponding assembly language instructions, and where the arguments are placed when calling […]
[…] not yet familiar with how objective-c methods are called, well it’s pretty well described here, at this point we’ll take as fact that $esp contains address of an object whom message is […]
[…] You might ask where I get the register names from. I found a good article on expaining the various registers of the different platforms: “Inspecting Obj-C parameters in gdb“. […]
http://lldb.llvm.org/tutorial.html
has a nice trick for lldb:
(lldb) frame variable
self = (SKTGraphicView *) 0x0000000100208b40
_cmd = (struct objc_selector *) 0x000000010001bae1
sender = (id) 0x00000001001264e0
selection = (NSArray *) 0x00000001001264e0
i = (NSUInteger) 0x00000001001264e0
c = (NSUInteger) 0x00000001001253b0
the “frame variable” command without arguments will give you most of what you want.
One thing I wish your table had was how to see the method return value.
Thanks.
Thanks for this post. This might be also useful in the same context:
Print an exception while it is being thrown:
po $r0 (arm)
po $eax (intel)
[…] Inspecting Obj-C parameters in gdb […]
What about arm64?