Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Vladimir Prus <ghost@cs.msu.su>
To: Jim Ingham <jingham@apple.com>,  GDB List <gdb@sources.redhat.com>
Subject: Re: MI: type prefixes for values
Date: Thu, 06 Apr 2006 14:05:00 -0000	[thread overview]
Message-ID: <200604061745.16585.ghost@cs.msu.su> (raw)
In-Reply-To: <20060406133546.GB25088@nevyn.them.org>

On Thursday 06 April 2006 17:35, Daniel Jacobowitz wrote:
> On Thu, Apr 06, 2006 at 05:03:25PM +0400, Vladimir Prus wrote:
> > I was thinking about this more, and still not 100% sure how Xcode can do
> > this. Do you mean that Xcode takes a stack trace when the varobj was
> > created, and deletes varobj whenever it sees that stack became shorter?
> >
> > The case I'm not sure about is this:
> >
> > 1. main calls 'a' which calls 'b' which bits breakpoint.
> > 2  varobj is created for local var of 'b'
> > 3. Users says 'continue'.
> > 4. 'b' exists and then 'a' calls 'b' again and breakpoint is
> >    hit again.
> >
> > However, this second time it's not guaranteed that stack frame of 'b' is
> > at the same address as it was the last time -- maybe 'a' has pushed
> > something on stack. How do you detect this case?
>
> Either b's stack frame is at the same address - in which case the
> varobj is still valid - or else it isn't, in which case the frame id
> has changed.

I did not know that GDB exposes frame ID in any way, and Jim has mentioned 
that it's XCode that does the magic, not gdb. Is there some command to print 
frame id that I've missed?

> > > Note, however, that the varobj's do remember their frames, so if you
> > > tried to evaluate one that was no longer on the stack, the varobj
> > > would report "out of scope".
> >
> > Would be great to add this in FSF version.
>
> It's already there:
>
>   /* The frame for this expression */
>   struct frame_id frame;
>
> c_value_of_root will always fail if the frame is gone.

Sorry, does not seems to work this way here. For the following program: 

  void foo()
  {
      int i = 10;
      ++i;
  }

  int main()
  {
      foo();
  }

I get this session:

    (gdb)
    -break-insert a.cpp:5
    ^done,bkpt={......
    (gdb)
    -exec-run
    ^running
    (gdb)
    *stopped,reason="breakpoint-hit",frame={addr="0x080483a1",func="foo"
    (gdb)
    -var-create TMP * i
    ^done,name="TMP",numchild="0",type="int"
    (gdb)
    -var-evaluate-expression TMP
    ^done,value="10"
    (gdb)
    -exec-finish
    ^running
    (gdb)
    *stopped,reason="function-finished",frame={addr="0x080483bd",func="main",
    (gdb)
    -var-evaluate-expression TMP
    ^done,value="10"
    (gdb)

There's no indication that 'TMP' varobj belongs to the stack frame we've 
already left. This is with vanilla 6.4.

- Volodya


  reply	other threads:[~2006-04-06 13:45 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-17  9:09 Vladimir Prus
2006-02-17 10:22 ` Eli Zaretskii
2006-02-17 10:29   ` Vladimir Prus
2006-02-17 11:26     ` Eli Zaretskii
     [not found]       ` <200602171450.16858.ghost@cs.msu.su>
2006-02-17 13:49         ` Eli Zaretskii
2006-02-17 13:54           ` Daniel Jacobowitz
2006-02-17 14:08             ` Eli Zaretskii
2006-02-17 13:58           ` Vladimir Prus
2006-02-17 14:11             ` Eli Zaretskii
2006-02-17 14:26               ` Vladimir Prus
2006-02-17 14:36                 ` Bob Rossi
2006-02-17 14:43                   ` Vladimir Prus
2006-02-17 14:51                     ` Bob Rossi
2006-02-17 15:02                       ` Vladimir Prus
2006-02-17 19:25                 ` Eli Zaretskii
2006-02-17 19:33                   ` Daniel Jacobowitz
2006-02-17 19:36                     ` Eli Zaretskii
2006-02-17 19:38                       ` Daniel Jacobowitz
2006-02-17 19:56                         ` Eli Zaretskii
2006-02-17 20:05                           ` Bob Rossi
2006-02-17 20:07                             ` Eli Zaretskii
2006-02-17 20:17                               ` Daniel Jacobowitz
2006-02-17 20:28                                 ` Eli Zaretskii
2006-02-17 20:33                                   ` Daniel Jacobowitz
2006-02-17 21:14                                     ` Jim Ingham
2006-02-18 11:34                                       ` Eli Zaretskii
2006-02-20 13:47                                         ` Vladimir Prus
2006-02-20  8:11                                       ` Vladimir Prus
2006-02-20 19:49                                         ` Jim Ingham
2006-02-20 20:56                                           ` Daniel Jacobowitz
2006-02-20 20:57                                             ` Jim Ingham
2006-02-21 14:15                                           ` Vladimir Prus
2006-02-21 21:33                                             ` Jim Ingham
2006-04-06 13:33                                               ` Vladimir Prus
2006-04-06 13:45                                                 ` Daniel Jacobowitz
2006-04-06 14:05                                                   ` Vladimir Prus [this message]
2006-04-06 14:31                                                     ` Daniel Jacobowitz
2006-04-06 15:05                                                       ` Vladimir Prus
2006-04-06 15:32                                                         ` Daniel Jacobowitz
2006-04-06 18:53                                                           ` Jim Ingham
2006-04-06 16:49                                                     ` Jim Ingham
2006-04-06 16:49                                                       ` Daniel Jacobowitz
2006-04-06 16:52                                                         ` Jim Ingham
2006-04-06 18:58                                                 ` Jim Ingham
2006-04-07  8:13                                                   ` Vladimir Prus
2006-04-07 20:08                                                     ` Jim Ingham
2006-04-12 15:38                                                       ` Vladimir Prus
2006-04-12 19:41                                                         ` Jim Ingham
2006-04-13 16:15                                                           ` Vladimir Prus
2006-02-17 21:19                                     ` Daniel Jacobowitz
2006-02-17 20:20                               ` Bob Rossi
2006-02-17 20:47                                 ` Daniel Jacobowitz
2006-02-17 19:44                       ` Bob Rossi
2006-02-17 19:59                         ` Eli Zaretskii
2006-02-20  7:28                         ` Vladimir Prus
2006-02-20 23:37                           ` Eli Zaretskii
2006-02-21  4:13                             ` Daniel Jacobowitz
2006-02-21 14:15                               ` Vladimir Prus
2006-02-21 20:41                                 ` Daniel Jacobowitz
2006-02-20 13:48                   ` Vladimir Prus
2006-02-17 11:27     ` 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=200604061745.16585.ghost@cs.msu.su \
    --to=ghost@cs.msu.su \
    --cc=gdb@sources.redhat.com \
    --cc=jingham@apple.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