Re: Asynchronous GDB

[jtc at redback dot com (J.T. Conklin)]

>>>>> "Eli" == Eli Zaretskii <eliz@is.elta.co.il> writes:
>> Date: Thu, 4 Jan 2001 15:10:05 -0500 (EST)
>> From: Jamie Guinan <guinan@bluebutton.com>
>> 
>> 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.

        --jtc

-- 
J.T. Conklin
RedBack Networks