From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19123 invoked by alias); 1 Nov 2007 07:52:44 -0000 Received: (qmail 19113 invoked by uid 22791); 1 Nov 2007 07:52:43 -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; Thu, 01 Nov 2007 07:52:40 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1InVmt-0000hp-Ac for gdb-patches@sources.redhat.com; Thu, 01 Nov 2007 11:52:32 +0300 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 1InVmj-0000hU-N4; Thu, 01 Nov 2007 11:52:17 +0300 From: Vladimir Prus To: Nick Roberts Subject: Re: [PATCH] MI: lvalues and variable_editable Date: Thu, 01 Nov 2007 07:52:00 -0000 User-Agent: KMail/1.9.6 Cc: gdb-patches@sources.redhat.com References: <18210.27153.559569.601092@kahikatea.snap.net.nz> <200710311458.58112.ghost@cs.msu.su> <18217.23406.21406.920384@kahikatea.snap.net.nz> In-Reply-To: <18217.23406.21406.920384@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: <200710312247.40840.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-11/txt/msg00005.txt.bz2 On Thursday 01 November 2007 07:51:58 Nick Roberts wrote: > > On Tuesday 30 October 2007 14:04:53 Nick Roberts wrote: > > > > 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. > > > > As long there which code *replaces* gdb_evaluate_expression, I'm > > perfectly happy. Thanks! > > Using var->value == NULL means that variable objects of pointers that cannot > be dereferenced are "noneditable". This means that such variable objects > may change from being "editable" to "noneditable" during execution. This > may not be a bad thing as discussion started from posts about not being > able to assign values to variable objects that were described as "editable". > > I'll look at combining varobj_editable_p with the test in > mi_cmd_var_assign: > > if (!varobj_set_value (var, expression)) > error (_("mi_cmd_var_assign: Could not assign expression to variable object" > > to give one message. I'm not sure that's possible. If you create varobj for *foo, and foo changes to point to inaccessible memory, then assignment to *foo will fail, but I don't know any mechanism in gdb that will tell you that without actually trying assignment. - Volodya