From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8288 invoked by alias); 28 Jan 2007 17:11:42 -0000 Received: (qmail 8280 invoked by uid 22791); 28 Jan 2007 17:11:42 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sun, 28 Jan 2007 17:11:37 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1HBDZ0-0003vX-Gs; Sun, 28 Jan 2007 12:11:34 -0500 Date: Sun, 28 Jan 2007 17:11:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb-patches@sourceware.org Subject: Re: [ob] Adjust member pointer test for g++ 3.3 Message-ID: <20070128171134.GA15012@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sourceware.org References: <20070112201706.GA2673@nevyn.them.org> <200701122150.l0CLoRue029795@brahms.sibelius.xs4all.nl> <20070112230803.GB7039@nevyn.them.org> <200701281539.l0SFdxiq013153@brahms.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200701281539.l0SFdxiq013153@brahms.sibelius.xs4all.nl> User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-01/txt/msg00571.txt.bz2 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. > 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. -- Daniel Jacobowitz CodeSourcery