From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31638 invoked by alias); 11 Jul 2007 11:57:44 -0000 Received: (qmail 31629 invoked by uid 22791); 11 Jul 2007 11:57:43 -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; Wed, 11 Jul 2007 11:57:37 +0000 Received: from kahikatea.snap.net.nz (198.62.255.123.dynamic.snap.net.nz [123.255.62.198]) by viper.snap.net.nz (Postfix) with ESMTP id D49993DA1C1; Wed, 11 Jul 2007 23:57:32 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id D49518FBF6; Wed, 11 Jul 2007 23:57:29 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18068.50600.964338.269608@kahikatea.snap.net.nz> Date: Wed, 11 Jul 2007 11:57:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: [MI] lvalues and variable_editable In-Reply-To: <200707111045.47111.ghost@cs.msu.su> References: <18048.64048.398970.186217@kahikatea.snap.net.nz> <200707102114.31334.ghost@cs.msu.su> <18068.12759.961280.457617@kahikatea.snap.net.nz> <200707111045.47111.ghost@cs.msu.su> X-Mailer: VM 7.19 under Emacs 22.1.50.13 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/msg00172.txt.bz2 > (gdb) > -var-assign F.public.i 10 > &"mi_cmd_var_assign: Could not assign expression to varible object\n" > ^error,msg="mi_cmd_var_assign: Could not assign expression to varible object" > (gdb) > > Clearly, gdb does not like assigning to F.public.i, and I'm pretty sure it's > because VALUE_LVAL for that varobj returns false. Naturally, it's reasonable > to expect to have F.public.i marked as non-editable, so that frontend won't > even let the user to assign a value. I don't think your patch will do that. OK. It would be strange to try to edit such variable objects, but I take your point and will change it (back to it's original set of conditions). > -var-update F > ^done,changelist=[{name="F",in_scope="true",type_changed="false"}] > (gdb) > -var-evaluate-expression F > ^done,value="{void (void)} 0x80483ca " > (gdb) > > Note that the current gdb has no problem whatsoever with printing the value > of function, and it also notices when a value changes. If you change c_value_of_variable > as outlined above, you'll only see "" as output. > > > Functions and methods are surely not changeable. > > 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. -- Nick http://www.inet.net.nz/~nickrob