From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26554 invoked by alias); 9 Jul 2007 12:38:10 -0000 Received: (qmail 26545 invoked by uid 22791); 9 Jul 2007 12:38: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; Mon, 09 Jul 2007 12:38:07 +0000 Received: from kahikatea.snap.net.nz (99.63.255.123.dynamic.snap.net.nz [123.255.63.99]) by viper.snap.net.nz (Postfix) with ESMTP id 19B9F3D9392; Tue, 10 Jul 2007 00:38:04 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 8C63A8FBF6; Tue, 10 Jul 2007 00:37:57 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18066.11299.571385.305234@kahikatea.snap.net.nz> Date: Mon, 09 Jul 2007 12:38:00 -0000 To: Daniel Jacobowitz Cc: gdb-patches@sourceware.org Subject: Re: [MI] lvalues and variable_editable In-Reply-To: <20070709120452.GA4011@caradoc.them.org> References: <18048.64048.398970.186217@kahikatea.snap.net.nz> <20070703161533.GF2868@caradoc.them.org> <18059.3627.269075.427280@kahikatea.snap.net.nz> <18059.4081.679819.107248@kahikatea.snap.net.nz> <20070704031408.GA25672@caradoc.them.org> <18059.5491.279643.514165@kahikatea.snap.net.nz> <18065.52462.459675.416595@kahikatea.snap.net.nz> <20070709120452.GA4011@caradoc.them.org> X-Mailer: VM 7.19 under Emacs 22.1.50.12 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-07/txt/msg00145.txt.bz2 > - Why do variable_editable_p and varobj_value_is_changeable_p have to > be different? That is, do we need varobj_value_is_changeable_p to be > true for any non-lvals. If not, we can eliminate one of them. Taking my earlier example: -var-create - * "i1 + i2" As it's not an lvalue it's not editable (variable_editable_p returns 0) but it's value can surely change (variable_changeable_p returns 1). So GDB has to check for this and report any change when -var-update is issued. While int m[10] -var-create - * m is not editable and not changeable. Does this show that variable_editable_p and varobj_value_is_changeable_p are necessarily different? (One is used to tell the user he can't edit the value, the other to tell GDB not to bother check for a change in value.) > - Why do you need to re-evaluate the expression? I think we can use > var->value, and report anything with a NULL value as non-editable. > No point editing it if we can't save it somewhere. Perhaps you don't. Currently you can do things like: (gdb) -var-create - * 1/0 ^done,name="var1",numchild="0",value="",type="int" (gdb) -var-create - * 0/0 ^done,name="var2",numchild="0",value="",type="int" I was just being cautious, and cut and pasting. > Also, I think varobj_value_is_changeable_p was missing from your > changelog (if I've correctly understood where one hunk of that patch > goes), OK. > and the patch had "variable_editable_pv" in it. Sticky fingers, sorry about that. My version of varobj.c compiles and doesn't have this, of course. -- Nick http://www.inet.net.nz/~nickrob