From: Manoj Iyer <manjo@austin.ibm.com>
To: gdb-patches@sources.redhat.com
Subject: [RFC] GDB prints internal error with C++ application produced by XLC.
Date: Thu, 14 Apr 2005 01:38:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.58.0504132107081.11095@lazy> (raw)
I submitted this patch to the list almost a month ago, I got good feed
back from other maintainers/developers (Daniel, Joel) but I have not got
any feed back/acceptance from the Dwarf maintainer, I have pinged the
dwarf maintainer numerous times for a response. Is there any super
maintainer who can review & approve my patch? Or shall I just commit it if
I dont get any response saying otherwise in 2 weeks? Please see below for
the details of this patch...
GDB prints internal error with C++ application produced by XLC.
=============== Test Case ========================
/* This testcase written by Lu Yang <luyang@ca.ibm.com> */
template<class T> class X;
template <class T>
class Y {
friend class X<T>;
public:
T f();
};
template <class T>
class X {
public:
friend inline T Y<T>::f();
static T a;
};
template <class T> inline T Y<T>::f() {return X<T>::a;}
template<> int X<int>::a =5;
int main() {
Y<int> obj;
if (obj.f() == 5)
return 55;
else
return 66;
}
====================== End Test Case =====================
When the above testcase is compiled -m64 by XLC, GDB generates an internal
error:
"internal-error: could not find partial DIE in cache"
GCC creates a DWARF TAG for "a" as DW_TAG_variable and XLC creates
DW_TAG_member. GDB throws away TAGS that it find as uninteresting. In this
case DW_TAG_member. (this is in dwarf2read.c function:
load_partial_dies(). )
GCC created DWARF information
-------------------------------
<2><102>: Abbrev Number: 13 (DW_TAG_variable)
DW_AT_name : a
DW_AT_decl_file : 1
DW_AT_decl_line : 13
DW_AT_MIPS_linkage_name: _ZN1XIiE1aE
DW_AT_type : <d5>
DW_AT_external : 1
DW_AT_declaration : 1
XLC created DWARF information
------------------------------
<2><96>: Abbrev Number: 5 (DW_TAG_member)
DW_AT_name : a
DW_AT_accessibility: 1 (public)
DW_AT_declaration : 1
DW_AT_type : <78>
GCC in this case is producing wrong information. According to DWARF
spec:
" If the variable entry represents the defining declaration for a C++
static data member of a structure, class or union, the entry has a
DW_AT_specification attribute, whose value is a reference to the debugging
information entry representing the declaration of this data member. The
referenced entry has the tag DW_TAG_member and will be a child of some
class, structure or union type entry. "
So I think GDB needs to handle the DW_TAG_member and not skip it, when
dealing with C++.
Here is a patch to GDB that will fix this problem
================ Patch to gdb ==================
2005-02-15 Manoj Iyer <manjo@austin.ibm.com>
* dwarf2read.c (load_partial_dies): Save DIE with tag
DW_TAG_member, generated by XLC when compiling C++ application.
diff -Naur ./old/src/gdb/dwarf2read.c ./new/src/gdb/dwarf2read.c
--- ./old/src/gdb/dwarf2read.c 2005-02-15 11:13:05.000000000 -0600
+++ ./new/src/gdb/dwarf2read.c 2005-02-22 10:24:08.000000000 -0600
@@ -5167,7 +5167,8 @@
&& abbrev->tag != DW_TAG_enumerator
&& abbrev->tag != DW_TAG_subprogram
&& abbrev->tag != DW_TAG_variable
- && abbrev->tag != DW_TAG_namespace)
+ && abbrev->tag != DW_TAG_namespace
+ && abbrev->tag != DW_TAG_member)
{
/* Otherwise we skip to the next sibling, if any. */
info_ptr = skip_one_die (info_ptr + bytes_read, abbrev, cu);
========================= END PATCH ======================
ok to commit? Or If I dont get any negative response within 2 weeks or so
shall I commit it anyway?
Thanks
-----
manjo
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Cogito ergo sum +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
next reply other threads:[~2005-04-14 1:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-14 1:38 Manoj Iyer [this message]
2005-04-14 3:08 ` Daniel Jacobowitz
2005-04-14 3:09 ` Daniel Jacobowitz
2005-04-14 16:15 ` Manoj Iyer
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=Pine.LNX.4.58.0504132107081.11095@lazy \
--to=manjo@austin.ibm.com \
--cc=gdb-patches@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