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

[Wu Zhou <woodzltc at cn dot ibm dot com>]

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