From: Wu Zhou <woodzltc@cn.ibm.com>
To: ezannoni@redhat.com
Cc: gdb-patches@sources.redhat.com
Subject: [patch ping] Set TYPE_VPTR_BASETYPE/TYPE_VPTR_FIELDNO of XL C++ virtual class
Date: Wed, 21 Sep 2005 06:57:00 -0000 [thread overview]
Message-ID: <Pine.LNX.4.63.0509211424570.8678@linux.site> (raw)
Hi Elena,
GNU c++ compiler depends on DW_AT_containing_type to represent the type
of virtual base class. But some other c++ compiler don't have this
dependence. IBM's XL c++ compiler is one of them. So while trying to
access the virtual base class of a XL c++ class, gdb will get a NULL
pointer and prone to get into SEGV error.
I posted a patch about five monthes ago to set TYPE_VPTR_BASETYPE and
TYPE_VPTR_FIELDNO of XL C++ virtual class correctly, which could cure this
error. Would you please review this and give your comment? Thanks a lot.
The original patch is at:
http://sourceware.org/ml/gdb-patches/2005-05/msg00655.html
You can also refer to the following appendent:
Index: dwarf2read.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2read.c,v
retrieving revision 1.181
diff -c -p -r1.181 dwarf2read.c
*** dwarf2read.c 9 Mar 2005 06:03:14 -0000 1.181
--- dwarf2read.c 30 May 2005 14:22:29 -0000
*************** read_structure_type (struct die_info *di
*** 3864,3869 ****
--- 3864,3891 ----
TYPE_VPTR_FIELDNO (type) = TYPE_VPTR_FIELDNO (t);
}
}
+ else if (cu->producer
+ && strncmp (cu->producer,
+ "IBM(R) XL C/C++ Advanced Edition", 32) == 0)
+ {
+ /* The IBM XLC compiler does not provide direct indication
+ of the containing type, but the vtable pointer is
+ always named __vfp. */
+
+ int i;
+
+ for (i = TYPE_NFIELDS (type) - 1;
+ i >= TYPE_N_BASECLASSES (type);
+ --i)
+ {
+ if (strcmp (TYPE_FIELD_NAME (type, i), "__vfp") == 0)
+ {
+ TYPE_VPTR_FIELDNO (type) = i;
+ TYPE_VPTR_BASETYPE (type) = type;
+ break;
+ }
+ }
+ }
}
do_cleanups (back_to);
Daniel thought that it is ok, and suggested one alternative fix: teach GDB
not to rely on TYPE_VPTR_FIELDNO and TYPE_VPTR_BASETYPE if the C++ ABI in
use does not require them. But that seems to need more work than this
one. So before working on that idea, I would like to see how do you think
on the above patch. If you accept that, I don't need to work on that
alternative fix. :-)
Thanks a lot in advance for your kind response.
Regards
- Wu Zhou
next reply other threads:[~2005-09-21 6:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-21 6:57 Wu Zhou [this message]
2005-09-29 10:18 ` Wu Zhou
2005-09-29 4:53 Wu Zhou
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.63.0509211424570.8678@linux.site \
--to=woodzltc@cn.ibm.com \
--cc=ezannoni@redhat.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