From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23210 invoked by alias); 16 Mar 2006 03:00:24 -0000 Received: (qmail 23201 invoked by uid 22791); 16 Mar 2006 03:00:23 -0000 X-Spam-Check-By: sourceware.org Received: from mta07.pge.com (HELO mta07.pge.com) (131.90.0.77) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 16 Mar 2006 03:00:22 +0000 Received: from mta17.comp.pge.com (mta17.comp.pge.com [10.244.4.52]) by mta07.pge.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2G30K3k023018 for ; Wed, 15 Mar 2006 19:00:20 -0800 (PST) Received: from mdssdev05.comp.pge.com (mdssdev05.comp.pge.com [10.244.96.61]) by mta17.comp.pge.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k2G30EHm018393; Wed, 15 Mar 2006 19:00:14 -0800 (PST) Received: (from esp5@localhost) by mdssdev05.comp.pge.com (8.11.7p1+Sun/8.11.7) id k2G30EM14120; Wed, 15 Mar 2006 19:00:14 -0800 (PST) Date: Thu, 16 Mar 2006 03:08:00 -0000 From: Ed Peschko To: gdb@sourceware.org Cc: esp5@pge.com Subject: Re: tracing, attaching to gdb processes Message-ID: <20060316030013.GA14099@mdssdev05> References: <20060306052832.GA12829@mdssdev05> <20060314022809.GA1335@nevyn.them.org> <20060315030437.GE10146@mdssdev05> <20060315034420.GA1616@nevyn.them.org> <20060315041618.GB12493@mdssdev05> <20060315142230.GA12258@nevyn.them.org> <20060315231846.GA13847@mdssdev05> <20060315233739.GA27218@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060315233739.GA27218@nevyn.them.org> 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/msg00089.txt.bz2 On Wed, Mar 15, 2006 at 06:37:39PM -0500, Daniel Jacobowitz wrote: > On Wed, Mar 15, 2006 at 03:18:46PM -0800, Ed Peschko wrote: > > On Wed, Mar 15, 2006 at 09:22:31AM -0500, Daniel Jacobowitz wrote: > > > Stopping on input is a bit more complicated than you think. Whenever > > > the program is running, it has control of the terminal - and input goes > > > to it, not to us. I don't see an easy way to do this. > > > > The way to do it is thorugh something similar to ReadKey - For example, the > > following perl script does sort of what I'd want: > > No, sorry, you did not understand my explanation of the problem. The > program being run is usually on the same terminal as GDB. If it reads, it > will consume the input. Ok, that's fine, I get what you are saying now. But its really punishing 99% of the programs out there for the requirements of the remaining 1%. Either they ignore stdin altogether, or take a bunch of stdin input and go into 'processing' mode, after which they don't need to touch stdin. In any there could be a variable (call it set no_block_read) which toggles it so that the user sends input to gdb rather than the underlying program. Then the user would type: (gdb) set no_block_read=qq (gdb) while 1; > step > db_sleep .1 > end and now if users input the string 'qq' it would cause the label to stop. In fact you could be really fancy about it - namely, if a process *was* expecting stdin, that the no_block_read would continue until it got input from stdin, which it would then compare against whatever was listed in 'no_block_read'. Example: .... strings of input ... *user presses 'qq'. ... strings of input ... gets fed to program, qq stops loop, and the input qq gets discarded. Of course this slows down the feeding of input, but it wouldn't be the default so that would be fine.. And I'd think it would be relatively easy to implement because you have to toggle between input streams anyways so people can enter commands to gdb. And finally IMO the current behaviour is broken. As you yourself stated, having an infinite loop in scripting is basically useless. > No; that library is only used in the creation of GDB, it should never > be linked to anything but GDB. It's just a convenience during the > build process. Once upon a time there were experiments with linking > things to GDB directly; eventually we decided that controlling it > through a pipe was a better choice. I'd put it the docs then. > Feel free: > > void gdb_stop (void) { } > > (gdb) break gdb_stop > > Or put it in a .gdbinit file that you ship with the application. Or a hook could be put into gdb which automatically inserts a breakpoint on the function name 'gdb_stop' if it exists. I mean, think of what happens if gdb_stop is defined in a place which is dynamically loaded? Then the users' setting of the breakpoint will fail. Having gdb check upon loading a symbol for the gdb_stop function makes it much easier. And even if the functionality for delayed breakpoints is added to gdb, it still is forcing the user to reimplement something for each project he/she works on.. Ed