From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10886 invoked by alias); 21 Aug 2007 22:49:16 -0000 Received: (qmail 10644 invoked by uid 22791); 21 Aug 2007 22:49:14 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 21 Aug 2007 22:49:09 +0000 Received: (qmail 22536 invoked from network); 21 Aug 2007 22:49:07 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 21 Aug 2007 22:49:07 -0000 To: gdb-patches@sourceware.org Subject: Re: [rfc] Allow watchpoints on inaccessible memory References: <20070821142500.GA28295@caradoc.them.org> <20070821180630.GA8332@caradoc.them.org> From: Jim Blandy Date: Tue, 21 Aug 2007 22:49:00 -0000 In-Reply-To: <20070821180630.GA8332@caradoc.them.org> (Daniel Jacobowitz's message of "Tue, 21 Aug 2007 14:06:30 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2007-08/txt/msg00422.txt.bz2 Daniel Jacobowitz writes: > On Tue, Aug 21, 2007 at 09:33:28AM -0700, Jim Blandy wrote: >> One thing I don't understand: why are the "always watch the outermost >> value even if it is lazy" changes needed? The code that evaluates the >> watchpoint condition should always simply unlazy the expression's >> final value to begin with, so it'll never be lazy by the time the >> other code sees it. > > But that might fail. That's why I switched from value_fetch_lazy to > gdb_value_fetch_lazy, which catches exceptiosn. Consider "watch *0"; > evaluating the expression works fine, but fetching the result of > evaluate_expression will call memory_error. We still want to set > the watchpoint. Okay, I see. So there are actually two independent changes here: - Even when we can't unlazy the final value of an expression, we may be able to set a hardware watchpoint on it, because hardware watchpoints don't require the address being watched to actually be accessible. - When evaluating an expression to yield even a lazy a result fails, we can treat the fact of failure as a distinct value, and watch for that to change. This change could be generalized, although I'm not sure it's worth it. In evaluating an expression like p->q->r->s, if p->q is an invalid address, we could set a hardware watchpoint on p->q. In other words, watching the values produced by a failing expression up to the point of failure would allow us to use hardware watchpoints whenever possible. As it stands, your patch will record NULL as that watchpoint's value, and single-step to watch for changes. A lot of this rationale was not obvious to me by a long shot; I spent about an hour working it all out. I think the patch needs more comments. If you'd like me to write them, just say the word; I like writing docs.