Re: watchpoints

[David Carlton <carlton at math dot stanford dot edu>]

On Wed, 18 Dec 2002 18:15:53 -0600, Michael Elizabeth Chastain <mec@shout.net> said:

>> Does this test pass for other people?

> You can find this in my attention tables.

Yeah, thanks, I did check that, at least for some configurations.
I should have made that more clear.

> (It helps to have a monitor
> the size of the main screen on the Starship Enterprise).

:-)

>> So what's going on here?

> 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.

Sounds plausible.

> Try this: after the first "next", do another "next".  The watchpoint
> fires, one instruction too late.

Right, I noticed that, too.  Also, if I move the breakpoint up one
line, then it still takes two nexts for the watchpoint to fire, and in
that case the watchpoint has a.x jumping from an unitialized value to
1, with the change to 0 not being seen.

> 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.

Interesting.

> It looks like a bug to me, too.

Thanks for the analysis.  It looks like I should file a PR and come up
with a test case for gdb.base/watchpoint.exp.

David Carlton
carlton@math.stanford.edu