Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT

[Paul Koning <pkoning@equallogic.com>]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

 >> The trouble I ran into is that this doesn't work because (on
 >> remote target support for MIPS anyway) the watchpoint handling
 >> does an effective "stepi" after the watchpoint stop.  After that
 >> stepi, stopped_by_watchpoint() would return false because the most
 >> recent stop was due to a break (the stepi).

 Eli> But that is something the target-side code could handle, right?
 Eli> I mean, stopped_by_watchpoint has intimate knowledge about the
 Eli> target's particulars, so it could fiddle the stop reason if it
 Eli> saw the indication that a watchpoint fired _and_ that the most
 Eli> recent stop was due to a single-step, right?

 Eli> Failing that, we could have something like
 Eli> AUTO_STEPI_AFTER_WATCHPOINT in higher-level code in GDB
 Eli> (infrun.c or breakpoint.c) to handle such targets, but I
 Eli> generally think that the GDB application-level code should not
 Eli> bother itself with target-specific peculiarities if we can avoid
 Eli> that.

I'd have to do a bunch of memory refreshing to remind myself of the
various possibilities you're talking about...

History: I started from a remote stub that was very poorly
implemented, and handled things by faking a single-step locally.  This
was extremely ugly.

I observed that gdb had machinery to handle all this cleanly from the
gdb end, so I turned it on.  And sure enough, it worked for some
cases.  But not for all, for the reasons I mentioned.  I then looked
for a way to fix that with minimal perturbation to the existing
machinery.  

My conclusion was: the bug is that the internally generated stepi
causese the "stopped by watchpoint" status and associated address to
be forgotten, so the best fix is not to forget them.  That's what I
did.  The other bug was that the break/watch point list traversal
routine would mishandle some cases where no match was found, which is
why I changed that area, again trying to do minimal change to the
logic and fixing only the place where the code didn't do what the
apparent intent was.

As for gdb not doing target-specific peculiarities -- I'd say that
HAVE_NONSTEPPABLE_WATCHPOINTS is the way to pass that knowledge
around.  Having it where it lives today is clean because (as far as I
can tell) it puts the necessary special handling near where
break/watch/step live.  Trying to do it further down means you end up
replicating a lot more of the magic involved in stepping.  The mess I
started out with (stepi "implemented" at the remote stub, transparent
to gdb) convinced me of this.

	 paul