Re: watchpoints inside 'commands'

[Edward Peschko <edwardp@excitehome.net>]

On Fri, Apr 06, 2001 at 05:09:18AM -0400, Eli Zaretskii wrote:
> > Date: Thu, 5 Apr 2001 20:05:25 -0700
> > From: Edward Peschko <edwardp@excitehome.net>
> > 
> > Key *Object::getItem(Key key)
> > {
> >	return (Object::getItem(&key));  bug here.
> > }
> > 
> > So. I tried the following:
> > 
> > b Object.cpp:12
> > commands 1
> > > silent
> > > watch key._data[0]
> > > continue
> > 
> > Unfortunately, this doesn't seem to work because, when the watchpoint is 
> > eliminated, the program auto halts. Why?
> 
> What exactly do you mean by ``when the watchpoint is eliminated, the
> program auto halts''?  Can you tell what commands do you type and what
> does GDB print in response?

Basically, the program halts (stops) after the watchpoint is hit.

> > And can you set an 'intelligent' watchpoint, one that watches the value of a 
> > variable *name* (not a variable instance) between point 'a' and point 'b' in 
> > your code? This would be far more useful than the current behaviour - 
> > currently, tracing one instance of a variable is useless if you've got a 
> > function which creates and destroys tons of them...
> 
> I'm not sure I understand what you want, but it sounds like watching
> the variable by its address instead of by its name should do the
> trick.

No, it won't - the point is, when you have code that looks like 

int function(char *string)
{
	# begin (line 15)
	... (string shouldn't change but it does)
	...
	# end (line 40)
}
	
then 'string' will have a different address every single time function is 
called. I'd like the ability to track 'string' from line 15 to line 40, put 
a hardware assisted watchpoint on it when line 15 is being reached, and letting
go the watchpoint when line 40 is being reached.


As it stands, if I say:

b 15
commands
> silent
> watch string
> continue


as soon as the scope changes inside of 'function', the program breaks... It says
'watchpoint being deleted as the variable goes out of scope'.


> > (ps -- this brings up another thing.. if you've got a heisenbug, how
> > do you go about tracking it down? Say that another piece of your
> > code (in another thread) is trashing your thread via an array bounds
> > write (or some such thing) How can you track this down as being the
> > cause?
> 
> I usually do that with hardware-assisted watchpoints on the memory
> region that is being trashed.

but the memory region that is being trashed varies from time to time...

Ed