From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26614 invoked by alias); 27 Mar 2008 07:00:30 -0000 Received: (qmail 26598 invoked by uid 22791); 27 Mar 2008 07:00:29 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 27 Mar 2008 07:00:04 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Jem5h-0007X3-0R for gdb-patches@sources.redhat.com; Thu, 27 Mar 2008 07:00:01 +0000 Received: from 78.158.192.230 ([78.158.192.230]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Mar 2008 07:00:01 +0000 Received: from ghost by 78.158.192.230 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Mar 2008 07:00:01 +0000 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: -var-update @ Date: Thu, 27 Mar 2008 07:00:00 -0000 Message-ID: References: <200803261754.10513.vladimir@codesourcery.com> <18411.11710.597524.273860@kahikatea.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.5 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: 2008-03/txt/msg00416.txt.bz2 Nick Roberts wrote: > Vladimir Prus writes: > > > > I've checked it the attached patch which allows one to issue > > > > -var-update @ > > > > and have all @-varobjs (or floating varobjs, as Nick suggested to name them), > > updated. I believe this is the only reasonable way to make @ varobjs, which > > are not bound to thread/frame/block to adequately work in MT program. > > This doesn't seem right to me but then there hasn't been any discussion. > > According to the manual in "-var-create - * EXPRESSION", "*" means "current > frame" (it's actually the selected frame because if you go up a frame, you can > create a variable object there, but as I say the manual mixes the terms). > > Whereas in "-var-update *", "*" means "all variable objects", as in a wildcard > character. > > So I think it's wrong to equate the two uses of "*" which looks like what > you've done with "@". So, you think the change might create confusion for *users* for MI interface. Clearly, as far as behaviour goes, no equation of two uses of "*" was done. I think it might be unfortunate that '*' means different things in different context, but that's what we have now, and probably the first fix to to remove '-var-create *' from the manual and educate frontend authors to use the frame explicitly, as that will make the protocol even less stateful. > > Otherwise, > > if frontend switches thread or frame and wishes to update floating varobjs, > > it should either to "-var-update *", which is extra work, or update varobjs > > one-by-one, which is also not very nice. > > I think that's exactly how it's mean't to work, although it's currently broken. > The usual use case that's cited is recursive functions. > > Using "-var-create - @ EXPRESSION" if there are two frames and you have "int > myvar" in one and "float myvar" in the other, when you change frame, you get > something like: > > -var-update --all-values * > ^done,changelist=[{name="var1",in_scope="true",new_type="float",new_num_children="0"}, > > which is missing the value field. > > with ints in both frames, moving up from the frame the variable object was > created in I get something like: > > -var-update --all-values * > ^done,changelist=[{name="var2",value="7",in_scope="true",type_changed="false"}] > (gdb) > up > &"up\n" > ~"#1 0x08048a00 in main (argc=-72539512, argv=0xbfca8f74) at myprog.c:232\n" > ~"232\t asdf = myprint (2*i, *(a + i) /* hello */);\n" > ^done > (gdb) > -var-update --all-values * > ^done,changelist=[{name="var2",value="-1077244176",in_scope="true",type_changed="false"}] > > when the value is really 0 in the upper frame. Sorry, I don't quite get, from your description, when the output of -var-update misses the value, and when the value is wrong -- it sounds like both cases happen when you do -var-update in a different frame. Can you clarify, or maybe create a testcase for this? > I think we should fix (and document) such floating variable objects We should; I was not aware of the bug with wrong value you report above. > but I really don't think we want a second command to update them. Let me try again. You are using '-var-update *' above. This command will update all variable objects, including those that a bound to a frame. There's no need to update variable objects that are bound to a frame -- a change to selected thread or frame will not change them at all. Updating variable object can take considerable time, and therefore it's better to be able to update only floating variable object. Is any bit of the logic above faulty? - Volodya