From: Daniel Jacobowitz <drow@false.org>
To: Nick Roberts <nickrob@snap.net.nz>
Cc: gdb-patches@sources.redhat.com
Subject: Re: MI: Another -var-update bug? [PATCH]
Date: Sat, 30 Dec 2006 15:06:00 -0000 [thread overview]
Message-ID: <20061230150650.GB15107@nevyn.them.org> (raw)
In-Reply-To: <17791.40309.90872.126841@kahikatea.snap.net.nz>
On Wed, Dec 13, 2006 at 07:28:05PM +1300, Nick Roberts wrote:
> > Variable objects appear to test scope on a frame basis (in c_value_of root).
> > If we create a variable object for j in the inner block of the program below
> > then doing -var-update on line 10 doesn't report it as being out of scope.
> > But struct varobj_root has a member struct block *valid_block. Presumably
> > the addresses in this structure can be used to test if the variable is still
> > in scope or not
>
> Something like below?
Yeah. My only concern about this is a variable going out of scope
which might then come back into scope. That can't happen if the frame
is gone (unless something has changed), but it can happen with blocks
once we support optimized blocks better (I posted a patch for this
once).
Here's an example. Suppose we have this code:
int func()
{
int i = foo();
{
int j = bar();
j = j * j;
i += j;
}
baz();
return i;
}
Since baz can't see i or j, it's legitimate for the compiler to move
the call to baz up to right after the call to bar. Then we'll appear
to "leave" the block and "re-enter" it after another step.
Will the front end delete the varobj if it sees in_scope="false"?
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2006-12-30 15:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-12 11:09 MI: Another -var-update bug? Nick Roberts
2006-12-13 6:32 ` MI: Another -var-update bug? [PATCH] Nick Roberts
2006-12-30 15:06 ` Daniel Jacobowitz [this message]
2006-12-30 22:43 ` Nick Roberts
2006-12-31 2:19 ` Daniel Jacobowitz
2007-01-01 16:24 ` Daniel Jacobowitz
2007-01-01 22:13 ` Nick Roberts
2007-01-04 18:51 ` Vladimir Prus
2007-01-04 19:43 ` Nick Roberts
2007-01-04 18:49 ` Vladimir Prus
2007-01-04 23:59 ` Nick Roberts
2007-01-05 9:10 ` Vladimir Prus
2007-01-05 15:10 ` Daniel Jacobowitz
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=20061230150650.GB15107@nevyn.them.org \
--to=drow@false.org \
--cc=gdb-patches@sources.redhat.com \
--cc=nickrob@snap.net.nz \
/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