This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: tracing, attaching to gdb processes
- From: Bob Rossi <bob at brasko dot net>
- To: Ed Peschko <esp5 at pge dot com>
- Cc: gdb at sourceware dot org
- Date: Mon, 6 Mar 2006 06:55:27 -0500
- Subject: Re: tracing, attaching to gdb processes
- References: <20060306052832.GA12829@mdssdev05>
On Sun, Mar 05, 2006 at 09:28:32PM -0800, Ed Peschko wrote:
> all,
>
> I had a couple of suggestions for gdb, and was wondering if they had either
> been implemented, or were on the 'wish list' to be implemented.
>
>
> 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.
For this problem, couldn't you simply have valgrind either start GDB in
screen so that you could attach to it when you want, or use a graphical
debugger (xterm -e gdb)?
Bob Rossi