From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2336 invoked by alias); 28 Jan 2007 15:40:17 -0000 Received: (qmail 2328 invoked by uid 22791); 28 Jan 2007 15:40:16 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO brahms.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 28 Jan 2007 15:40:10 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.13.8/8.13.8) with ESMTP id l0SFe0VH030608; Sun, 28 Jan 2007 16:40:00 +0100 (CET) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.13.8/8.13.8/Submit) id l0SFdxiq013153; Sun, 28 Jan 2007 16:39:59 +0100 (CET) Date: Sun, 28 Jan 2007 15:40:00 -0000 Message-Id: <200701281539.l0SFdxiq013153@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: gdb-patches@sourceware.org In-reply-to: <20070112230803.GB7039@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 12 Jan 2007 18:08:03 -0500) Subject: Re: [ob] Adjust member pointer test for g++ 3.3 References: <20070112201706.GA2673@nevyn.them.org> <200701122150.l0CLoRue029795@brahms.sibelius.xs4all.nl> <20070112230803.GB7039@nevyn.them.org> 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/msg00570.txt.bz2 > Date: Fri, 12 Jan 2007 18:08:03 -0500 > From: Daniel Jacobowitz > > On Fri, Jan 12, 2007 at 10:50:27PM +0100, Mark Kettenis wrote: > > The test now runs for me, but I get quite a few errors. Here's the > > resulting bit from gdb.log. Can you spot what's going wromg here? > > Should we XFAIL this test for GCC 3.3? > > That depends how we got to some of these bogus conclusions. I filed > a GCC bug for the lousy debug info it emits for member pointers; until > that's fixed, though, I added a workaround in dwarf2read.c. If there's > an easy way to extend that to match this too, then it may be helpful to > do so. > > Do OpenBSD 3.x toolchains use dwarf2? Or is this out in stabs land? We're using dwarf2 for a while now. > > ptype pmi > > type = int A::** > > (gdb) FAIL: gdb.cp/member-ptr.exp: ptype pmi (A::j) > > It should be "int A::*". Somehow we think we have a pointer to a > member pointer, instead of just a member pointer. That explains most > of the cascading failures for pmi. 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? > > print a.*pmf > > $9 = {int (A *, int)} 0x1c000af6 > > (gdb) PASS: gdb.cp/member-ptr.exp: print a.*pmf > > We get this right... > > > print (a.*pmf)(3) > > $11 = 127 > > (gdb) FAIL: gdb.cp/member-ptr.exp: print (a.*pmf)(3) > > So I'm pretty surprised that we get this wrong. We've somehow called > the wrong function, or called it with a bogus argument / "this" pointer. Isn't it just another cascading error because initializing members through data member pointers fails? Mark P.S. You still need to submit some bug reports for the gdb/NNN's.