This is the mail archive of the
mailing list for the GDB project.
Re: Asynchronous GDB
>>>>> "Eli" == Eli Zaretskii <email@example.com> writes:
>> Date: Thu, 4 Jan 2001 15:10:05 -0500 (EST)
>> From: Jamie Guinan <firstname.lastname@example.org>
>> I'm interested in GDB's ability to run asynchronously, like being able to
>> examine and modify values without stopping the debugged program.
Eli> Forgive me a possibly stupid question, but what does it mean, in
Eli> practice, to examine and modify values without stopping the debugged
Eli> program? If the debuggee continues to run, the values continue to
Eli> change right under your feet, yes? So how do you make sense out of
Eli> several values you examine, without having a clue whether they are
Eli> consistent with each other or not?
While you're correct that it's difficult to debug a live system, in
some cases it can also be the only way a bug can tracked down.
For example, consider debugging a aggregation router that "can't" go
down. It mostly works, so the customer doesn't want to boot many of
their paying customers for you to track down the bug. With a little
luck, you can peek around global data structures, memory mapped i/o
registers, etc. and get a idea of what might be wrong. If not, well,
you've done your best.
I've done this a bit myself under vxWorks. When you connect to the
WDB agent and not connected to a task, you can still read and write
memory. I wish the remote protocol was the same way.