hardware watchpoints in non-stop - "moribund"/delayed watchpoint traps

[Pedro Alves <pedro at codesourcery dot com>]

Hi,

I'm working on making watchpoints actually work in non-stop
mode (against a private stub).

One thing that was never handled is "moribund" / delayed
watchpoint traps.  Cases like these:


| Time/ | GDB                               | Target                         |
|  Step |                                   |                                |
|-------+-----------------------------------+--------------------------------|
|     1 | user sets watchpoint, gdb tells   |                                |
|       | target to insert watchpoint       |                                |
|-------+-----------------------------------+--------------------------------|
|     2 |                                   | inserts watchpoint (sets debug |
|       |                                   | registers)                     |
|-------+-----------------------------------+--------------------------------|
|       |                                   | hits watchpoint (puts event    |
|     3 |                                   | in queue/sends to gdb)         |
|-------+-----------------------------------+--------------------------------|
|     4 | user deletes watchpoint, gdb      |                                |
|       | tells target to delete watchpoint |                                |
|-------+-----------------------------------+--------------------------------|
|     5 |                                   | receives watchpoint            |
|       |                                   | delete request                 |
|-------+-----------------------------------+--------------------------------|
|     6 | receives watchpoint hit event     |                                |


Say the target is able to report stopped data addresses on watchpoint
hits (some can't).  When you reach step 6, bpstat_stop_status doesn't
find any watchpoint in the breakpoint list for the reported stopped
data address, and hence doesn't put any watchpoint related bpstat in
the list --- step 4 had deleted the corresponding watchpoint from
gdb's breakpoint lists.

The end result is that GDB simply reports the trap a random SIGTRAP,
which is far from user friendly (Program received signal SIGTRAP,
Trace/breakpoint trap).


This actually triggers very often with current GDB, because
watchpoints have never been adjusted to work in always-inserted mode
--- GDB always removes/inserts watchpoints on every reported event.
I'll post patches to fix that later.


This shouldn't be limited to non-stop mode.  I'm thinking (but haven't
tried to reproduce it), that something like this will happen in
linux/all-stop mode when Jan's reordered-watchpoints patch goes in:


| Time/ | GDB                               | Target                         |
|  Step |                                   |                                |
|-------+-----------------------------------+--------------------------------|
|     1 | sets watchpoint                   |                                |
|-------+-----------------------------------+--------------------------------|
|       |                                   | two threads hit watchpoint.    |
|     2 |                                   | One event is reported, the     |
|       |                                   | other left pending.            |
|-------+-----------------------------------+--------------------------------|
|     3 | user deletes watchpoint,          |                                |
|       | continues                         |                                |
|-------+-----------------------------------+--------------------------------|
|     4 |                                   | skips resuming --- has pending |
|       |                                   | status to report, and reports  |
|       |                                   | that now                       |
|-------+-----------------------------------+--------------------------------|
|     5 | receives watchpoint hit           |                                |
|       | event, but there's no             |                                |
|       | watchpoint listed for this        |                                |
|       | stopped data address              |                                |
|-------+-----------------------------------+--------------------------------|
|     6 | report random SIGTRAP to the user |                                |


We could probably tweak Jan' new test at
<http://sourceware.org/ml/gdb-patches/2009-11/msg00400.html> to trigger this.


So, here's the simple patch to handle this.  Any comments/concerns?

2009-11-18  Pedro Alves  <pedro@codesourcery.com>

	* infrun.c (handle_inferior_event): Hardware watchpoint traps are
	never random signals.

-- 
Pedro Alves


---
 gdb/gdbserver/i386-low.c |    1 +
 gdb/infrun.c             |    9 +++++++++
 2 files changed, 10 insertions(+)

Index: src/gdb/infrun.c
===================================================================
--- src.orig/gdb/infrun.c	2009-11-18 12:09:05.000000000 +0000
+++ src/gdb/infrun.c	2009-11-18 14:06:34.000000000 +0000
@@ -3613,9 +3613,18 @@ targets should add new threads to the th
          be necessary for call dummies on a non-executable stack on
          SPARC.  */
 
+      /* This is where we handle "moribund" watchpoints.  Unlike
+	 software breakpoints traps, hardware watchpoint traps are
+	 always distinguishable from random traps.  If no high-level
+	 watchpoint is associated with the reported stop data address
+	 anymore, then the bpstat does not explain the signal ---
+	 simply make sure to ignore it if `stopped_by_watchpoint' is
+	 set.  */
+
       if (ecs->event_thread->stop_signal == TARGET_SIGNAL_TRAP)
 	ecs->random_signal
 	  = !(bpstat_explains_signal (ecs->event_thread->stop_bpstat)
+	      || stopped_by_watchpoint
 	      || ecs->event_thread->trap_expected
 	      || (ecs->event_thread->step_range_end
 		  && ecs->event_thread->step_resume_breakpoint == NULL));