This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: tracing, attaching to gdb processes
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: "'Bob Rossi'" <bob at brasko dot net>, "'Ed Peschko'" <esp5 at pge dot com>
- Cc: <gdb at sourceware dot org>
- Date: Mon, 6 Mar 2006 12:01:00 -0000
- Subject: RE: tracing, attaching to gdb processes
On 06 March 2006 11:55, Bob Rossi wrote:
> 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
Or have valgrind attach a gdbserver instance to the faulting process, and
then connect locally to _that_ with gdb?
cheers,
DaveK
--
Can't think of a witty .sigline today....