From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 428 invoked by alias); 7 Dec 2006 06:53:20 -0000 Received: (qmail 416 invoked by uid 22791); 7 Dec 2006 06:53:19 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 07 Dec 2006 06:53:13 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GsD7s-0002Ti-QI for gdb-patches@sources.redhat.com; Thu, 07 Dec 2006 07:53:01 +0100 Received: from 73-198.umostel.ru ([82.179.73.198]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Dec 2006 07:53:00 +0100 Received: from ghost by 73-198.umostel.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Dec 2006 07:53:00 +0100 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: MI: fix base members in references Date: Thu, 07 Dec 2006 06:53:00 -0000 Message-ID: References: <200611291555.42209.ghost@cs.msu.su> <17783.31160.70662.126254@kahikatea.snap.net.nz> <17783.40741.544295.457176@kahikatea.snap.net.nz> <200612070921.25566.ghost@cs.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.2 X-IsSubscribed: yes 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/msg00092.txt.bz2 Vladimir Prus wrote: > 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. To avoid potential confusion -- cplus_number_of_children does not handle references. c_number_of_children is not expected to, cplus_number_of_children might handle them, but does not. - Volodya