Re: read watchpoints ignored?

[Vladimir Prus <ghost at cs dot msu dot 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.

Well, there are two distinct bugs there. First is that "breakpoint on store 
instruction", where watched value should be re-read by gdb, but is not. 
Second is that for targets with real read watchpoints, the problem is present 
anyway. When I do "target remote :1234" the current PC is before assignment,
since watchpoint is read-only, gdb does not stop on write, and ignores first 
read of variable.

I can't fix the first problem yet, because I'm not familiar with the code.
About the second...

> > > This should be controlled by an architecture method indicating that
> > > there are only access watchpoints.
> >
> > And then what? disable `rwatch'?  I object to such ``solution'', since
> > the emulated read watchpoints proved to be most useful to me since the
> > code we discuss was introduced.
>
> I thought this was fairly straightforward, so I didn't go into detail.
> 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".
>
> It should be trivial to fix if you had a platform with read watchpoints
> handy.  Which I don't easily.

.. I can try adding extra method to target ops, and for remote target, 
implement it by returning the value of 
 
   remote_protocol_Z[Z_PACKET_READ_WP].support

Should I do this?

- Volodya