From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28266 invoked by alias); 8 Jan 2007 09:40:34 -0000 Received: (qmail 28255 invoked by uid 22791); 8 Jan 2007 09:40:34 -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; Mon, 08 Jan 2007 09:40:26 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1H3qzK-0007Yq-8e for gdb-patches@sources.redhat.com; Mon, 08 Jan 2007 12:40:23 +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 1H3qzA-0007YU-5n; Mon, 08 Jan 2007 12:40:08 +0300 From: Vladimir Prus To: Nick Roberts Subject: Re: MI testsuite failures Date: Mon, 08 Jan 2007 09:40:00 -0000 User-Agent: KMail/1.9.1 Cc: gdb-patches@sources.redhat.com References: <17825.33653.885121.321357@kahikatea.snap.net.nz> <17825.64924.680523.195443@kahikatea.snap.net.nz> In-Reply-To: <17825.64924.680523.195443@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: <200701081239.22723.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/msg00222.txt.bz2 On Monday 08 January 2007 11:15, Nick Roberts wrote: > > > 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. Ah, indeed, -var-assign var2 will change var->print_value. > If > you can see a way to do update both please show me. Hmm, I don't understand why this test worked before and does not work now. After all, we never detected the case where two varobjs refer to the same memory location. Why it passed before and why it fails now? We're talking about this failure: FAIL: gdb.mi/mi-var-cmd.exp: assign same value to func (update) right? The assignement is to the 'func' varobj. What is the other varobj that's involved here? > > > 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. The fact that -var-evaluate-expression is not necessary the value in memory is OK. The fact that -var-assign does not change the value of varobj is independent from that, and still confusing. - Volodya