Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Nick Roberts <nickrob@snap.net.nz>
To: Jim Blandy <jimb@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: RFA: Document @-frame variable objects
Date: Sat, 26 May 2007 00:42:00 -0000	[thread overview]
Message-ID: <18007.33414.708569.679329@kahikatea.snap.net.nz> (raw)
In-Reply-To: <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


  parent reply	other threads:[~2007-05-26  0:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-25 17:59 Jim Blandy
2007-05-25 19:08 ` Eli Zaretskii
2007-05-26  0:42 ` Nick Roberts [this message]
2007-05-26  5:53   ` Nick Roberts

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=18007.33414.708569.679329@kahikatea.snap.net.nz \
    --to=nickrob@snap.net.nz \
    --cc=gdb-patches@sourceware.org \
    --cc=jimb@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox