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 <woodzltc@cn.ibm.com>]

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