This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [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: drow at false dot org, gdb-patches at sources dot redhat dot com
- Date: Thu, 29 Sep 2005 12:25:04 +0800 (CST)
- Subject: Re: [patch ping] Set TYPE_VPTR_BASETYPE/TYPE_VPTR_FIELDNO of XL C++virtual class
- References: <Pine.LNX.4.63.0509211424570.8678@linux.site>
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
>
>