This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

watchpoint troubles


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.

In these tests I was using "awatch", i.e., watching both loads and
stores. 

First...  I had defined HAVE_NONSTEPPABLE_WATCHPOINT to force gdb to
step over the instruction where the watchpoint occurs.  That seems to
work, but it has a bizarre side effect:

Once the watchpoint is defined, every entry to gdb (whether from that
watchpoint or from single stepping) prints out a mention of that
watchpoint.  I tracked it down to bpstat_stop_status, which looks up
the watch address.  If that comes back from the target code as zero,
it continues the breakpoint scan loop ("continue" around line 2637 in
breakpoint.c).  Since the default settings for a bpstat entry is stop
and print, two evil things happen: (a) the watchpoint info is printed
(minor), (b) the single-stepping stops immediately, i.e., an "n"
command is turned into a "stepi" command! (major).

I figured I could fix this by setting stop and print to zero before
that continue, but if I do that then gdb doesn't stop at all anymore
as soon as I continue from a watchpoint.

So, just to try something, I removed the definition of
HAVE_NONSTEPPABLE_WATCHPOINT, because it looked like part of the
problem is that the "stopped due to a watchpoint" flag is no longer
set after the single-step after the watchpoint hits.

That exposed a different bug, which is very clear in the remote
protocol debug printout.

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?

Thanks,
	paul


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]