This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFA: Document @-frame variable objects
- From: Nick Roberts <nickrob at snap dot net dot nz>
- To: Jim Blandy <jimb at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Sat, 26 May 2007 12:42:46 +1200
- Subject: Re: RFA: Document @-frame variable objects
- References: <m3tzu095cm.fsf@codesourcery.com>
> 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