From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25411 invoked by alias); 29 Nov 2006 23:59:01 -0000 Received: (qmail 25403 invoked by uid 22791); 29 Nov 2006 23:59:00 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 29 Nov 2006 23:58:52 +0000 Received: from kahikatea.snap.net.nz (p202-124-120-138.snap.net.nz [202.124.120.138]) by viper.snap.net.nz (Postfix) with ESMTP id 654632F49E5; Thu, 30 Nov 2006 12:59:42 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 28329BE44C; Thu, 30 Nov 2006 12:54:34 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17774.7608.862541.696058@kahikatea.snap.net.nz> Date: Wed, 29 Nov 2006 23:59:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: MI/C++/references fixup In-Reply-To: <200611291741.13617.vladimir@codesourcery.com> References: <200611291215.21876.vladimir@codesourcery.com> <200611291715.05247.vladimir@codesourcery.com> <20061129142435.GD29365@nevyn.them.org> <200611291741.13617.vladimir@codesourcery.com> X-Mailer: VM 7.19 under Emacs 22.0.91.7 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-11/txt/msg00410.txt.bz2 > > > > 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