From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29926 invoked by alias); 16 May 2006 23:53:09 -0000 Received: (qmail 29916 invoked by uid 22791); 16 May 2006 23:53:09 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 16 May 2006 23:53:05 +0000 Received: from farnswood.snap.net.nz (p262-tnt1.snap.net.nz [202.124.111.8]) by viper.snap.net.nz (Postfix) with ESMTP id 04916756FE2; Wed, 17 May 2006 11:53:04 +1200 (NZST) Received: by farnswood.snap.net.nz (Postfix, from userid 500) id BE589627ED; Wed, 17 May 2006 00:52:32 +0100 (BST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17514.26047.918241.942848@farnswood.snap.net.nz> Date: Wed, 17 May 2006 00:45:00 -0000 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com, Vladimir Prus Subject: Re: [PATCH] -var-update [was Re: Variable objects: references formatting] In-Reply-To: <20060515164605.GF28924@nevyn.them.org> References: <17497.14121.225320.477428@farnswood.snap.net.nz> <200605041100.09748.ghost@cs.msu.su> <17497.43822.261192.673547@farnswood.snap.net.nz> <200605041610.16153.ghost@cs.msu.su> <17503.15435.371371.707494@farnswood.snap.net.nz> <20060515164605.GF28924@nevyn.them.org> X-Mailer: VM 6.97 under Emacs 21.2.1 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00370.txt.bz2 > > I think this patch works. My reasoning is one of symmetry: whatever is > > done to val2 should also be done to val1, and that you probably don't want > > to change the contents of val1 (hence val3). I don't know exactly what > > coerce_array does, apart from convert the type from TYPE_CODE_REF to > > TYPE_CODE_INT or TYPE_CODE_FLOAT or whatever, so the comment might not be > > quite right. > > I don't think this is in the right place: you're using an argument of > symmetry, but in fact, the comments in my_value_equal suggest that > symmetry is inappropriate. Also because, its a safe one, particularly if a dummy value variable is used, because nothing gets changed outhside my_value_equal. Anyway I now see its the wrong change, it just detects when the reference is assigned an address, not when the value at that address changes. > For instance: > > /* The contents of VAL1 are supposed to be known. */ > gdb_assert (!value_lazy (val1)); > > If val1 is the reference at this point, then we haven't checked what we > think we have. Trying to interpret the code, given that val1 doesn't hold the value I wonder why this assertion is true i.e why is value->lazy=0 even though the value isn't in the contents field. > Every time my_value_equal is called its first argument comes from a > varobj's ->value. It seems to me that if we want to properly know > whether the varobj has changed, we'd better have read its value into > GDB. Could it not doing that because GDB's value mechanism isn't working properly for references? -- Nick http://www.inet.net.nz/~nickrob