From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11756 invoked by alias); 9 Oct 2005 03:58:47 -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 11745 invoked by uid 22791); 9 Oct 2005 03:58:44 -0000 Received: from ausmtp01.au.ibm.com (HELO ausmtp01.au.ibm.com) (202.81.18.186) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 09 Oct 2005 03:58:44 +0000 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp01.au.ibm.com (8.12.10/8.12.10) with ESMTP id j9941ck5351576 for ; Sun, 9 Oct 2005 14:01:38 +1000 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.250.243]) by sd0208e0.au.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j9941eal181510 for ; Sun, 9 Oct 2005 14:01:40 +1000 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.12.11/8.13.3) with ESMTP id j993wd7g014740 for ; Sun, 9 Oct 2005 13:58:39 +1000 Received: from [9.181.133.252] ([9.181.133.252]) by d23av02.au.ibm.com (8.12.11/8.12.11) with ESMTP id j993wb6L014700; Sun, 9 Oct 2005 13:58:38 +1000 Date: Sun, 09 Oct 2005 03:58:00 -0000 From: Wu Zhou To: Daniel Jacobowitz cc: gdb-patches@sources.redhat.com Subject: Re: Removing TYPE_VPTR_FIELDNO uses (was: Re: [patch ping] Set TYPE_VPTR_BASETYPE/TYPE_VPTR_FIELDNO of XL C++ virtual class) In-Reply-To: <20051002222103.GA32728@nevyn.them.org> Message-ID: References: <1127969598.433b733eedab9@imap.linux.ibm.com> <20051002222103.GA32728@nevyn.them.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2005-10/txt/msg00072.txt.bz2 Hi Daniel, Thanks for your comments. Some more questions about these code. > > - 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. Maybe we need to add some code to dump VPTRs for gnu-v3 ABI after removing TYPE_VPTR_FIELDNO? > > - 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! It seems that the definition for METHOD_PTR_IS_VIRTUAL is at least error for 64-bit arch. Seen from the changelogs I found it was introduced in gdb since 1992. Will this still stands after more than ten years? #define METHOD_PTR_IS_VIRTUAL(ADDR) ((ADDR) & 0x80000000) Didn't all these different compilers reached an agreement on how to predicate a pointer-to-method is virtual? > > - 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. If so, we can use this to find the vptr. > 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. Do you have any clues on how to determine whether this assumption stands? Best Regards - Wu Zhou