From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1133 invoked by alias); 10 Dec 2006 20:42:32 -0000 Received: (qmail 1121 invoked by uid 22791); 10 Dec 2006 20:42:27 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sun, 10 Dec 2006 20:42:20 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1GtVUt-0000Ym-UJ; Sun, 10 Dec 2006 15:42:08 -0500 Date: Sun, 10 Dec 2006 20:42:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: Vladimir Prus , gdb-patches@sources.redhat.com Subject: Re: MI: fix base members in references Message-ID: <20061210204207.GA1681@nevyn.them.org> Mail-Followup-To: Nick Roberts , Vladimir Prus , gdb-patches@sources.redhat.com 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17787.35236.492750.204386@kahikatea.snap.net.nz> User-Agent: Mutt/1.5.13 (2006-08-11) 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/msg00158.txt.bz2 On Sun, Dec 10, 2006 at 05:14:28PM +1300, Nick Roberts wrote: > Vladimir Prus writes: > > > 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. 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? 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. 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. -- Daniel Jacobowitz CodeSourcery