From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10489 invoked by alias); 8 Jan 2007 08:15:37 -0000 Received: (qmail 10480 invoked by uid 22791); 8 Jan 2007 08:15:36 -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; Mon, 08 Jan 2007 08:15:29 +0000 Received: from kahikatea.snap.net.nz (unknown [202.124.120.80]) by viper.snap.net.nz (Postfix) with ESMTP id 688F63D821A; Mon, 8 Jan 2007 21:15:25 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 2714D4F6D2; Mon, 8 Jan 2007 21:15:25 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17825.64924.680523.195443@kahikatea.snap.net.nz> Date: Mon, 08 Jan 2007 08:15:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: MI testsuite failures In-Reply-To: References: <17825.33653.885121.321357@kahikatea.snap.net.nz> X-Mailer: VM 7.19 under Emacs 22.0.92.6 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-01/txt/msg00221.txt.bz2 > > FAIL: gdb.mi/mi-var-cmd.exp: assign same value to func (update) > > > > This is more subtle and is caused by having two variable objects for > > one variable, var1 and var2 say. Then if they have a common value 10 > > say and you do: > > > > -var-assign var1 11 > > -var-assign var2 12 > > > > var->updated is set to 1 for each and they are both reported as changed > > with -var-update. > > > > However doing -var-update again gives var1 in the chagelist because the > > real value is 12 but var->print_value is "11". > > That's because -var-assign should update var->print_value. "-var-assign var2 12" will update var->print_value for var2 but not var1. If you can see a way to do update both please show me. > > I think this is a bug in -var-assign; it should set the variable value > > but not interfere with the variable object. Note that generally if you > > have two variable objects for one value and set the value of one with > > -var-assign, one will be reported as changed because var->updated is 1, > > and the other because the value has changed. I think the value held > > by the variable object shouldn't change until -var-update is issued, > > just as is the case if the real value changes during execution. This is > > a patch to do that. > > I don't think that if you assign a value to varobj and then > -var-evaluate-expression returns something else than the value you've > assigned, it would be rather confusing interface. I recall that when I submitted my first patches (start of 2003?) Daniel J was confused by the fact that -var-evaluate-expression didn't always return the current variable value, and Jim Ingham explained that variable objects were designed to work like that. It only appears confusing because you're used to the current behaviour. -- Nick http://www.inet.net.nz/~nickrob