From: Nick Roberts <nickrob@snap.net.nz>
To: Vladimir Prus <vladimir@codesourcery.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: MI/C++/references fixup
Date: Wed, 29 Nov 2006 23:59:00 -0000 [thread overview]
Message-ID: <17774.7608.862541.696058@kahikatea.snap.net.nz> (raw)
In-Reply-To: <200611291741.13617.vladimir@codesourcery.com>
> > > > In C++ it can't meaningfully change. In a program, though, it can;
> > > > once when it's initialized, and again if something scribbles on the
> > > > stack. And that might be what you're trying to debug. So, I'm
> > > > a little wary of this; it seems to me that we ought to check for both
> > > > changes in the address and value (sort of like we do for watchpoints).
I'm not that familiar with references but presumably the idea is not to have
to think about the address otherwise you might as well use a pointer.
> > > In practice, if the address changes, the value also changes, so the user
> > > can notice. Second, if user really wants to get the address, he can do
> > > that with "&whatever".
> >
> > I suppose that's true. Want to post an updated patch, and we'll see if
> > anyone has a reason to keep it? We're leaving the CLI as it was, this
> > time.
>
> Here's it.
> - Volodya
> * varobj.c (varobj_create): Don't call release_value.
> (varobj_set_value): Likewise.
> (install_new_value): Call coerce_ref and release_value
> on the value. Add asserts.
This changes to varobj.c look good to me.
* gdb.mi/mi-cpp.exp: New file.
* gdb.mi/mi-cpp.cpp: New file.
gdb.mi/mi-var-cp.exp?
gdb.mi/mi-var-cp.cc?
Its for variable objects, and for consistency. The testsuite has the directory
gdb.cp and it's populated with *.cc files
--
Nick http://www.inet.net.nz/~nickrob
next prev parent reply other threads:[~2006-11-29 23:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-29 9:15 Vladimir Prus
2006-11-29 9:25 ` Vladimir Prus
2006-11-29 14:01 ` Daniel Jacobowitz
2006-11-29 14:15 ` Vladimir Prus
2006-11-29 14:24 ` Daniel Jacobowitz
2006-11-29 14:41 ` Vladimir Prus
2006-11-29 23:59 ` Nick Roberts [this message]
2006-11-30 7:31 ` Vladimir Prus
2006-12-05 21:11 ` Daniel Jacobowitz
2006-12-06 9:17 ` Vladimir Prus
2006-12-07 14:39 ` Daniel Jacobowitz
2006-12-08 12:45 ` 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=17774.7608.862541.696058@kahikatea.snap.net.nz \
--to=nickrob@snap.net.nz \
--cc=gdb-patches@sources.redhat.com \
--cc=vladimir@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