From: Nick Roberts <nickrob@snap.net.nz>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: Variable objects laziness
Date: Wed, 29 Nov 2006 04:14:00 -0000 [thread overview]
Message-ID: <17773.2057.807160.209965@kahikatea.snap.net.nz> (raw)
In-Reply-To: <20061129025457.GA11339@nevyn.them.org>
> > Also -var-update only reports a change when the address changes and not
> > the value. Variable objects were broken before but in a different way
> > (-var-assign worked but -var-update always reported that the reference
> > value had changed).
>
> Just so we're all on the same page, could you post a compilable test
> case? I don't need a dejagnu-ified one, just some C++.
Any C++ program with references (I've never used them in earnest) would do e.g
1: main()
2: {
3: int x = 4;
4: int& rx = x;
5: x = 7;
6: }
1) Do -var-create * - rx before line 4.
2) -var-update --all-values after line 4 picks up the change of address.
3) -var-update --all-values after line 5 doesn't pick up the change of value.
4) -var-assign var1 generates an internal error.
> > I think a further call to coerce_array is needed and the output to -var-update
> > should look like:
> >
> >
> > -var-update --all-values var1
> > ^done,changelist=[{name="var1",value="4",in_scope="true",type_chan ged="false"}]
> >
> > i.e the address shouldn't appear in the value field.
>
> Is that what it did before? I guess it's not surprising.
No, before it would give the address too:
^done,changelist=[{name="var1",value="@0xbff72ebc: 4",in_scope="true",type_chan ged="false"}]
like now, but all the time e.g if you issued -var-update twice without doing
anything in between.
--
Nick http://www.inet.net.nz/~nickrob
next prev parent reply other threads:[~2006-11-29 4:14 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-29 8:59 Nick Roberts
2006-11-29 2:08 ` Nick Roberts
2006-11-29 2:55 ` Daniel Jacobowitz
2006-11-29 4:14 ` Nick Roberts [this message]
2006-11-29 7:25 ` Vladimir Prus
2006-11-29 13:45 ` Daniel Jacobowitz
2006-11-29 13:56 ` Vladimir Prus
2006-11-29 20:25 ` Nick Roberts
2006-11-29 9:09 ` Vladimir Prus
-- strict thread matches above, loose matches on Subject: below --
2006-11-15 2:45 Nick Roberts
2006-11-15 9:22 ` Vladimir Prus
2006-11-14 13:43 Vladimir Prus
2006-11-14 20:47 ` Daniel Jacobowitz
2006-11-15 9:04 ` Vladimir Prus
2006-11-15 16:25 ` Daniel Jacobowitz
2006-11-17 9:23 ` Vladimir Prus
2006-11-17 10:40 ` Mark Kettenis
2006-11-17 10:45 ` Vladimir Prus
2006-11-17 14:22 ` Daniel Jacobowitz
2006-11-17 15:01 ` Vladimir Prus
2006-11-17 17:19 ` Vladimir Prus
2006-11-17 18:12 ` Daniel Jacobowitz
2006-11-18 9:48 ` Vladimir Prus
2006-11-28 17:09 ` Daniel Jacobowitz
2006-12-04 19:27 ` Vladimir Prus
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=17773.2057.807160.209965@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