[RFC] Add a little IBM XL C++ specific code in dwarf2read.c, to set TYPE_VPTR_FIELDNO and TYPE_VPTR_BASETYPE of a virtual class correctly

[RFC] Add a little IBM XL C++ specific code in dwarf2read.c, to set TYPE_VPTR_FIELDNO and TYPE_VPTR_BASETYPE of a virtual class correctly

[Wu Zhou]

Daniel, 

As we discussed in a previous thread before, gdb will drop into SEGV
fault when handling the debug-info of a virtual class which has no
DW_AT_containing_type attribute.  ARM's RVCT compiler will generate 
this kind of debuginfo and prone to trigger SEGV error, which you 
fixed in a big un-cleanuped patch.  IBM's XL compiler will also 
generate this kind of debuginfo and prone to SEGV error too, on 
which I posted a small patch based on yours.  

I see that you are still too busy to look into this.  But maybe we
could handle this somewhat easily.  My thought is to begin with 
eliminating the SEGV error first, which only need a small fix.  Then
we could go on with other parts.  So I post the following IBM XLC++ 
specific patch, wishing that we could make some progress on this. 
What is your point on this idea?  If you think it is ok, I could also
add ARM specific code into this patch.  Please review and comment. 
Thanks a lot!

<2005-05-31>  Wu Zhou  <woodzltc@cn.ibm.com>

	* dwarf2read.c (read_structure_type): Add a little IBM XL C++
	specific code to set TYPE_VPTR_FIELDNO and TYPE_VPTR_BASETYPE
	of a virtual class if a field named "__vfp" is found.  


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


Cheers
- Wu Zhou	  

Re: [RFC] Add a little IBM XL C++ specific code in dwarf2read.c, to set TYPE_VPTR_FIELDNO and TYPE_VPTR_BASETYPE of a virtual class correctly

[Daniel Jacobowitz]

Your computer's date is wrong; please fix that.  I had to go hunting to
see where this message was filed :-)

On Sat, Apr 30, 2005 at 01:53:46PM -0700, Wu Zhou wrote:
> Daniel, 
> 
> As we discussed in a previous thread before, gdb will drop into SEGV
> fault when handling the debug-info of a virtual class which has no
> DW_AT_containing_type attribute.  ARM's RVCT compiler will generate 
> this kind of debuginfo and prone to trigger SEGV error, which you 
> fixed in a big un-cleanuped patch.  IBM's XL compiler will also 
> generate this kind of debuginfo and prone to SEGV error too, on 
> which I posted a small patch based on yours.  
> 
> I see that you are still too busy to look into this.  But maybe we
> could handle this somewhat easily.  My thought is to begin with 
> eliminating the SEGV error first, which only need a small fix.  Then
> we could go on with other parts.  So I post the following IBM XLC++ 
> specific patch, wishing that we could make some progress on this. 
> What is your point on this idea?  If you think it is ok, I could also
> add ARM specific code into this patch.  Please review and comment. 
> Thanks a lot!

I am not the maintainer of this code, so I can't approve patches to it.  
You currently need to speak with Elena about DWARF-2 patches.

I think the change is probably reasonable.  Alternatively, we could
teach GDB not to rely on TYPE_VPTR_FIELDNO and TYPE_VPTR_BASETYPE if
the C++ ABI in use does not require them, which the GNU v3 ABI does
not.  That would also be a good solution.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [RFC] Add a little IBM XL C++ specific code in dwarf2read.c, to set TYPE_VPTR_FIELDNO and TYPE_VPTR_BASETYPE of a virtual class correctly

[Wu Zhou]

On Mon, 30 May 2005, Daniel Jacobowitz wrote:

> Your computer's date is wrong; please fix that.  I had to go hunting to
> see where this message was filed :-)

Sorry for the trouble it brought.  Should be fixed now.  

> 
> On Sat, Apr 30, 2005 at 01:53:46PM -0700, Wu Zhou wrote:
> > Daniel, 
> > 
> > As we discussed in a previous thread before, gdb will drop into SEGV
> > fault when handling the debug-info of a virtual class which has no
> > DW_AT_containing_type attribute.  ARM's RVCT compiler will generate 
> > this kind of debuginfo and prone to trigger SEGV error, which you 
> > fixed in a big un-cleanuped patch.  IBM's XL compiler will also 
> > generate this kind of debuginfo and prone to SEGV error too, on 
> > which I posted a small patch based on yours.  
> > 
> > I see that you are still too busy to look into this.  But maybe we
> > could handle this somewhat easily.  My thought is to begin with 
> > eliminating the SEGV error first, which only need a small fix.  Then
> > we could go on with other parts.  So I post the following IBM XLC++ 
> > specific patch, wishing that we could make some progress on this. 
> > What is your point on this idea?  If you think it is ok, I could also
> > add ARM specific code into this patch.  Please review and comment. 
> > Thanks a lot!
> 
> I am not the maintainer of this code, so I can't approve patches to it.  
> You currently need to speak with Elena about DWARF-2 patches.

OK, got it.  I will also include Elena in the CC list.

Elena,  would you please help review this patch and give your comment on
this?  Thanks a lot!
 
> I think the change is probably reasonable.  Alternatively, we could
> teach GDB not to rely on TYPE_VPTR_FIELDNO and TYPE_VPTR_BASETYPE if
> the C++ ABI in use does not require them, which the GNU v3 ABI does
> not.  That would also be a good solution.

Yes.  I had ever thought of that and even added a file named xlc-abi.c
to not rely on these two fields.  But I am not sure whether this is the
most appropriate way.  The developer of XL compiler ever told me that 
they also comply to the GNU C++ ABI.  Maybe it is acceptable to code 
that change in gnu-v3-abi.c.  My question is: which one is better and 
more prone to be accepted by mainline?  Any comments, suggestion and
idea are highly appreciated! 

Cheers
- Wu Zhou 

Re: [RFC] Add a little IBM XL C++ specific code in dwarf2read.c, to set TYPE_VPTR_FIELDNO and TYPE_VPTR_BASETYPE of a virtual class correctly

[Daniel Jacobowitz]

On Tue, May 31, 2005 at 11:26:52AM +0800, Wu Zhou wrote:
> On Mon, 30 May 2005, Daniel Jacobowitz wrote:
> > I think the change is probably reasonable.  Alternatively, we could
> > teach GDB not to rely on TYPE_VPTR_FIELDNO and TYPE_VPTR_BASETYPE if
> > the C++ ABI in use does not require them, which the GNU v3 ABI does
> > not.  That would also be a good solution.
> 
> Yes.  I had ever thought of that and even added a file named xlc-abi.c
> to not rely on these two fields.  But I am not sure whether this is the
> most appropriate way.  The developer of XL compiler ever told me that 
> they also comply to the GNU C++ ABI.  Maybe it is acceptable to code 
> that change in gnu-v3-abi.c.  My question is: which one is better and 
> more prone to be accepted by mainline?  Any comments, suggestion and
> idea are highly appreciated! 

Right - I did not mean adding a new file for xlc (which you should not
need to do), but modifying the GNU v3 support and common code instead.

I think that fixing this would be more work, but also more correct.
I haven't really looked yet at how much work it would be.

-- 
Daniel Jacobowitz
CodeSourcery, LLC