[RFC] Interaction between HW watchpoints and 'set var'.

[RFC] Interaction between HW watchpoints and 'set var'.

[Paul Pluzhnikov]

Greetings,

Consider the following test case:

--- cut ---
int x;
int main()
{
  int i, j;

  for (i = 0; i < 500; ++i) {
    j = 0;  // break here
    x = 42;
    j = i;  // expect HW watchpoint stop
  }
  return 0;
}
--- cut ---

gdb64-cvs -q ./a.out

  Reading symbols from /tmp/a.out...done.
  (gdb) b 7
  Breakpoint 1 at 0x400455: file foo.c, line 7.
  (gdb) r

  Breakpoint 1, main () at foo.c:7
  7           j = 0;  // break here
  (gdb) watch x
  Hardware watchpoint 2: x
  (gdb) c
  Hardware watchpoint 2: x

  Old value = 0
  New value = 42
  main () at foo.c:9
  9           j = i;  // expect HW watchpoint stop
  (gdb) c

  Breakpoint 1, main () at foo.c:7
  7           j = 0;  // break here

So far, everything is working just as one would expect.

  (gdb) p x
  $1 = 42
  (gdb) set var x = 1
  (gdb) print x
  $2 = 1
  (gdb) c

  Breakpoint 1, main () at foo.c:7
  7           j = 0;  // break here
  (gdb) print x
  $3 = 42

Why didn't HW watchpoint fire? Clearly 'x' changed from 1 to 42.

Setting 'debug infrun' shows that the watchpoint does indeed fire,
but is ignored by watchpoint_check() because GDB thinks the old
value was 42 as well.  And GDB believes that because value_assign()
does not update breakpoints.

Now, I can fix that by installing deprecated_memory_changed_hook,
but the deprecated part gives me pause.

Should I create a new memory_changed observer and remove
deprecated_memory_changed_hook instead?

Thanks,
--
Paul Pluzhnikov

Re: [RFC] Interaction between HW watchpoints and 'set var'.

[Joel Brobecker]

Interesting.  One thing that you don't see is the behavior when using
software watchpoints.  My guess is that you'd see the debugger stop
immediately at the first resume because the value looks new to GDB
as well.

> Now, I can fix that by installing deprecated_memory_changed_hook,
> but the deprecated part gives me pause.
> 
> Should I create a new memory_changed observer and remove
> deprecated_memory_changed_hook instead?

After reviewing the history of that hook, I think it would be a desired
cleanup to have a memory_changed observer. Once you have the observer,
you'll want to (possibly) re-evaluate the watchpoint value every time
the memory changes. Not sure how to best implement that, but one issue
you might face is when the user is updating the variable value while
it being out of scope...  If you manipulate memory blocks exclusively,
then it shouldn't be a problem, but if you re-evaluate using the
watchpoint expression, it might be.

-- 
Joel