This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: watchpoints inside 'commands'
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