This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[patch ping] Set TYPE_VPTR_BASETYPE/TYPE_VPTR_FIELDNO of XL C++virtual class
- From: Wu Zhou <woodzltc at cn dot ibm dot com>
- To: ezannoni at redhat dot com
- Cc: gdb-patches at sources dot redhat dot com
- Date: Wed, 21 Sep 2005 14:58:10 +0800 (CST)
- Subject: [patch ping] Set TYPE_VPTR_BASETYPE/TYPE_VPTR_FIELDNO of XL C++virtual class
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