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

[Wu Zhou <woodzltc at cn dot ibm dot 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