From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18944 invoked by alias); 18 Nov 2009 19:46:57 -0000 Received: (qmail 18919 invoked by uid 22791); 18 Nov 2009 19:46:56 -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 19:45:53 +0000 Received: (qmail 6835 invoked from network); 18 Nov 2009 19:45:51 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Nov 2009 19:45:51 -0000 From: Pedro Alves To: Jan Kratochvil Subject: Re: hardware watchpoints in non-stop - "moribund"/delayed watchpoint traps Date: Wed, 18 Nov 2009 19:46:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb-patches@sourceware.org References: <200911181445.38897.pedro@codesourcery.com> <200911181750.50292.pedro@codesourcery.com> <20091118183917.GA30279@host0.dyn.jankratochvil.net> In-Reply-To: <20091118183917.GA30279@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911181945.50684.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/msg00410.txt.bz2 On Wednesday 18 November 2009 18:39:17, Jan Kratochvil wrote: > The problem is it is not clear from this message there is a GDB bug and the > testsuite already contains too many racy failures to be catching more of them. I'd bet a couple of those are actually exactly as the all-stop case I described and actually fixed by this change. > > 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. > > The heuristic can be disabled in the all-stop mode remembering all watchpoint > locations indefinitely exactly until count_events_callback() reports zero. "indefinitely exactly until" is contradictory. :-) Think about it. The fact that we count a certain made-up number of events _is_ part of the heuristic. I've seen the moribund events count reaching zero sooner than it should have, and GDB reporting a random SIGTRAP by mistake. > But sure your patch is better than the current state and I can post what > I find more strict later. If we have moribund watchpoint locations, then most of the races you're talking about would still be hidden, exactly by the moribund locations. I don't think we'd be stricter. It seems the only case that wouldn't happen is the case of the target keeping reporting bad SIGTRAPs repeatedly, but I'm sure those are noticeable by other symptoms, like, e.g., target slowness. Keep in mind that on targets that can't report a stopped data address, gdb already necessarily ignores bad watchpoint traps. -- Pedro Alves