Re: debugging on Intel macs
Re: debugging on Intel macs
- Subject: Re: debugging on Intel macs
- From: Eric Albert <email@hidden>
- Date: Thu, 23 Feb 2006 07:03:20 -0800
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:
This email sent to email@hidden