From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10897 invoked by alias); 21 Sep 2005 06:57:26 -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 10876 invoked by uid 22791); 21 Sep 2005 06:57:14 -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; Wed, 21 Sep 2005 06:57:14 +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 j8L6pSmC140512 for ; Wed, 21 Sep 2005 16:51:31 +1000 Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.250.244]) by sd0208e0.au.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8L6xWdj087018 for ; Wed, 21 Sep 2005 16:59:36 +1000 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.12.11/8.13.3) with ESMTP id j8L6uVMq004415 for ; Wed, 21 Sep 2005 16:56:32 +1000 Received: from [9.181.133.252] ([9.181.133.252]) by d23av03.au.ibm.com (8.12.11/8.12.11) with ESMTP id j8L6uTVK004352; Wed, 21 Sep 2005 16:56:30 +1000 Date: Wed, 21 Sep 2005 06:57:00 -0000 From: Wu Zhou To: ezannoni@redhat.com cc: gdb-patches@sources.redhat.com Subject: [patch ping] Set TYPE_VPTR_BASETYPE/TYPE_VPTR_FIELDNO of XL C++ virtual class Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2005-09/txt/msg00187.txt.bz2 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