Re: read watchpoints ignored?

[Eli Zaretskii <eliz at gnu dot org>]

> Date: Sun, 13 Nov 2005 21:43:45 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb@sources.redhat.com, Vladimir Prus <ghost@cs.msu.su>
> 
> > >                                           it is not updating the values
> > > of watchpoints before resuming the instruction.  That instruction
> > > happened to modify the value behind a read watchpoint.
> > 
> > Then that's the bug, I'd say.  Do you agree that this is what we
> > should fix to solve this bug?  Because the following discussion of
> > problems with read watchpoints is only remotely related to the bug
> > reported by Vladimir.
> 
> Yes, certainly this is the bug, I just don't know which way to fix it.

We need to find a way to get GDB to check whether the watchpoint fired
during such stepping.

> I'm talking about watchpoint_check.  If that had been called, we would
> have updated the value stored in the watchpoint for "a", and at the
> next read watchpoint, it would not appear to have changed.

I think we need call watchpoint_check only if
target_stopped_data_address says the watchpoint fired.

> Fortunately any platform with read watchpoints probably also has access
> watchpoints, so we can get by with using those instead.

Exactly.

> But the first read after the value changes has a high chance of
> being the important one while debugging.

I think the current code should handle this well.  But perhaps you are
thinking about some particular situation where it won't, so please
show the code you had in mind.

> Certainly there's no reason to disable rwatch.  Conditionalize "skip
> this watchpoint if the value has changed" on "this is really an access
> watchpoint because the target does not support read watchpoints".

That's fine with me.