This is the mail archive of the
mailing list for the GDB project.
- To: Gdb List <gdb at sources dot redhat dot com>
- Subject: Asynchronous GDB
- From: Jamie Guinan <guinan at bluebutton dot com>
- Date: Thu, 4 Jan 2001 15:10:05 -0500 (EST)
- Reply-To: guinan at bluebutton dot com
I'm interested in GDB's ability to run asynchronously, like being able to
examine and modify values without stopping the debugged program.
Eventually I'd like this to work in a cross-gdb environment with a custom
RISC processor my company is working on, but I thought I'd try it with a
native Linux build first so that I could see how gdb handles async
debugging internally. 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.) *
When the standard input is connected to a terminal device, GDB
uses the asynchronous event loop by default, unless disabled by
I've only just started looking at the sources, and it appears that
event_loop_p and target_async_p() are integral to the whole async
mechanism, so I'll start digging around where I see them.
1. Should I be using CVS or snapshots to test async support?
2. Is there any target support in CVS or snapshots?
3. If so, for which targets?
Thanks for your advice.