[patch ping] Set TYPE_VPTR_BASETYPE/TYPE_VPTR_FIELDNO of XL C++ virtual class

[patch ping] Set TYPE_VPTR_BASETYPE/TYPE_VPTR_FIELDNO of XL C++ virtual class

[Wu Zhou]

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

Re: [patch ping] Set TYPE_VPTR_BASETYPE/TYPE_VPTR_FIELDNO of XL C++ virtual class

[Wu Zhou]

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
> 
> 

Re: [patch ping] Set TYPE_VPTR_BASETYPE/TYPE_VPTR_FIELDNO of XL C++ virtual class

[Wu Zhou]

OK.  Maybe you are 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.  So I had a search in the gdb source tree 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 also 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 VPTRs.  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 real address of the virtual function.

- gnu-v3-abi.c: VPTRs 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


Quoting Wu Zhou <woodzltc@cn.ibm.com>:

> 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
> 
> 


Cheers
- Wu Zhou