This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
hardware watchpoints in non-stop - "moribund"/delayed watchpoint traps
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Date: Wed, 18 Nov 2009 14:45:38 +0000
- Subject: hardware watchpoints in non-stop - "moribund"/delayed watchpoint traps
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));