From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19989 invoked by alias); 13 Jun 2005 03:26: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 19916 invoked by uid 22791); 13 Jun 2005 03:26:04 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 13 Jun 2005 03:26:04 +0000 Received: from drow by nevyn.them.org with local (Exim 4.50) id 1DhfaL-0006Xz-Nb; Sun, 12 Jun 2005 23:26:01 -0400 Date: Mon, 13 Jun 2005 03:26:00 -0000 From: Daniel Jacobowitz To: Wu Zhou Cc: ezannoni@redhat.com, gdb-patches@sources.redhat.com Subject: Re: [RFC] Add a little IBM XL C++ specific code in dwarf2read.c, to set TYPE_VPTR_FIELDNO and TYPE_VPTR_BASETYPE of a virtual class correctly Message-ID: <20050613032601.GJ9288@nevyn.them.org> Mail-Followup-To: Wu Zhou , ezannoni@redhat.com, gdb-patches@sources.redhat.com References: <20050531025031.GA7983@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-06/txt/msg00145.txt.bz2 On Tue, May 31, 2005 at 11:26:52AM +0800, Wu Zhou wrote: > On Mon, 30 May 2005, Daniel Jacobowitz wrote: > > I think the change is probably reasonable. Alternatively, we could > > teach GDB not to rely on TYPE_VPTR_FIELDNO and TYPE_VPTR_BASETYPE if > > the C++ ABI in use does not require them, which the GNU v3 ABI does > > not. That would also be a good solution. > > Yes. I had ever thought of that and even added a file named xlc-abi.c > to not rely on these two fields. But I am not sure whether this is the > most appropriate way. The developer of XL compiler ever told me that > they also comply to the GNU C++ ABI. Maybe it is acceptable to code > that change in gnu-v3-abi.c. My question is: which one is better and > more prone to be accepted by mainline? Any comments, suggestion and > idea are highly appreciated! Right - I did not mean adding a new file for xlc (which you should not need to do), but modifying the GNU v3 support and common code instead. I think that fixing this would be more work, but also more correct. I haven't really looked yet at how much work it would be. -- Daniel Jacobowitz CodeSourcery, LLC