Re: debugging on Intel macs
Re: debugging on Intel macs
- Subject: Re: debugging on Intel macs
- From: Eric Albert <email@hidden>
- Date: Thu, 6 Apr 2006 10:48:38 -0700
It should work fine...but for functions with frames. objc_msgSend is a
bunch of handcrafted assembly which doesn't use ëp as a frame
pointer, so its arguments are %esp-relative. This means that when you
break on it you have a pointer to the first argument in %esp + 4:
(gdb) po *(int *) ($esp + 4)
<NSApplication: 0x315c40>
(gdb)
-Eric
On Apr 6, 2006, at 7:29 AM, Aurélien Hugelé wrote:
Hello every one,
I'm trying to use $ebp + 8, ebp + 12 in place of $r3,$r4 in GDB as
nicely explained by Eric, but it does not work on my new Intel Imac:
(gdb) po $ebp + 8
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x90a4e387 in objc_msgSend ()
The program being debugged was signaled while in a function called
from GDB.
GDB has restored the context to what it was before the call.
To change this behavior use "set unwindonsignal off"
Evaluation of the expression containing the function
(_NSPrintForDebugger) will be abandoned.
using po $r3 at the very same line of code on a PPC returns the
description of self...
can you help me? being able to **easily** get the equivalent of
self/_cmd/etc... is vital to me!
Using GCC 4 on Intel Core Duo, OS X 10.4.6, XCode 2.2.1.
Thanks,
Aurelien
On 23 févr. 06, at 16:03, Eric Albert wrote:
This is the same regardless of optimization. At higher optimizations
you're slightly more likely to run into the rare exceptions I
mentioned, but they're still pretty unusual.
-Eric
On Feb 23, 2006, at 5:24 AM, Aurélien Hugelé wrote:
You are my savior! it does seem very simple indeed!
Is this still true whatever the optimization is (-O3 -Os or -O0) ?
(sorry if the question is stupid and unrelated to the problem, i'm a
total newby on this things, but i love using po $r3 po
NSStringFromSelector($r4) and po $r5 to see what happens in someone
else code...)
On 20 févr. 06, at 11:19, Eric Albert wrote:
Sorry I'm late to this thread; I was away last week.
Printing arguments on Intel really isn't all that hard. On
PowerPC, you'd print $r3, $r4, $r5, etc. On Intel, it's $ebp + 8,
$ebp + 12, $ebp + 16, etc.
There are some rare circumstances in which the compiler may pass
the first argument in a register or in which the first argument
will be in $ebp + 12, but those don't happen often so it's easiest
to not worry about them. The $esp-relative addressing Jonas
mentioned for frameless functions doesn't get generated by gcc on
Mac OS X, so you only have to worry about that if you're debugging
handcoded assembly.
Hope this helps,
Eric
On Feb 15, 2006, at 4:24 AM, Aurélien Hugelé wrote:
Thanks for your explanations. As i feared, it is way above me...
I'll keep a powermac around for several years just to debug
someone-else's code :)
Damn x86
long live to PPC !
On 15 févr. 06, at 10:29, Jonas Maebe wrote:
On 15 feb 2006, at 10:17, Aurélien Hugelé wrote:
Can someone confirm my fears ? will I be able to print "self"
in $r3, the current selector in $r4 and arguments in $r5 -> rX
? or things will be different ?
Just print the parameters/variables by name, gdb will fetch
them from the correct location. Also note that printing the
contents of those registers on PPC will give you wrong results
in many instances, because the parameters are only guaranteed
to be in those registers at the start of the routine. They can
be located anywhere (including in memory) inside the body of
the routine.
i forgot to add that i use GDB for something other than my
code... so i do not know the names of parameters and
variables....
i often add a (future)breakpoints to cocoa's method and look at
their arguments etc... to know how to use it...
First of all, your idea that all PPC arguments are passed in
r3->rX is wrong. It's r3->r10, and the rest is also passed on the
stack on PPC. Of course, it doesn't happen that often that your
run out of registers.
Apple's x86 abi is documented at
http://developer.apple.com/documentation/DeveloperTools/
Conceptual/LowLevelABI/Articles/IA32.html#//apple_ref/doc/uid/
TP40002492-SW4
They do not use registers to pass parameters in any case. If a
function has a frame pointer and already set up its stack frame,
you can view the first parameter using "x/x $ebp+8", the second
using "x/x $ebp+12" etc. If the frame pointer is optimized away,
you'll have to disassemble the code to see by how much the stack
pointer (esp) has already been changed and then look at the right
offset relative to esp (also using x/x). The parameters start at
"x/x $esp+4" (x/x $esp is the return address) as long as esp is
not yet modified.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
--
Eric Albert email@hidden
http://outofcheese.org/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
--
Eric Albert email@hidden
http://outofcheese.org/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden