From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20234 invoked by alias); 7 Dec 2006 06:22:04 -0000 Received: (qmail 20225 invoked by uid 22791); 7 Dec 2006 06:22:03 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 07 Dec 2006 06:21:59 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1GsCdn-0004Cs-Re for gdb-patches@sources.redhat.com; Thu, 07 Dec 2006 09:21:56 +0300 Received: from localhost ([127.0.0.1] helo=ip6-localhost) by zigzag.lvk.cs.msu.su with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1GsCdU-0004Bo-Ib; Thu, 07 Dec 2006 09:21:36 +0300 From: Vladimir Prus To: Nick Roberts Subject: Re: MI: fix base members in references Date: Thu, 07 Dec 2006 06:22:00 -0000 User-Agent: KMail/1.9.1 Cc: Daniel Jacobowitz , Jim Blandy , gdb-patches@sources.redhat.com References: <200611291555.42209.ghost@cs.msu.su> <17783.31160.70662.126254@kahikatea.snap.net.nz> <17783.40741.544295.457176@kahikatea.snap.net.nz> In-Reply-To: <17783.40741.544295.457176@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612070921.25566.ghost@cs.msu.su> 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-12/txt/msg00090.txt.bz2 On Thursday 07 December 2006 07:57, Nick Roberts wrote: > Nick Roberts writes: > > More generally variable objects still don't seem to work (even with > > Vladimir's yet to be committed patch) for references to pointers. > > > > Assuming that the test program below makes sense, a variable object for n1 > > has a value which includes the address and reports the value has changed > > (as it used to do for pure references) > > Sorry thats actually rubbish (I was using an old GDB), but for > > struct S { int i; int j; }; > > S *s; > S *&s1 = s; > > -var-create - * s > ^done,name="var1",numchild="1",type="S *" > (gdb) > -var-create - * s1 > ^done,name="var2",numchild="0",type="S *&" > > so the pointer is dereferenced by GDB but the reference to the pointer is > not. I think that they should work in the same way but I'm not sure. Guess what happens? The code path that computes the number of children -- namely c_number_of_children -- does not seem to handle references. So even while the underlying value is passed via coerce_ref, the reported number of children is always 0, so you can't get any children. Ick! On the other hand, that's no something that I've broke -- I did not even touch c_number_of_children or anything related. I guess we need to first commit the primary references patch and then fix c_number_of_children. Not that I find references to pointers very common thing, but better be correct. - Volodya > >