From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13677 invoked by alias); 15 Mar 2006 03:44:26 -0000 Received: (qmail 13668 invoked by uid 22791); 15 Mar 2006 03:44:25 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Wed, 15 Mar 2006 03:44:22 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FJMvs-0000SQ-Db; Tue, 14 Mar 2006 22:44:20 -0500 Date: Wed, 15 Mar 2006 03:45:00 -0000 From: Daniel Jacobowitz To: Ed Peschko Cc: gdb@sourceware.org Subject: Re: tracing, attaching to gdb processes Message-ID: <20060315034420.GA1616@nevyn.them.org> Mail-Followup-To: Ed Peschko , gdb@sourceware.org References: <20060306052832.GA12829@mdssdev05> <20060314022809.GA1335@nevyn.them.org> <20060315030437.GE10146@mdssdev05> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060315030437.GE10146@mdssdev05> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes 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/msg00069.txt.bz2 On Tue, Mar 14, 2006 at 07:04:37PM -0800, Ed Peschko wrote: > > In general, you can get this by having a loop that does "while 1; step; > > shell sleep 1" and hitting Control-C to stop it. Anything more > > complicated than that involves the "hitting a button to stop" concept, > > which means a GUI should be issuing the step commands - that's easy > > to do when you're driving GDB. > > I don't understand.. > > Are you suggesting that I make an expect script to control gdb, and then have > that control script pass characters to the underlying process? Or something > more exotic? The GDB CLI scripting language has "while". See the manual. It won't work very well though. The C-c will stop the sleep, but not the while. > And why can't this be built into gdb in the form of a 'set' variable? Either that, > or a built-in high-resolution 'sleep' call that doesn't require spawning a shell? You asked if GDB could do what you wanted; this is how it can. I don't know whether it should have a built in command to do this or not. > Or best yet, a builtin non-blocking read call that waits for a person's input? I fail to see how this relates to what you wanted. > well, I was thinking of something like gdbserver (which I wasn't aware existed) > but now I see what people were talking about when they were saying 'use screen > with your gdb processes' - I wasn't aware that screen could be started already > detached, nor that you could run an alternate shell with screen (eg: 'gdb'). > > Anyways, maybe this warrants an entry in the manual - its not only valgrind that > could benefit from this workflow, but other processes, especially those run > through inetd. Maybe. > It would be very cool, for example, if you could somehow trigger gdb to run with > an instantiated call, say: > > /* my code here */ > spawn_gdb() > /* my code here */ > > and then a gdb would be spawned automatically and attached to the process at the > point right following the spawn_gdb call. GDK/GTK already have code to do this. So do lots of other libraries. It's not something that needs to be distributed with GDB; it's just if (fork () == 0) execlp ("gdb", argv[0], getppid (), NULL); -- Daniel Jacobowitz CodeSourcery