From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10543 invoked by alias); 6 Mar 2006 20:10:59 -0000 Received: (qmail 10535 invoked by uid 22791); 6 Mar 2006 20:10:58 -0000 X-Spam-Check-By: sourceware.org Received: from mta01.pge.com (HELO mta01.pge.com) (131.89.129.71) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 06 Mar 2006 20:10:55 +0000 Received: from mta11.comp.pge.com (mta11.comp.pge.com [10.245.211.126]) by mta01.pge.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k26KAMGN013151; Mon, 6 Mar 2006 12:10:29 -0800 (PST) Received: from mdssdev05.comp.pge.com (mdssdev05.comp.pge.com [10.244.96.61]) by mta11.comp.pge.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k26KAM1p003485; Mon, 6 Mar 2006 12:10:22 -0800 (PST) Received: (from esp5@localhost) by mdssdev05.comp.pge.com (8.11.7p1+Sun/8.11.7) id k26KACO14497; Mon, 6 Mar 2006 12:10:12 -0800 (PST) Date: Mon, 06 Mar 2006 20:10:00 -0000 From: Ed Peschko To: Dave Korn Cc: "'Bob Rossi'" , gdb@sourceware.org Subject: Re: tracing, attaching to gdb processes Message-ID: <20060306201012.GA14453@mdssdev05> References: <20060306115527.GA17491@brasko.net> <055601c64115$a2b494a0$a501a8c0@CAM.ARTIMI.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <055601c64115$a2b494a0$a501a8c0@CAM.ARTIMI.COM> User-Agent: Mutt/1.4.2.1i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00047.txt.bz2 On Mon, Mar 06, 2006 at 12:01:00PM -0000, Dave Korn wrote: > 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 > -- well, the X11 solution was the one I thought of first, but I don't always have a X11 connection (I do most of my stuff over screen), and two, since valgrind is run under inetd, its not in an interactive terminal, so I would be very interested to know if I *could* redirect the gdb session to a screen, and if so, how. WRT gdbserver, I'm not sure - I need to start the gdb with the format gdb -nw %f %p, ie: be able to write to the executable or core file, and to be able to attach to the process. I guess I also need to stop the gdbserver each time I do this, the gdb through valgrind is a blocking call.. Anyways, thanks for the suggestions. I'm assuming that the 'trace' mode, on the other hand does not exist? Ed