Re: (no subject) (xcode gdb attach)
Re: (no subject) (xcode gdb attach)
- Subject: Re: (no subject) (xcode gdb attach)
- From: Jim Ingham <email@hidden>
- Date: Wed, 19 Nov 2003 14:20:45 -0800
Tim,
On Nov 19, 2003, at 2:06 PM, Tim Gogolin wrote:
Thanks, but if I understand correctly, this requires some foresight on
my part (it has steps that must be done before running the program).
If I knew I was going to need debugging, I could have just launched my
app via the debugger...
Maybe I was unclear, but you don't need to have prep'ed anything.
Suppose you are running your app outside of Xcode. Your app puts up a
dialog box that alarms you, and you want to attach and debug.
No sweat... If Xcode is not running, you start up Xcode. Then open
the Project that builds that app.
Now, you want to start up a debug session in Xcode, but you don't want
to use the instance of the app that is going to be started by it. So
you set a breakpoint at main, and click Debug. Then when the second
copy of your App hits the breakpoint, you immediately "kill" it. Now
you have an Xcode debug session that you can then use "attach" to
switch over to the running copy of your app.
All this can be done after your App has launched.
But thanks for the unsupported, disgusting, and thoroughly
entertaining hack :-)
I'm looking forward to xcode having the ability to attach to a running
process. Bonus karma points if this behavior could be triggered
programatically (i.e. if my app, having shown an internal inspection
dialog, could *cause* xcode to attach and/or break as a result of me
pressing one of the dialog buttons)
All this should be possible in the fullness of time.
Jim
--
Tim Gogolin
On Nov 19, 2003, at 3:50 PM, Jim Ingham wrote:
Attaching to a running process is definitely one of the things that
we intend to support, but with all the changes from PB to Xcode, we
didn't get to it yet. So no, there is no nice GUI way to do this.
The following fairly disgusting and totally unsupported hack does
work, however:
In Xcode, set a breakpoint at main, run your app, then when you stop
at main, open the gdb console, type "kill". This will kill off the
running program but leaving gdb still running. So then you can issue
the "attach <PID>" command in the console, that will attach gdb to
the real version of your app. Now you need to convince Xcode that
the target process is actually there. I usually do this by typing
"stepi" in the gdb console. The point is that when the target stops
gdb will send a message to Xcode telling it this, and then Xcode will
nicely sync up with the target, get the backtrace, etc. stepi is the
smallest forward you can move the app (step one instruction), so it
is the safest way to get it to move a bit and then stop.
Hope this helps,
Jim
On Nov 19, 2003, at 12:44 PM, Tim Gogolin wrote:
My situation:
I have an app (built in xcode) that can detect an internal error
situation and post a modal dialog that helps me understand part of
the problem. The dialog is posted via [myApp runModalForWindow: w],
so the stack is still intact. If I switch to the terminal, run gdb,
and "attach" to the process I can get a good back trace.
Presumably I could continue to debug from the command line (ouch,
command line debugging). The project is open in xcode and I launched
the app from xcode (but not by using the "debug" command). Is there
any way to "change my mind" and get the debugging UI up and running,
in the same way that command line gdb will allow one to start
debugging after the app has already been running normally?
--
Tim Gogolin
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.
--
Jim Ingham email@hidden
Developer Tools
Apple Computer
--
Jim Ingham email@hidden
Developer Tools
Apple Computer
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.