This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: watchpoints inside 'commands'
- To: edwardp at excitehome dot net
- Subject: Re: watchpoints inside 'commands'
- From: Eli Zaretskii <eliz at delorie dot com>
- Date: Fri, 6 Apr 2001 05:09:18 -0400 (EDT)
- CC: gdb at sources dot redhat dot com
- References: <20010405200028.A18474@excitehome.net> <20010405200525.A18623@excitehome.net>
- Reply-to: Eli Zaretskii <eliz at is dot elta dot co dot il>
> 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?
> 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.
> (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.