From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13385 invoked by alias); 11 Jul 2007 13:09:12 -0000 Received: (qmail 13373 invoked by uid 22791); 11 Jul 2007 13:09:11 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 11 Jul 2007 13:09:07 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1I8bwE-0004Yp-AV for gdb-patches@sources.redhat.com; Wed, 11 Jul 2007 17:09:03 +0400 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1I8bw7-0004YA-5z; Wed, 11 Jul 2007 17:08:55 +0400 From: Vladimir Prus To: Nick Roberts Subject: Re: [MI] lvalues and variable_editable Date: Wed, 11 Jul 2007 13:09:00 -0000 User-Agent: KMail/1.9.5 Cc: gdb-patches@sources.redhat.com References: <18048.64048.398970.186217@kahikatea.snap.net.nz> <200707111045.47111.ghost@cs.msu.su> <18068.50600.964338.269608@kahikatea.snap.net.nz> In-Reply-To: <18068.50600.964338.269608@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707111708.52171.ghost@cs.msu.su> 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/msg00173.txt.bz2 On Wednesday 11 July 2007 15:57, Nick Roberts wrote: > > I think you misunderstand the meaning of varobj_value_is_changeable_p. It > > does not indicate if the object itself may be changed, by the programming > > language or by gdb user. It indicates if the value of varobj, as printed by > > -var-evaluate-expression, may change. As shown above, in current gdb, the > > value of varobj having type 'function' can change just fine, in a meaningful > > way. > > It shows I misunderstood the concept of the value of a function. I'll > change that also, which means varobj_editable_p can't be easily derived > from varobj_changeable_p. Well, current varobj_changeable_p answers the question "do we need to store a non-lazy value inside varobj, so that after -var-update we can detect that the value has changed". It follows that -var-evaluate-expression should print some static string for such varobjs. As for editability, two approaches are possible: 1. If static string is printed as value, it makes no sense to assign anything. In that case, using varobj_changeable_p by varobj_editable_p is reasonable. 2. Why not allow assigning "{1,2}" to a varobj of expression type? That might be good feature to user, but I'm not sure how hard it will be to implement. So for now I think we can take (1), and then use varobj_changeable_p from varobj_editable_p. Should that become problematic, we can always make the functions completely independent. - Volodya