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

[Jan Kratochvil]

On Wed, 18 Nov 2009 15:45:38 +0100, Pedro Alves wrote:
> 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.

I agree, nice catch.

Such patch to test it is at the bottom.


>        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));

This means forgotten triggers (as currently without the hw-watchpoints
patch 1/4) would be hidden.

As the is already the infrastructure for moribund locations isn't it better to
enable them even for all-stop mode and check the address explicitly against
them?  Sorry for no such patch in this mail.


Regards,
Jan


--- a/gdb/testsuite/gdb.threads/watchthreads-reorder.exp
+++ b/gdb/testsuite/gdb.threads/watchthreads-reorder.exp
@@ -88,6 +88,8 @@ foreach reorder {0 1} {
 	gdb_test "rwatch unused1_rwatch" "Hardware read watchpoint \[0-9\]+: unused1_rwatch"
 	gdb_test "rwatch unused2_rwatch" "Hardware read watchpoint \[0-9\]+: unused2_rwatch"
     }
+    gdb_test "delete 2"
+    gdb_test "delete 3"
 
     gdb_test "continue" \
 	     "Hardware read watchpoint \[0-9\]+: thread\[12\]_rwatch\r\n\r\nValue = 0\r\n0x\[0-9a-f\]+ in thread\[12\]_func .*" \