Re: tracing, attaching to gdb processes

Ed Peschko
2006-03-15T03:04:43Z

On Mon, Mar 13, 2006 at 09:28:09PM -0500, Daniel Jacobowitz wrote:
> On Sun, Mar 05, 2006 at 09:28:32PM -0800, Ed Peschko wrote:
> > 1) trace mode. I'd like the ability to set a time delay between how often
> > statements are executed, and then have gdb show the statements as they
> > *are* being executed.
> >
> > dbx has this, and its a lifesaver. You set 'trace' on, and then hit
> > 'c' - and you see the program steps and code that get executed realtime.
> >
> > To be real useful, you should be able to start the trace, choose whether
> > or not you are going to use 'step' mode (ie: show each step as its executed)
> > or 'next' mode (ie: skip over subroutines). And you should be able to hit
> > a button to stop execution at any given time.
>
> In general, you can get this by having a loop that does "while 1; step;
> shell sleep 1" and hitting Control-C to stop it. Anything more
> complicated than that involves the "hitting a button to stop" concept,
> which means a GUI should be issuing the step commands - that's easy
> to do when you're driving GDB.

I don't understand..

Are you suggesting that I make an expect script to control gdb, and then have
that control script pass characters to the underlying process? Or something
more exotic?

And why can't this be built into gdb in the form of a 'set' variable? Either that,
or a built-in high-resolution 'sleep' call that doesn't require spawning a shell?

Or best yet, a builtin non-blocking read call that waits for a person's input?

> > 2) attach mode. I've noticed, especially with testing services through xinetd,
> > that you can't always expect to have a gdb session come up visibly.
> >
> > For example, I was testing cvs the other day through valgrind, and it has a
> > --db-command option for firing up a debugger if a memory leak occurs.
> > If you are in a shell, this is no big deal. But if the service runs through
> > something like valgrind, the gdb debugger gets fired up in a non-interactive
> > place. I'd like to have the ability to attach to the gdb command from a window
> > and be able to interact with the gdb session from there.
>
> Of course GDB supports attaching to processes. It's just valgrind
> that's a problem child, since the way valgrind starts up a GDB to talk
> to is so strange. For everything else, you just stop the affected
> process when you want to debug it, and gdb FILE PID to attach at your
> leisure. Having valgrind create a screen session instead of a gdb
> is probably your easiest solution.

well, I was thinking of something like gdbserver (which I wasn't aware existed)
but now I see what people were talking about when they were saying 'use screen
with your gdb processes' - I wasn't aware that screen could be started already
detached, nor that you could run an alternate shell with screen (eg: 'gdb').

Anyways, maybe this warrants an entry in the manual - its not only valgrind that
could benefit from this workflow, but other processes, especially those run
through inetd.

It would be very cool, for example, if you could somehow trigger gdb to run with
an instantiated call, say:

/* my code here */
spawn_gdb()
/* my code here */

and then a gdb would be spawned automatically and attached to the process at the
point right following the spawn_gdb call.

I know that people could probably cook something up like this on their own,
but IMO it makes a lot of sense to be distributed with gdb - you could simply
use the above function and link with -lgdb to get the functionality wanted. And
it really would revolutionize the way that daemon processes get debugged,
letting them be debugged in-situ. (no more 'CVS_SERVER_SLEEP' for example,
to cause the cvs server to sleep for x seconds so you can whip out
'ps -ef | grep cvs', find the child process and attach to it before time runs out. )

Ed