From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eli Zaretskii" To: guinan@bluebutton.com Cc: gdb@sources.redhat.com Subject: Re: Asynchronous GDB Date: Thu, 04 Jan 2001 12:53:00 -0000 Message-id: <1659-Thu04Jan2001225150+0200-eliz@is.elta.co.il> References: X-SW-Source: 2001-01/msg00006.html > Date: Thu, 4 Jan 2001 15:10:05 -0500 (EST) > From: Jamie Guinan > > 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 > ftp://sourceware.cygnus.com/pub/gdb/releases/insight-5.0.tar.bz2 ). > And I found this in the info docs, > > `-async' > 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 ;-) >From guinan@bluebutton.com Thu Jan 04 15:10:00 2001 From: Jamie Guinan To: Eli Zaretskii Cc: Gdb List Subject: Re: Asynchronous GDB Date: Thu, 04 Jan 2001 15:10:00 -0000 Message-id: References: <1659-Thu04Jan2001225150+0200-eliz@is.elta.co.il> X-SW-Source: 2001-01/msg00007.html Content-length: 1850 On Thu, 4 Jan 2001, Eli Zaretskii wrote: > > Date: Thu, 4 Jan 2001 15:10:05 -0500 (EST) > > From: Jamie Guinan > > > > 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? Yes, values could certainly change under your feet, and the user should consider that when doing asynchronous debugging. My interest is in embedded applications. For a trivial example, suppose you had a program that had to run without stopping, such as reading rotary encoders attached to live machinery, or routing ATM packets in a core network environment. You might have counters in your code that you would want to examine, and while the exact numbers might change, you might want to know whether a value at a given instant is on the order of 5 or 1000 or 1000000. Snapshots, essentially. Or you might have polled flag variables in your program that enable or disable certain features, you could use GDB to set them. Since GDB knows where objects are located from the symbol table, and it can interpret data structures, it would be a valuable tool in this kind of situation. > 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 ;-) Yes, thanks for documenting that, I would have thought I was doing something wrong/stupid (not unusual) when it didn't work. :) Regards, -Jamie