From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24904 invoked by alias); 18 Nov 2009 17:51:59 -0000 Received: (qmail 24894 invoked by uid 22791); 18 Nov 2009 17:51:59 -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 17:50:54 +0000 Received: (qmail 2383 invoked from network); 18 Nov 2009 17:50:51 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Nov 2009 17:50:51 -0000 From: Pedro Alves To: Jan Kratochvil Subject: Re: hardware watchpoints in non-stop - "moribund"/delayed watchpoint traps Date: Wed, 18 Nov 2009 17:51:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb-patches@sourceware.org References: <200911181445.38897.pedro@codesourcery.com> <20091118165952.GA23719@host0.dyn.jankratochvil.net> In-Reply-To: <20091118165952.GA23719@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911181750.50292.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/msg00408.txt.bz2 On Wednesday 18 November 2009 16:59:53, Jan Kratochvil wrote: > On Wed, 18 Nov 2009 15:45:38 +0100, Pedro Alves wrote: > > > 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. But is that a correctness problem? I guess I could put something like: if (debug_infrun && !bpstat_explains_signal (ecs->event_thread->stop_bpstat) && stopped_by_watchpoint) fprintf_unfiltered (gdb_stdlog, "infrun: no user watchpoint explains watchpoint event, ignoring"); so that we can tell from the logs if something is reporting bad watchpoint SIGTRAPs. > 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. At first I thought so, but, I then changed my mind into thinking the extra complexity isn't necessary. We needed the moribund breakpoint locations heuristic, to be able to distinguish random SIGTRAPs from delayed software breakpoint traps. We don't keep them indefinitly, so to reduce the chances of mistaking a real random SIGTRAP from a delayed software breakpoint SIGTRAP. We don't need the heuristic with hardware watchpoint traps --- we can always tell the difference. -- Pedro Alves