Re: watchpoint troubles

[Paul Koning <pkoning@equallogic.com>]

>>>>> "Paul" == Paul Koning <pkoning@equallogic.com> writes:

>>>>> "Mark" == Mark Salter <msalter@redhat.com> writes:
>>>>> Paul Koning writes:
 >>> I'm having all sorts of watchpoint troubles with gdb 5.3 and a
 >>> remote target.  These are things I'm running into as I'm working
 >>> to improve the implementation of watchpoints in my remote stub.

 Mark> ...

 >>> Without that flag, the first thing that gdb does after the
 >>> watchpoint entry is to read the address being watched.  Needless
 >>> to say, that causes a watchpoint recursion within the target
 >>> stub.  In the case where HAVE_NONSTEPPABLE_WATCHPOINT is defined,
 >>> things work because the watchpoint is removed before the memory
 >>> read request is made.

 >>> Since gdb normally removes and reinserts watch/break points on
 >>> every entry, I figured it's gdb's job to do things in the right
 >>> order.  Bad assumption?  I can certainly hack up the stub to
 >>> remove the watchpoints before acting on any memory access
 >>> requests from gdb, but is that kind of hackery supposed to be
 >>> done?

 Mark> This has come up before:

 Mark> http://sources.redhat.com/ml/gdb-patches/2001-03/msg00506.html

 Mark> I think the answer is that the stub should disable watchpoints
 Mark> anytime the target stops and reenable them when stepping or
 Mark> continuing.

 Paul> Thanks.

 Paul> I just read that thread and the final message seems to say "gdb
 Paul> can be fixed to remove the watchpoints before doing the memory
 Paul> read in the case where HAVE_NONSTEPPABLE_WATCHPOINT is
 Paul> undefined.  Yes, I thought so.

 Paul> I may do that just to try it.  As I mentioned, what I *really*
 Paul> want is for the case where HAVE_NONSTEPPABLE_WATCHPOINT *is*
 Paul> defined to work correctly.  Right now it doesn't.

Ok, so I tried it.

The simple approach (call remove_breakpoints before the call to
bp_stop_status) doesn't work.  And that may be another reason why
things won't work even when I do have HAVE_NONSTEPPABLE_WATCHPOINT
defined.

The problem is that remove_breakpoints for some reason frees the
val_chain of the watchpoint.  So when bpstat_stop_status looks to see
whether the watched address (as reported by the target) matches what
we're watching, it says "no" because the watchpoint appears not to be
watching anything (because its val_chain is null).  So now my
watchpoint doesn't stop at all...

A similar problem applies in the HAVE_NONSTEPPABLE_WATCHPOINT case,
because that's done by calling remove_breakpoints followed by
single-stepping the target.  So quite apart from the fact that
remote.c believes that the last thing that happened was a single step
rather than a watchpoint, the val_chain is now gone so it isn't seen
in bpstat_stop_status.

   paul