From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18596 invoked by alias); 10 Dec 2006 21:20:05 -0000 Received: (qmail 18587 invoked by uid 22791); 10 Dec 2006 21:20:04 -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; Sun, 10 Dec 2006 21:19:59 +0000 Received: from kahikatea.snap.net.nz (p202-124-125-222.snap.net.nz [202.124.125.222]) by viper.snap.net.nz (Postfix) with ESMTP id 56DBC3D84C6; Mon, 11 Dec 2006 10:21:06 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id A4A9CBE3F2; Mon, 11 Dec 2006 10:15:31 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17788.30961.422979.535189@kahikatea.snap.net.nz> Date: Sun, 10 Dec 2006 21:20:00 -0000 To: Daniel Jacobowitz Cc: Vladimir Prus , gdb-patches@sources.redhat.com Subject: Re: MI: fix base members in references In-Reply-To: <20061210204207.GA1681@nevyn.them.org> References: <17787.10504.215397.177658@kahikatea.snap.net.nz> <200612100037.24768.ghost@cs.msu.su> <17787.11900.251681.440151@kahikatea.snap.net.nz> <200612100114.44118.ghost@cs.msu.su> <17787.35236.492750.204386@kahikatea.snap.net.nz> <20061210204207.GA1681@nevyn.them.org> X-Mailer: VM 7.19 under Emacs 22.0.91.15 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/msg00159.txt.bz2 > > > does the code you've added ever does anything? > > > > It seems to handle variable objects of references to pointers correctly. > > Have you tried it? > > I have not been able to follow this discussion, but there needs to be a > better level of understanding here. Vlad's asking "why does this fix > the problem" and you're responding "it seems to fix the problem". > Every time I see something like that, I assume the problem is only > being fixed by accident - I'm a big believer in understanding causes. Looking at code is a bit like peeling an onion: when you remove one layer there's another layer beneath. Unfortunately I have to work within my limitations, both temporal and mental, and I was just trying to get Vladimir to do a sanity check. It's easier to show code doesn't work than prove it does and I don't follow his point about using value_type (var->value) instead of var->type. Surely if he thinks that there is a simpler/better patch then the onus is on him to provide it? > get_type_deref looks at the type, and if it is a pointer or reference, > it dereferences it. I assume that this is because we want to show the > children of pointers to structs and references to structs. Is that > right? My patch was just for references to pointers. > If you want to show the children of the struct given a reference to a > pointer to the struct, then it should handle that too. Sounds like it > should check for a reference and _then_ for a pointer, instead of > checking at the same time. I'm not thinking specifically of structs... > There are probably some missing calls to check_typedef here, too. I > don't think you can have a typedef to a reference in C++, but you can > definitely have a typedef to a pointer, so it would probably be > advisable to call check_typedef before checking for TYPE_CODE_PTR. ...or typedefs. -- Nick http://www.inet.net.nz/~nickrob