Re: [ob] Adjust member pointer test for g++ 3.3

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Sun, 28 Jan 2007 12:11:34 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb-patches@sourceware.org
> Mail-Followup-To: Mark Kettenis <mark.kettenis@xs4all.nl>,
> 	gdb-patches@sourceware.org
> Content-Disposition: inline
> X-XS4ALL-DNSBL-Checked: mxdrop24.xs4all.nl checked 66.93.172.17 against DNS blacklists
> X-Virus-Scanned: by XS4ALL Virus Scanner
> X-XS4ALL-Spam-Score: 0.0 () DK_POLICY_SIGNSOME
> X-XS4ALL-Spam: NO
> Envelope-To: mark.kettenis@xs4all.nl
> X-UIDL: 1170004298._smtp.mxdrop24.68367,S=3014
> 
> On Sun, Jan 28, 2007 at 04:39:59PM +0100, Mark Kettenis wrote:
> > Here's the relevant readelf -a output:
> > 
> >  <1><11f>: Abbrev Number: 3 (DW_TAG_base_type)
> >      DW_AT_name        : int    
> >      DW_AT_byte_size   : 4      
> >      DW_AT_encoding    : 5      (signed)
> > ...
> >  <1><177b>: Abbrev Number: 2 (DW_TAG_typedef)
> >      DW_AT_name        : PMI    
> >      DW_AT_decl_file   : 1      
> >      DW_AT_decl_line   : 82     
> >      DW_AT_type        : <1786> 
> >  <1><1786>: Abbrev Number: 20 (DW_TAG_pointer_type)
> >      DW_AT_byte_size   : 8      
> >      DW_AT_type        : <178c> 
> >  <1><178c>: Abbrev Number: 47 (DW_TAG_ptr_to_member_type)
> >      DW_AT_containing_type: <14a7>      
> >      DW_AT_type        : <11f>  
> > 
> > So it looks like GCC 3.3.5 is emitting bogus debug info.  Do you see a
> > possibility to deal with that?
> 
> Hmm... how much of a hack do you think it's worth? :-)  It's definitely
> possible.
> 
> The problem is that this is a perfectly legitimate piece of debug
> output, describing "int A::**" instead of "int A::*".  We could
> recognize this problem based on string matching the DW_AT_producer;
> I have added precedents for that before.  I don't see any other way
> of doing it.

I don't really care; ok if I xfail those tests for GCC 3.3.x?  3.4.x
seems to be fine.  Did you test things on some other GCC versions?

> > Isn't it just another cascading error because initializing members
> > through data member pointers fails?
> 
> Oh, you're probably right.
> 
> > P.S. You still need to submit some bug reports for the gdb/NNN's.
> 
> Rather delete most of them, at this point - I didn't add them in this
> round of changes.  Michael Chastain did several years ago, when none of
> these tests worked with GCC.

Oops, for some reason I thought this was a new test.  Anyway, the
failure modes are probably completely different after your code
changes, so removing them is probably the most sensible thing to do.