Re: Asynchronous GDB

Re: Asynchronous GDB

[James Cownie]

Jamie Guinan wrote :

> I'm interested in GDB's ability to run asynchronously, like being able to
> examine and modify values without stopping the debugged program.  

Depending on the operating system this may not be possible no matter
how gdb works. On systems which use the ptrace interface for debugging
(e.g. Linux, AIX) the ptrace system call itself _requires_ that the
target process be stopped before allowing the debugger to delve around
inside it.

Taking linux/x86 as a "for instance", here's the relevant code for the
sys_ptrace in arch/i386/kernel/ptrace.c
...
	if (child->state != TASK_STOPPED) {
		if (request != PTRACE_KILL)
			goto out;
	}
...

In other words the only thing you can do via ptrace to an unstopped
process is kill it.

-- Jim 

James Cownie	<jcownie@etnus.com>
Etnus, LLC.     +44 117 9071438
http://www.etnus.com

Re: Asynchronous GDB

[Andrew Cagney]

> In other words the only thing you can do via ptrace to an unstopped
> process is kill it.

Unless the target has several processes and one is dedicated to
debugging that will always be the case.  Some code somewhere will need
to stop the system just long enough to capture the required information
and then resume it.

The main thing is that it is pushed down towards the target and away
from the debug core.

In terms of async debugging, its been demoed working with single
threaded remote target but not much else.  There are still some fairly
fundamental design problems in the way :-(

	Andrew

Re: Asynchronous GDB

[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

Re: Asynchronous GDB

[Jamie Guinan]

On Thu, 4 Jan 2001, Eli Zaretskii wrote:

> > 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.  
> 
> 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

Re: Asynchronous GDB

[Eli Zaretskii]

> 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.  

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 ;-)

Asynchronous GDB

[Jamie Guinan]

Hello,

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
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.)				*

	 When the standard input is connected to a terminal device, GDB
	 uses the asynchronous event loop by default, unless disabled by
         the
	 `-noasync' option.

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.

Questions:
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.
-Jamie