From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: drow@false.org
Cc: gdb-patches@sourceware.org
Subject: Re: [ob] Adjust member pointer test for g++ 3.3
Date: Sun, 28 Jan 2007 15:40:00 -0000 [thread overview]
Message-ID: <200701281539.l0SFdxiq013153@brahms.sibelius.xs4all.nl> (raw)
In-Reply-To: <20070112230803.GB7039@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 12 Jan 2007 18:08:03 -0500)
> Date: Fri, 12 Jan 2007 18:08:03 -0500
> From: Daniel Jacobowitz <drow@false.org>
>
> 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 <A::bar(int)>
> > (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.
next prev parent reply other threads:[~2007-01-28 15:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-12 20:17 Daniel Jacobowitz
2007-01-12 21:50 ` Mark Kettenis
2007-01-12 23:08 ` Daniel Jacobowitz
2007-01-28 15:40 ` Mark Kettenis [this message]
2007-01-28 17:11 ` Daniel Jacobowitz
2007-01-28 17:50 ` Mark Kettenis
2007-01-28 17:52 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200701281539.l0SFdxiq013153@brahms.sibelius.xs4all.nl \
--to=mark.kettenis@xs4all.nl \
--cc=drow@false.org \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox