This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFA: Document @-frame variable objects


 > 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]