From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25976 invoked by alias); 27 Mar 2008 05:17:23 -0000 Received: (qmail 25966 invoked by uid 22791); 27 Mar 2008 05:17:21 -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 05:16:55 +0000 Received: from kahikatea.snap.net.nz (211.30.255.123.static.snap.net.nz [123.255.30.211]) by viper.snap.net.nz (Postfix) with ESMTP id E8FDD3DA2D8; Thu, 27 Mar 2008 18:16:51 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 305658FC6D; Thu, 27 Mar 2008 17:16:49 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18411.11710.597524.273860@kahikatea.snap.net.nz> Date: Thu, 27 Mar 2008 05:17:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: -var-update @ In-Reply-To: <200803261754.10513.vladimir@codesourcery.com> References: <200803261754.10513.vladimir@codesourcery.com> X-Mailer: VM 7.19 under Emacs 23.0.60.51 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/msg00415.txt.bz2 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 "@". > 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. I think we should fix (and document) such floating variable objects but I really don't think we want a second command to update them. -- Nick http://www.inet.net.nz/~nickrob