From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32329 invoked by alias); 9 Jul 2007 12:46:35 -0000 Received: (qmail 32321 invoked by uid 22791); 9 Jul 2007 12:46:34 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 09 Jul 2007 12:46:27 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1I7sdB-0002tR-Bb for gdb-patches@sources.redhat.com; Mon, 09 Jul 2007 14:46:21 +0200 Received: from 241-246.umostel.ru ([77.246.241.246]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Jul 2007 14:46:21 +0200 Received: from ghost by 241-246.umostel.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Jul 2007 14:46:21 +0200 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: [MI] lvalues and variable_editable Date: Mon, 09 Jul 2007 12:46:00 -0000 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.2 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/msg00146.txt.bz2 Daniel Jacobowitz wrote: > On Mon, Jul 09, 2007 at 05:51:42PM +1200, Nick Roberts wrote: >> (Me) >> >> > Anyway let me submit a more complete patch, in due course, for >> > consideration after the release. >> >> This is what I have in mind. There are no regressions, at least with MI >> (I >> can't test Insight). If there's still time, this could go in before the >> branch. I also have a (much smaller) change, that I've submitted >> earlier, for after the release which adds the editable field to the >> output of -var-create and -var-list-children, . > > Thanks for doing this. I have two questions for you. > > - 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. I would expect being able to create varobj for "a + b" and have it updated as I step, and being not editable. So variable_editable_p will be false, whereas varobj_value_is_changeable_p will be true. - Volodya