Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Nick Roberts <nickrob@snap.net.nz>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] MI: -var-update bug
Date: Sat, 09 Dec 2006 20:47:00 -0000	[thread overview]
Message-ID: <17787.8140.925641.542454@kahikatea.snap.net.nz> (raw)
In-Reply-To: <20061208202300.GA26172@nevyn.them.org>

 > >  > Randomisation isn't even the issue - I think that what you've got now
 > >  > is simply an accident, and varobjs associated with a particular frame
 > >  > should not become valid if a similar looking frame reappears later.
 > > 
 > > OK that shows I've misunderstood.  I thought it was looking for a frame
 > > to associate with it.
 > 
 > If a varobj is associated with a particular frame, and that frame
 > leaves the stack, I think we should report in_scope="false".  I'm
 > thinking that we should always report in_scope="false" after that
 > point... even if another frame that happens to have the same frame
 > ID appears later.

That's why I thought randomisation was an issue: without it presumably when
GDB stops at the same point (after restarting) for the second time, the frame
looks the same as it did the first time.  In this situation, the user might
want to keep the variable object.

Where the user creates a variable object, comes out of the frame and goes
into the next, it might be best for the variable object to be out of scope.
Does GDB check the procedure name is different in this case? (if it's the
same procedure, the variable object could presumably stay in scope).

 > There seem to be a bunch of different ways a varobj can associate
 > with a frame; I guess we don't need to stop varobjs that have
 > use_current_frame or no valid_block?

Do you mean use_selected_frame?

-var-create - * fred  (USE_CURRENT_FRAME)    Usual case.  Documented.
-var-create - @ fred  (USE_SELECTED_FRAME)   Undocumented.

I think the latter is evaluated in the frame where execution stops.

 > >  > Right now we never delete varobjs automatically.  We could preserve
 > >  > that, but set a flag on the varobjs indicating they're permanently out
 > >  > of scope?
 > > 
 > > What value is a variable object that is permanently out of scope?
 > 
 > Just in_scope="false".

I mean "what worth/benefit". :-)

-- 
Nick                                           http://www.inet.net.nz/~nickrob


      reply	other threads:[~2006-12-09 20:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-08 19:38 Nick Roberts
2006-12-08 19:43 ` Daniel Jacobowitz
2006-12-08 19:56   ` Nick Roberts
2006-12-08 20:04     ` Daniel Jacobowitz
2006-12-08 20:09       ` Nick Roberts
2006-12-08 20:23         ` Daniel Jacobowitz
2006-12-09 20:47           ` Nick Roberts [this message]

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=17787.8140.925641.542454@kahikatea.snap.net.nz \
    --to=nickrob@snap.net.nz \
    --cc=drow@false.org \
    --cc=gdb-patches@sources.redhat.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