From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14188 invoked by alias); 9 Oct 2005 20:09:36 -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 14090 invoked by uid 22791); 9 Oct 2005 20:09:33 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 09 Oct 2005 20:09:33 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1EOhUB-0001zJ-B4; Sun, 09 Oct 2005 16:09:31 -0400 Date: Sun, 09 Oct 2005 20:09:00 -0000 From: Daniel Jacobowitz To: Wu Zhou 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) Message-ID: <20051009200931.GC7107@nevyn.them.org> Mail-Followup-To: Wu Zhou , gdb-patches@sources.redhat.com References: <1127969598.433b733eedab9@imap.linux.ibm.com> <20051002222103.GA32728@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-10/txt/msg00078.txt.bz2 On Sun, Oct 09, 2005 at 12:02:16PM +0800, Wu Zhou wrote: > > > - 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? I wouldn't even bother unless you need it for debugging; this code doesn't see much use lately. > > > - 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? I don't know what the v3 ABI does for this; but it certainly does not do it that way. > > 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? I don't know, I'm afraid; some experimentation is in order. -- Daniel Jacobowitz CodeSourcery, LLC