From: Kris Warkentin <kewarken@qnx.com>
To: gdb@sources.redhat.com
Subject: gdb crash when printing C++ class
Date: Fri, 10 Dec 2004 20:00:00 -0000 [thread overview]
Message-ID: <41BA0117.40407@qnx.com> (raw)
Some background:
I'm using Intel's icc compiler with Dinkum C++ headers. I have a
feeling that there is something wrong with the way the debug info is
being generated but I want to understand the issue a bit better before I
send it off to them.
In gnuv3_baseclass_offset there is a section of code described by this
comment:
/* We're now looking for the cur_base_offset'th entry (negative index)
in the vcall_and_vbase_offsets array. We used to cast the object to
its TYPE_VPTR_BASETYPE, and reference the vtable as TYPE_VPTR_FIELDNO;
however, that cast can not be done without calling baseclass_offset
again
if the TYPE_VPTR_BASETYPE is a virtual base class, as described in the
v3 C++ ABI Section 2.4.I.2.b. Fortunately the ABI guarantees that the
vtable pointer will be located at the beginning of the object, so
we can
bypass the casting. Verify that the TYPE_VPTR_FIELDNO is in fact
at the
start of whichever baseclass it resides in, as a sanity measure - iff
we have debugging information for that baseclass. */
vbasetype = TYPE_VPTR_BASETYPE (type);
if (TYPE_VPTR_FIELDNO (vbasetype) < 0)
fill_in_vptr_fieldno (vbasetype);
When I try to print an ostream variable, gdb crashes because vbasetype
is dereferenced when type->main_type->vptr_basetype is null. In fact,
TYPE_VPTR_FIELDNO(type) is -1 so as one of my tests, I tried calling
fill_in_vptr_fieldno(type) but that didn't fill it in.
As a workaround to prevent the crash, I just return -1 if
TYPE_VPTR_BASETYPE(type) is null and then I get something like this:
10 ostream foo;
(gdb) p foo
$1 = {
<std::basic_ios<char, std::char_traits<char> >> = <invalid address>,
members of std::ostream:
_vptr.basic_ostream<char, std::char_traits<char> > = void
}
Using gcc with very similar headers, I get much nicer output:
10 ostream foo;
(gdb) p foo
$6 = {
<std::basic_ios<char, std::char_traits<char> >> = {
<> = {<No data fields>},
members of std::basic_ios<char, std::char_traits<char> >:
_Mystrbuf = 0x0,
_Tiestr = 0x0,
_Fillch = 32 ' '
},
members of std::ostream:
_vptr.basic_ostream = 0x804f38c
}
Where was the vptr_basetype set up in the first place? Since type
claims to have a baseclass, logically the baseclass pointer shouldn't be
void so I'm assuming it just didn't get filled in somewhere. Can anyone
give me any hints on how to determine if Intel's debug info is off?
cheers,
Kris
next reply other threads:[~2004-12-10 20:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-10 20:00 Kris Warkentin [this message]
2004-12-10 20:21 ` Daniel Jacobowitz
2004-12-10 21:44 ` Kris Warkentin
[not found] ` <41BA1487.8030302@qnx.com>
2004-12-10 21:46 ` 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=41BA0117.40407@qnx.com \
--to=kewarken@qnx.com \
--cc=gdb@sources.redhat.com \
/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