This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: hardware watchpoints in non-stop - "moribund"/delayed watchpoint traps
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Pedro Alves <pedro at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 18 Nov 2009 17:59:53 +0100
- Subject: Re: hardware watchpoints in non-stop - "moribund"/delayed watchpoint traps
- References: <200911181445.38897.pedro@codesourcery.com>
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 .*" \