From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22789 invoked by alias); 6 Mar 2006 05:28:38 -0000 Received: (qmail 22775 invoked by uid 22791); 6 Mar 2006 05:28:37 -0000 X-Spam-Check-By: sourceware.org Received: from mta04.pge.com (HELO mta04.pge.com) (131.89.129.74) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 06 Mar 2006 05:28:35 +0000 Received: from mta12.comp.pge.com (mta12.comp.pge.com [10.245.211.127]) by mta04.pge.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k265SXED014133 for ; Sun, 5 Mar 2006 21:28:33 -0800 (PST) Received: from mdssdev05.comp.pge.com (mdssdev05.comp.pge.com [10.244.96.61]) by mta12.comp.pge.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k265SXqF017331; Sun, 5 Mar 2006 21:28:33 -0800 (PST) Received: (from esp5@localhost) by mdssdev05.comp.pge.com (8.11.7p1+Sun/8.11.7) id k265SWk12841; Sun, 5 Mar 2006 21:28:32 -0800 (PST) Date: Mon, 06 Mar 2006 05:28:00 -0000 From: Ed Peschko To: gdb@sourceware.org Cc: esp5@pge.com Subject: tracing, attaching to gdb processes Message-ID: <20060306052832.GA12829@mdssdev05> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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/msg00039.txt.bz2 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. 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. 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. Anyways, #1 I think would be more generally useful, but #2 would be very nice in lots of situations too, IMO. Have either of these been implemented? Ed