From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4661 invoked by alias); 2 Oct 2005 22:21:08 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 4641 invoked by uid 22791); 2 Oct 2005 22:21:06 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 02 Oct 2005 22:21:06 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1EMCCd-0000dd-Ha; Sun, 02 Oct 2005 18:21:03 -0400 Date: Sun, 02 Oct 2005 22:21:00 -0000 From: Daniel Jacobowitz To: Wu Zhou Cc: gdb-patches@sources.redhat.com Subject: Removing TYPE_VPTR_FIELDNO uses (was: Re: [patch ping] Set TYPE_VPTR_BASETYPE/TYPE_VPTR_FIELDNO of XL C++ virtual class) Message-ID: <20051002222103.GA32728@nevyn.them.org> Mail-Followup-To: Wu Zhou , gdb-patches@sources.redhat.com References: <1127969598.433b733eedab9@imap.linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1127969598.433b733eedab9@imap.linux.ibm.com> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-10/txt/msg00003.txt.bz2 On Thu, Sep 29, 2005 at 12:53:18AM -0400, Wu Zhou wrote: > - gnu-v2-abi.c is for an old ABI. Not relevant. > - stabsread.c is for a different debug format. Not relevant. > - dwarf2read.c: to read out data for VPTRs if there are any. No need for > any change IMO. Yes, I agree. > - gdbtypes.c/gdbtype.h: to initialize VPTR_FIELDNO (in alloc_type and > create_array_type), fill VPTRs (in fill_in_vptr_fieldno), and dump VPTRs > (in recursive_dump_type). Maybe some change to the type dumping is > needed. Not if we leave them for older ABIs and stabs. > - varobj.c (cplus_class_num_children and cplus_name_of_child): The code > will ignore VPTRs when iterating thru the base classes. I don't know > the way how to iterate thru the base classes if there is no dependence > for VPTRs. Maybe we need to find a way for that? For this code, it may suffice to ignore DW_AT_artificial fields and make sure that the vptr is tagged as artificial. Or, call a new C++ ABI method (cp-abi.h) to check for vptrs and ignore them. > - eval.c (evaluate_subexp_standard): TYPE_VPTR_BASETYPE is used to iterate > the baseclasses to find the real address of the virtual function. This code needs to be (A) read and thought about, so that we can figure out what it used to do, and (B) replaced with something less broken. It hasn't worked in forever. Take a look at what METHOD_PTR_IS_VIRTUAL expands to! I believe this was specific to one particular C++ ABI. I don't remember which... maybe gnuv2, maybe HP aCC. > - gnu-v3-abi.c: VPTRs is used for rtti, virtual function and virtual base > class offset. In this file, I think we can skip all the rigamarole with debug information to find the vptr. It's very easy: it's the size of a pointer, and it's at offset 0. Always. Unless of course there isn't one. We may need to figure out what the field at offset 0 is to see whether it's a vptr or a user variable. I haven't thought about that in a while; maybe we can assume that there is one by the time we get into this file. -- Daniel Jacobowitz CodeSourcery, LLC