From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22821 invoked by alias); 29 Sep 2005 10:18:28 -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 22794 invoked by uid 22791); 29 Sep 2005 10:18:16 -0000 Received: from ausmtp02.au.ibm.com (HELO ausmtp02.au.ibm.com) (202.81.18.187) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 29 Sep 2005 10:18:16 +0000 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp02.au.ibm.com (8.12.10/8.12.10) with ESMTP id j8T4GUSP031336 for ; Thu, 29 Sep 2005 14:16:35 +1000 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.250.242]) by sd0208e0.au.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8T4OkCq133940 for ; Thu, 29 Sep 2005 14:24:47 +1000 Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.12.11/8.13.3) with ESMTP id j8T4LkIE014288 for ; Thu, 29 Sep 2005 14:21:46 +1000 Received: from [9.181.133.252] ([9.181.133.252]) by d23av01.au.ibm.com (8.12.11/8.12.11) with ESMTP id j8T4LhDa014229; Thu, 29 Sep 2005 14:21:44 +1000 Date: Thu, 29 Sep 2005 10:18:00 -0000 From: Wu Zhou To: ezannoni@redhat.com cc: drow@false.org, gdb-patches@sources.redhat.com Subject: Re: [patch ping] Set TYPE_VPTR_BASETYPE/TYPE_VPTR_FIELDNO of XL C++ virtual class In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2005-09/txt/msg00289.txt.bz2 OK. Maybe you are very busy. Maybe you didn't see this mail. Anyway, I will try to see whether we can resolve this in another way. Daniel, We ever talked about teaching GDB not to rely on TYPE_VPTR_FIELDNO and TYPE_VPTR_BASETYPE in case that the C++ ABI does not require that. I am now thinking whether we can follow this point to make these c++ compiler to interoperate well with gdb. The first thought out of my mind is to locate what changes and where we need to make. Then I had a search in the gdb source and found that TYPE_VPTR_FIELDNO and TYPE_VPTR_BASETYPE (I will call them VPTRs in the following text for convenience) are only used in the following seven files: dwarf2read.c, gdbtypes.c/gdbtype.h, gnu-v2-abi.c, gnu-v3-abi.c, stabsread.c, varobj.c and eval.c. I had a quick reading for the related code and had the following discovery (any error, please correct me): - 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. - 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. - 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 VPTRsare. Maybe we need to find a way for that? - eval.c (evaluate_subexp_standard): TYPE_VPTR_BASETYPE is used to iterate the baseclasses to find the read address of the virtual function. - gnu-v3-abi.c: is used for rtti, virtual function and virtual base class offset. So the main effort should be focused on the last three files IMHO. What is your point on this? Regards - Wu Zhou On Wed, 21 Sep 2005, Wu Zhou wrote: > Hi Elena, > > GNU c++ compiler depends on DW_AT_containing_type to represent the type > of virtual base class. But some other c++ compiler don't have this > dependence. IBM's XL c++ compiler is one of them. So while trying to > access the virtual base class of a XL c++ class, gdb will get a NULL > pointer and prone to get into SEGV error. > > I posted a patch about five monthes ago to set TYPE_VPTR_BASETYPE and > TYPE_VPTR_FIELDNO of XL C++ virtual class correctly, which could cure this > error. Would you please review this and give your comment? Thanks a lot. > > The original patch is at: > http://sourceware.org/ml/gdb-patches/2005-05/msg00655.html > > You can also refer to the following appendent: > > Index: dwarf2read.c > =================================================================== > RCS file: /cvs/src/src/gdb/dwarf2read.c,v > retrieving revision 1.181 > diff -c -p -r1.181 dwarf2read.c > *** dwarf2read.c 9 Mar 2005 06:03:14 -0000 1.181 > --- dwarf2read.c 30 May 2005 14:22:29 -0000 > *************** read_structure_type (struct die_info *di > *** 3864,3869 **** > --- 3864,3891 ---- > TYPE_VPTR_FIELDNO (type) = TYPE_VPTR_FIELDNO (t); > } > } > + else if (cu->producer > + && strncmp (cu->producer, > + "IBM(R) XL C/C++ Advanced Edition", 32) == 0) > + { > + /* The IBM XLC compiler does not provide direct indication > + of the containing type, but the vtable pointer is > + always named __vfp. */ > + > + int i; > + > + for (i = TYPE_NFIELDS (type) - 1; > + i >= TYPE_N_BASECLASSES (type); > + --i) > + { > + if (strcmp (TYPE_FIELD_NAME (type, i), "__vfp") == 0) > + { > + TYPE_VPTR_FIELDNO (type) = i; > + TYPE_VPTR_BASETYPE (type) = type; > + break; > + } > + } > + } > } > > do_cleanups (back_to); > > > Daniel thought that it is ok, and suggested one alternative fix: teach GDB > not to rely on TYPE_VPTR_FIELDNO and TYPE_VPTR_BASETYPE if the C++ ABI in > use does not require them. But that seems to need more work than this > one. So before working on that idea, I would like to see how do you think > on the above patch. If you accept that, I don't need to work on that > alternative fix. :-) > > Thanks a lot in advance for your kind response. > > Regards > - Wu Zhou > >