From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 808 invoked by alias); 30 Oct 2007 11:05:13 -0000 Received: (qmail 796 invoked by uid 22791); 30 Oct 2007 11:05:13 -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, 30 Oct 2007 11:05:06 +0000 Received: from kahikatea.snap.net.nz (240.63.255.123.dynamic.snap.net.nz [123.255.63.240]) by viper.snap.net.nz (Postfix) with ESMTP id 0F11F3D9CEC; Wed, 31 Oct 2007 00:04:58 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 39CB58FC6D; Wed, 31 Oct 2007 00:04:54 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18215.4053.151140.671560@kahikatea.snap.net.nz> Date: Tue, 30 Oct 2007 11:15:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] MI: lvalues and variable_editable In-Reply-To: <200710301222.03459.ghost@cs.msu.su> References: <18210.27153.559569.601092@kahikatea.snap.net.nz> <200710271615.23579.ghost@cs.msu.su> <18214.46470.57856.84852@kahikatea.snap.net.nz> <200710301222.03459.ghost@cs.msu.su> X-Mailer: VM 7.19 under Emacs 22.1.50.14 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-10/txt/msg00815.txt.bz2 > I believe that var->value will be NULL. Yes, that looks good. I'll use: if (!var->value || !VALUE_LVAL(var->value)) return 0; and that should keep us both happy. > > When it's created it can be in a different frame according to the syntax. > > However, in Emacs I only create watch expressions in the selected frame > > (the manual suggests that "*" sets the value in the current frame but > > there are many anomalies like this). > > Are you suggesting that GDB code should only work when used from Emacs? If I was, I would probably say something like "I suggest that GDB code should only work when used from Emacs". You're free read it how you like, but I was just giving an example of real use. > GDB, > as it stands, allows you to create a variable object in any frame, and your > patch does not work with that. So, either creating variable objects in any > frame should be disallowed, Actually I think that would be a good idea. Generally a user would create a watch expression in the frame he's examining. If not, the frontend would have to prompt for the frame. Does KDevelop do this? >... > > Likewise I think variable assignment should only be done in the selected > > frame. > > Err, why? I might have varobj for global variable called like 'g'. When I > assign value to that varobj, I don't really want any local variable called > 'g' to get in. Of course, real program would have the variable named > differently, but still. I'm not talking about global variables as they're valid in all frames. >... > > That's what I've just said. > > So, in essence, the primary think you test is that this message now > say "Variable object is not editable"? It's not just the message but that it's now triggered by: if (!(varobj_get_attributes (var) & 0x00000001)) instead of: if (!varobj_set_value (var, expression)) > I personally think that the fact that -var-show-attributes reports rvalues > as non-editable is equally important, but if you don't feel like writing a > test for that, up to you -- in which case I'll probably submit a patch > myself (and maybe even make the 'editable' field into regular varobj > printing, as opposed to this 'attribute' thing). mi_cmd_var_show_attributes calls varobj_get_attributes. Like I said: it's basically the same test. -- Nick http://www.inet.net.nz/~nickrob