From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 762 invoked by alias); 26 May 2007 00:42:56 -0000 Received: (qmail 754 invoked by uid 22791); 26 May 2007 00:42:55 -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 00:42:53 +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 E1A0C3DA35D; Sat, 26 May 2007 12:42:49 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id A19AA8F92C; Sat, 26 May 2007 12:42:47 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18007.33414.708569.679329@kahikatea.snap.net.nz> Date: Sat, 26 May 2007 00:42:00 -0000 To: Jim Blandy Cc: gdb-patches@sourceware.org Subject: Re: RFA: Document @-frame variable objects In-Reply-To: References: 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/msg00402.txt.bz2 > Could the MI folks also read this over for accuracy? I've never tried to this behaviour because I've not used it yet, there are many instance in the GDB manual where current and selected frame are confused, and if the description isn't completely accurate it may get reported as a bug. The manual currently says: > The frame under which the expression should be evaluated can be > specified by FRAME-ADDR. A `*' indicates that the current frame should > be used. Even this isn't true. If you stop in a frame (current frame) then do "up", you can no longer create variable objects in the current frame, but you can create them in the selected frame. >... > +@item > +If it is @samp{*}, then GDB evaluates @var{expression} in the scope of > +the frame selected at the time the @code{-var-create} command is > +given. This sounds right. > When the frame is eventually popped, the variable object is > +marked out of scope. This is really part of "-var-update" and I've added something about scope the manual already, although you might want to add to it. > +@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. Note that thhere are probably many other deficiencies in the description of MI, e.g, * `*ADDR-ADDR' -- a memory address range (TBD) can't work because `*0x8049e54 - 3' gets evaluated by GDB as the value at 0x8049e54 minus 3. -- Nick http://www.inet.net.nz/~nickrob