From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21273 invoked by alias); 25 Nov 2009 18:06:39 -0000 Received: (qmail 21207 invoked by uid 22791); 25 Nov 2009 18:06:38 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Nov 2009 18:06:31 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 4CE492BABEF; Wed, 25 Nov 2009 13:06:30 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BCowWfXBVurQ; Wed, 25 Nov 2009 13:06:30 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 105402BAB6B; Wed, 25 Nov 2009 13:06:30 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id A34B3F5905; Wed, 25 Nov 2009 13:06:25 -0500 (EST) Date: Wed, 25 Nov 2009 18:06:00 -0000 From: Joel Brobecker To: Paul Pluzhnikov Cc: gdb-patches@sourceware.org Subject: Re: [RFC] Interaction between HW watchpoints and 'set var'. Message-ID: <20091125180625.GG26004@adacore.com> References: <20091125175149.BB89D76D99@ppluzhnikov.mtv.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091125175149.BB89D76D99@ppluzhnikov.mtv.corp.google.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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/msg00553.txt.bz2 Interesting. One thing that you don't see is the behavior when using software watchpoints. My guess is that you'd see the debugger stop immediately at the first resume because the value looks new to GDB as well. > Now, I can fix that by installing deprecated_memory_changed_hook, > but the deprecated part gives me pause. > > Should I create a new memory_changed observer and remove > deprecated_memory_changed_hook instead? After reviewing the history of that hook, I think it would be a desired cleanup to have a memory_changed observer. Once you have the observer, you'll want to (possibly) re-evaluate the watchpoint value every time the memory changes. Not sure how to best implement that, but one issue you might face is when the user is updating the variable value while it being out of scope... If you manipulate memory blocks exclusively, then it shouldn't be a problem, but if you re-evaluate using the watchpoint expression, it might be. -- Joel