From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25166 invoked by alias); 24 Jan 2007 09:21:55 -0000 Received: (qmail 25156 invoked by uid 22791); 24 Jan 2007 09:21:54 -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, 24 Jan 2007 09:21:50 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1H9eK6-00063r-5k for gdb-patches@sources.redhat.com; Wed, 24 Jan 2007 12:21:47 +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 1H9eJz-00063f-WD; Wed, 24 Jan 2007 12:21:36 +0300 From: Vladimir Prus To: Nick Roberts Subject: Re: [PATCH] MI: Free values when updating Date: Wed, 24 Jan 2007 09:21:00 -0000 User-Agent: KMail/1.9.1 Cc: gdb-patches@sources.redhat.com References: <17845.48393.877158.536969@kahikatea.snap.net.nz> <17847.9067.795191.960722@kahikatea.snap.net.nz> In-Reply-To: <17847.9067.795191.960722@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: <200701241221.27419.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-01/txt/msg00496.txt.bz2 On Wednesday 24 January 2007 12:14, Nick Roberts wrote: > > > > @@ -1987,11 +1987,7 @@ c_value_of_root (struct varobj **var_han > > > > /* We need to catch errors here, because if evaluate > > > > expression fails we just want to make val->error = 1 and > > > > go on */ > > > > > > This comment is not applicable anymore. > > > > It actually is -- the comment says why we use gdb_evaluate_expression, > > as opposed to evaluate_expression. Only the part about val->error is obsolete, > > and I'll fix that. > > I'm not even sure that current use of gdb_evaluate_expression with variable > objects is sensible. Currently GDB accepts: > > -var-create - * 1/0 > > and if you do: > > -var-create - * n1/n2 > > and n2 is set to 0, with "-var-update --all-values", GDB returns: > > ^done,changelist=[{name="var2",in_scope="false"}] Yes. in_scope="false" actually means "there's being some kind of error evaluating the expression". It's not very clear but not a big problem either. It might be good to clean this up, but I'm nore interested in fixing the (IMO) large scoping problems -- as I've suggested in -var-list --all-locals proposal. - Volodya