From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31771 invoked by alias); 16 Mar 2006 03:08:57 -0000 Received: (qmail 31760 invoked by uid 22791); 16 Mar 2006 03:08:56 -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; Thu, 16 Mar 2006 03:08:54 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FJir1-0008KS-Qs; Wed, 15 Mar 2006 22:08:47 -0500 Date: Thu, 16 Mar 2006 07:04:00 -0000 From: Daniel Jacobowitz To: Ed Peschko Cc: gdb@sourceware.org Subject: Re: tracing, attaching to gdb processes Message-ID: <20060316030847.GA31950@nevyn.them.org> Mail-Followup-To: Ed Peschko , gdb@sourceware.org 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> <20060316030013.GA14099@mdssdev05> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060316030013.GA14099@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/msg00090.txt.bz2 On Wed, Mar 15, 2006 at 07:00:13PM -0800, Ed Peschko wrote: > 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. You might want to play around with Unix process groups and shared stdin; it doesn't work quite like you think it does. I'm sure there's some way to do this, but I don't know how. > > 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. "break gdb_stop" at the end of your .gdbinit file will do this. > 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.. GDB already has delayed breakpoints (the term used is "pending"). And it doesn't require any reimplementation if you put it in $HOME/.gdbinit. You might want to spend some time with the existing manual. It's very complete, and it seems like you don't realize a lot of the things GDB is already capable of. You've definitely suggested a couple of things that the manual doesn't make clear, and I'm saving your messages to add to the manual as suggestions at some point. -- Daniel Jacobowitz CodeSourcery