Re: read watchpoints ignored?

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 13 Nov 2005 11:45:48 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> 
> I can reproduce this on Debian/unstable.

So can I, as I wrote in my reply.

> You included an example of setting the breakpoint by address, but not
> one of setting by "b main", so I can't guess from your transcript what
> happened.

You don't need to guess: since you reproduced the problem on your
machine (and I on mine), you could just look yourself.  I didn't show
such a transcript because it was identical to what Vladimir reported,
so instead I just said that I see the same on Debian.  I don't see why
I need to waste bandwidth by posting redundant information, given that
the OP's problem is easily reproducible on any similar platform.

> You also didn't show the disassembly of the function.

Again, there's no need to do that, as your own disassembly clearly
shows.  I don't understand why are you nitpicking at me.

> This is a relatively old GDB, and so probably a relatively old GCC.  On
> my installation it behaves as reported.

So it is on mine, thus the ``relatively old version'' is irrelevant.

> > So I'm guessing that the problem happens because GDB misses the data
> > write into a in line 7, and thus doesn't take notice that a was
> > assigned the value 10.  That's why it gets confused when "b = a;"
> > reads from a.
> 
> It misses it, but shouldn't.  When GDB single steps over the
> temporarily removed breakpoint at "main",
                      ^^^^^^^^^^
Did you mean ``watchpoint''?  If not, I'm afraid I don't follow.

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

> Presumably because trap_expected is set, infrun never calls
> bpstat_stop_status, so the watchpoint is never checked.  Maybe we
> should separate that code out into a separate function, or maybe we
> should call it more rigorously.

Sorry, I don't see how the suggestions in your second sentence would
solve the problem identified in the first.  Could you please explain?

> Eli, am I reading breakpoint.c right?

Right, and so am I.

> It looks like we _always_ ignore changed values for
> bp_read_watchpoint, which means that the core of GDB does not work
> on targets which support true read watchpoints.  Which IIRC includes
> S/390, which disabled them for this reason.

We've been through this: it's inaccurate to say that ``GDB does not
work on targets which support true read watchpoints.''  A more
accurate statement would be ``on targets which support true read
watchpoints, GDB does not announce read watchpoints when the watched
value changes,'' which is quite a different story, and a fairly rare
case.

If someone finds a way to announce a read watchpoint when the value
changed on a target that supports that, without losing support for
read watchpoints on x86 (which is by far the most popular platform
these days), I'll gladly agree to such a change.  IIRC, until now no
one did find how to do that.  I object to fixing read watchpoints in
such rare situations (i.e., when the data is only read, not written,
but the value still changes as a side effect) at a price of losing
read watchpoints on x86.  The solution proposed by Vladimir would do
precisely that, so I don't think we should accept it.

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