From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17627 invoked by alias); 26 May 2007 05:53:01 -0000 Received: (qmail 17616 invoked by uid 22791); 26 May 2007 05:53:01 -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; Sat, 26 May 2007 05:52:59 +0000 Received: from kahikatea.snap.net.nz (194.60.255.123.dynamic.snap.net.nz [123.255.60.194]) by viper.snap.net.nz (Postfix) with ESMTP id 0B5993DA358; Sat, 26 May 2007 17:52:56 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 234BE8F92C; Sat, 26 May 2007 17:52:49 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18007.52013.601925.299571@kahikatea.snap.net.nz> Date: Sat, 26 May 2007 05:53:00 -0000 To: Jim Blandy , gdb-patches@sourceware.org Subject: Re: RFA: Document @-frame variable objects In-Reply-To: <18007.33414.708569.679329@kahikatea.snap.net.nz> References: <18007.33414.708569.679329@kahikatea.snap.net.nz> X-Mailer: VM 7.19 under Emacs 22.1.50.2 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-05/txt/msg00403.txt.bz2 > > +@item > > +If it is @samp{@@}, then the expression has no fixed scope: GDB > > +evaluates @var{expression} in the currently selected frame, and future > > +@code{-var-update} commands will use whatever frame is selected when > > +they are invoked. Variable objects of this sort may go in and out of > > +scope as the program runs, and their type may change from one update > > +to the next. > > I don't think this is accurate. If you have two frames, where i=10 in > one and i=5 in the other, GDB won't report any change with -var-update > if you do "up" and "down" to move between them. Actually I'm confused now because GDB 6.6 seems to behave differently to GDB in CVS. In the latter, it does report changes, albeit with the wrong value in the frame in which the varobj wasn't created. I see that there is just one test for this type of varobj -- just for the creation, in mi-var-cmd.exp and mi2-var-cmd.exp -- which explains why changes haven't been noticed. If we are serious about using @, then we really need to check it's behavior and add more tests. -- Nick http://www.inet.net.nz/~nickrob