Re: [ppc-linux-nat]: set access flag for h/w watchpoint even if it is only read or write

[Wu Zhou <woodzltc at cn dot ibm dot com>]

Eli,

Just as Daniel said, my problem is not the same as yours. given the
following code:

  int var1 = 0, var2;
  var1 = 10;
  var2 = var1;

if we set read watchpoint on var1, it should stop at "var2 = var1", but
gdb are using "watchpoint_check" to see if the watched variable are
changed or not, if it is changed, then it assumes the watched variable is
writed; if not, it assumes the watched variable is read.

Because when execution get to "var1=10", it won't trigger a watchpoint,
the old value stored in var1 is still 0, so watchpoint_check will get a
wrong conclusion that var1 is changed to 10 by this instruction.  So it
won't treat it as a read watchpoint hit.

My solution is to let gdb update the value stored in the watched variable,
so that it always get the fresh value for comparison.

Another solution might be to change the verify logic of read watchpoint
hit in watchpoint_check.  Maybe we can just trust the underlying os will
only trigger in read hit?

Still another is like what Daniel and you said, we can let the target to
tell what kind of hit it is on the watched variable.  As for this, I can
figure out two methods at this time: the kernel should transfer the
watchpoint type information to user space (maybe through siginfo), or
gdb iterate through all the watched variable to determine what kind of
watchpoint this is.  Both of these changes also involve the change in
watchpoint_check routine.

Comparing all these solution, my solution is the most simple one.  I mean,
it makes little change to the current code.  To address the slowdown, we
can still use the original flags for write hit.

What is your idea on this?

On Thu, 6 Jul 2006, Daniel Jacobowitz wrote:

> On Thu, Jul 06, 2006 at 11:58:58PM +0300, Eli Zaretskii wrote:
> > Yes, this problem is known on x86 and elsewhere.  The problem is
> > extremely rare, as reading and writing to the same address in the same
> > instruction is a hard-to-accomplish treat.  Wu, could you show a
> > real-life example of where this matters?
>
> I thought, though I may be misremembering, that it was actually a
> different problem.  Something like this:
>
> - We set a read watchpoint.  It does not trigger on writes.
>
> - An instruction writes to the location.
>
> - GDB stops, sees that it stopped at a watchpoint at the given address,
>   tries to determine what sort of watchpoint it was, determines that
>   the value had changed, and ignores the read watchpoint - the value
>   has changed since we last checked so this "must" have been a write
>   watchpoint.
>
> Is that plausible or nonsensical?
>
> --
> Daniel Jacobowitz
> CodeSourcery

Regards
- Wu Zhou