From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11918 invoked by alias); 27 Mar 2008 09:54:17 -0000 Received: (qmail 11907 invoked by uid 22791); 27 Mar 2008 09:54:16 -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; Thu, 27 Mar 2008 09:53:45 +0000 Received: from kahikatea.snap.net.nz (100.62.255.123.dynamic.snap.net.nz [123.255.62.100]) by viper.snap.net.nz (Postfix) with ESMTP id 0A0BB3DA47B; Thu, 27 Mar 2008 22:53:37 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 67CCE8FC6D; Thu, 27 Mar 2008 21:53:34 +1200 (NZST) From: Nick Roberts To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: -var-update @ In-Reply-To: References: <200803261754.10513.vladimir@codesourcery.com> <18411.11710.597524.273860@kahikatea.snap.net.nz> X-Mailer: VM 7.19 under Emacs 22.1.92.3 Message-Id: <20080327095334.67CCE8FC6D@kahikatea.snap.net.nz> Date: Thu, 27 Mar 2008 09:54:00 -0000 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/msg00418.txt.bz2 > > 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. I'm not sure that I would advocate it's removal just yet, but yes it does seem to be best for the frontend to keep track of the state of the debugger rather than Gdb >... > 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? void mysub () { int myvar = 5; int myvar1 = 5; return; } main () { float myvar = 7.8; int myvar1 = 7; mysub (); } Stop Gdb on the return statement in mysub, then: (gdb) -var-create - @ myvar ^done,name="var1",numchild="0",value="5",type="int",thread-id="1" (gdb) -var-create - @ myvar1 ^done,name="var2",numchild="0",value="5",type="int",thread-id="1" (gdb) up &"up\n" ~"#1 0x0804837f in main () at temp5.c:13\n" ~"13\t mysub ();\n" ^done (gdb) -var-update --all-values var1 ^done,changelist=[{name="var1",in_scope="true",new_type="float",new_num_children="0"}] (gdb) -var-update --all-values var2 ^done,changelist=[{name="var2",value="-1080652880",in_scope="true",type_changed="false"}] (gdb) > > 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 There's a logic there if the frontend knows when the variable objects that are bound to a frame will not change. If there's a console, the user can change the value with "p myvar=9", say, and the frontend wouldn't know directly that such a variable object had changed value. However, on reflection there is no harm in having this functionality as I see now that "*" updates both kinds of objects so a frontend needn't use it. I would just suggest a more consistent syntax as currently: -var-update @ Updates all floating variable objects. -var-update * Updates all variable objects. -var-update var1 Updates the variable object var1 (floating or otherwise). -var-create - @ Creates a floating variable object. -var-create - * Creates a fixed frame variable object. -- Nick http://www.inet.net.nz/~nickrob