Re: tracing, attaching to gdb processes

[Daniel Jacobowitz <drow@false.org>]

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.

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

-- 
Daniel Jacobowitz
CodeSourcery