This is the mail archive of the
mailing list for the GDB project.
Re: Asynchronous GDB
- To: guinan at bluebutton dot com
- Subject: Re: Asynchronous GDB
- From: "Eli Zaretskii" <eliz at is dot elta dot co dot il>
- Date: Thu, 04 Jan 2001 22:51:51 +0200
- CC: gdb at sources dot redhat dot com
- References: <Pine.LNX.firstname.lastname@example.org>
- Reply-to: Eli Zaretskii <eliz at is dot elta dot co dot il>
> Date: Thu, 4 Jan 2001 15:10:05 -0500 (EST)
> From: Jamie Guinan <email@example.com>
> I'm interested in GDB's ability to run asynchronously, like being able to
> examine and modify values without stopping the debugged program.
Forgive me a possibly stupid question, but what does it mean, in
practice, to examine and modify values without stopping the debugged
program? If the debuggee continues to run, the values continue to
change right under your feet, yes? So how do you make sense out of
several values you examine, without having a clue whether they are
consistent with each other or not?
> But I tried running gdb with "--async" and it
> did not appear to run asynchronously (I configured and built gdb from
> And I found this in the info docs,
> Use the asynchronous event loop for the command-line interface.
> GDB processes all events, such as user keyboard input, via a
> special event loop. This allows GDB to accept and process user
> commands in parallel with the debugged process being run(1), so
> you don't need to wait for control to return to GDB before you
> * type the next command. (_Note:_ as of version 5.0, the target *
> * side of the asynchronous operation is not yet in place, so *
> * `-async' does not work fully yet.) *
I see that I was right to add this snippet to the docs: at least we
don't pretend that we do something when the truth is otherwise ;-)