Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* [patch ping] Set TYPE_VPTR_BASETYPE/TYPE_VPTR_FIELDNO of XL C++ virtual class
@ 2005-09-21  6:57 Wu Zhou
  2005-09-29 10:18 ` Wu Zhou
  0 siblings, 1 reply; 3+ messages in thread
From: Wu Zhou @ 2005-09-21  6:57 UTC (permalink / raw)
  To: ezannoni; +Cc: gdb-patches

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


^ permalink raw reply	[flat|nested] 3+ messages in thread
* Re: [patch ping] Set TYPE_VPTR_BASETYPE/TYPE_VPTR_FIELDNO of XL C++ virtual class
@ 2005-09-29  4:53 Wu Zhou
  0 siblings, 0 replies; 3+ messages in thread
From: Wu Zhou @ 2005-09-29  4:53 UTC (permalink / raw)
  To: Wu Zhou; +Cc: ezannoni, gdb-patches

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


^ permalink raw reply	[flat|nested] 3+ messages in thread
end of thread, other threads:[~2005-09-29 10:18 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-09-21  6:57 [patch ping] Set TYPE_VPTR_BASETYPE/TYPE_VPTR_FIELDNO of XL C++ virtual class Wu Zhou
2005-09-29 10:18 ` Wu Zhou
2005-09-29  4:53 Wu Zhou

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox