This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]