Re: debugging on Intel macs
Re: debugging on Intel macs
- Subject: Re: debugging on Intel macs
- From: Aurélien Hugelé <email@hidden>
- Date: Thu, 06 Apr 2006 20:36:05 +0200
I'm really sorry to bother you with this, but i don't understand
anything...
(gdb) po *(int *) ($esp + 4)
sometimes display "self" (objC speaking), which is equivalent to $r3
on PPC
sometimes causes a KERN_PROTECTION_FAILURE
sometimes display "something" which is not self nor an argument.
Can you please describe the rule (i hope it is simple, but i fear
that it's a total mess) if there is one, I'm only interested in objC/
Cocoa debugging...
i want the self argument
the _cmd argument (current selector)
and the possible folowing arguments
Thanks a lot, i'm totally lost and unproductive with my new iMac :(
On 6 avr. 06, at 19:48, Eric Albert wrote:
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:
40outofcheese.org
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:
40outofcheese.org
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