Re: dynamic breakpoints/watchpoints

["Ed S. Peschko" <esp5@pge.com>]

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" <esp5@pge.com>
> > 
> > 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