Re: watchpoints

[Michael Elizabeth Chastain <mec at shout dot net>]

Hi David,

> Does this test pass for other people?

You can find this in my attention tables.  (It helps to have a monitor
the size of the main screen on the Starship Enterprise).  Go to the
gdb-testers mailing lists, look for my most recent report, go to the
attention tables, search for "annota2.exp".

My answer is: this test FAILed in 330 configurations out of 330 tested.

> So what's going on here?

It looks like an interaction between the way gdb manages breakpoints
and the way that hardware watchpoints work.

(Michael Snyder, among many other people, knows this much better than I do,
so if I mangle the explanation, please correct me).

When gdb sets a breakpoint, it writes a "breakpoint trap" instruction
into the code of the inferior process.  Eventually the inferior process
executes the breakpoint trap instruction and gdb gets control.

When gdb resumes execution of the inferior, it has to do this:

  write the original instruction back to the inferior
  single-step the inferior
  write the breakpoint back to the inferior
  continue the inferior

The source code here is:

  a.x = 0;
  a.x = 1; /* breakpoint here */
  a.y = 2;

These lines compile to single machine instructions.

So when gdb resumes execution after the breakpoint, it single-steps
on the "a.x = 1" instruction.  I bet that this gives rise to both a
single-step trap and a watchpoint trap.  To make matters even more
confusing, I think there is another breakpoint trap instruction on
the "a.y = 2" line, in order to implement "next".  So between the
these three things, the watchpoint trap seems to get delayed.

Try this: after the first "next", do another "next".  The watchpoint
fires, one instruction too late.  Similarly, do a "continue" instead
of "next", and the watchpoint fires, one instruction too late.

And try this code:

  a.x = 0;
  a.y = 0; /breakpoint here */
  a.x = 1;
  a.y = 2;

I ran this code on native i686-pc-linux-gnu, gdb 5.2.1-4-rh, gcc v3,
dwarf-2, put a watchpoint on a.x, and the watchpoint fired in the
right place.

It looks like a bug to me, too.  I have no clue how to fix this.

Michael C