From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18075 invoked by alias); 18 Nov 2009 14:46:44 -0000 Received: (qmail 18067 invoked by uid 22791); 18 Nov 2009 14:46:43 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 18 Nov 2009 14:45:42 +0000 Received: (qmail 9227 invoked from network); 18 Nov 2009 14:45:40 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Nov 2009 14:45:40 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: hardware watchpoints in non-stop - "moribund"/delayed watchpoint traps Date: Wed, 18 Nov 2009 14:46:00 -0000 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911181445.38897.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-11/txt/msg00404.txt.bz2 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 to trigger this. So, here's the simple patch to handle this. Any comments/concerns? 2009-11-18 Pedro Alves * 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));