From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19387 invoked by alias); 14 Mar 2007 08:34:35 -0000 Received: (qmail 19377 invoked by uid 22791); 14 Mar 2007 08:34:34 -0000 X-Spam-Check-By: sourceware.org Received: from mta06.pge.com (HELO mta06.pge.com) (131.90.0.76) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 14 Mar 2007 08:34:28 +0000 Received: from mta12.comp.pge.com (mta12.comp.pge.com [10.245.211.127]) by mta06.pge.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id l2E8YCqU004033; Wed, 14 Mar 2007 01:34:13 -0700 (PDT) Received: from mdssdr01.utility.pge.com (mdssdr01.utility.pge.com [10.244.52.48]) by mta12.comp.pge.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l2E8YB0e025254; Wed, 14 Mar 2007 01:34:11 -0700 (PDT) Received: (from esp5@localhost) by mdssdr01.utility.pge.com (8.11.7p3+Sun/8.11.7) id l2E8Y9k21838; Wed, 14 Mar 2007 01:34:09 -0700 (PDT) Date: Wed, 14 Mar 2007 08:34:00 -0000 From: "Ed S. Peschko" To: Eli Zaretskii Cc: gdb@sourceware.org Subject: Re: dynamic breakpoints/watchpoints Message-ID: <20070314083409.GA21561@venus> References: <20070314002242.GB17710@venus> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-03/txt/msg00195.txt.bz2 On Wed, Mar 14, 2007 at 06:20:51AM +0200, Eli Zaretskii wrote: > > Date: Tue, 13 Mar 2007 17:22:42 -0700 > > From: "Ed S. Peschko" > > > > What I'm looking for is something akin to grep integrated with gdb. Commands > > like: > > > > bc /pattern_in_code/ > > > > would stop at the first place where 'pattern_in_code' was seen after continuing > > execution > > Is `rbreak' (q.v.) what you are looking for? Well, sort of, but I don't see why it has to be limited by subroutines. And I don't see why it has to be static. For example, int main() { ==> int stuff; aha(); aha2(); } int aha() { fprintf(stderr, "HERE1"); } int aha2() { fprintf(stderr, "HERE"); } Suppose that I'm at the '==>'. if I say bc /HERE/", I would break in the function 'aha', at the fprintf statement HERE1'. If I said bc /HERE/ at THAT point, then I'd break at 'HERE2'. The breakpoint changes as you go along. The main point of bc /HERE/ is that you forget the name of a variable, a function, or what-have-you but you know that a statement is going to contain that pattern at some point when you reach it in the future. Say for instance, a logging message. The way I use 'bc' (at least in perl) adds a simple method to get to ANY piece of code that I recognize. > > bv /pattern_in_variable/ > > > > would monitor the data that *any* variable is using, and stop as soon as an > > assignment of that pattern is made to that variable. > > I think this one would be impractical, at least on x86, where the > number of watchpoints is severely limited by the available number of > debug registers. Well, I guess I'm not talking about a hardware watchpoint but a software one. And yes, that would mean examining each chunk of memory before it gets written to a variable, which would probably require a gcc-hook for gdb to plug into. But this particular feature is WELL worth it - as I've used it in perl. Its a real GODSEND. Again, instead of needing to track down the program flow by several runs to get the point where you need to break, you simply look at the data coming into the program to see where to break, and THEN figure out the program flow by going backwards via trace. A good example - I was trying to track down how curl wrote data to a certain socket the other day. I knew that it consisted of writing a tag 'filename=' in a file somewhere, but for the life of me I couldn't figure out where that string was coming about in the curl source code. If I had 'bv' , I could have simply used 'bv /filename=/', ran the program, found out where the code picked up this tag, and used trace to figure out what made it get to that point. It would have taken a 4 hour excruciating hunt and peck operation, and turned it into a 5 minute task. Ed