From: woodzltc@us.ibm.com
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: about how to add support to new c++ compiler in GDB
Date: Thu, 28 Apr 2005 06:34:00 -0000 [thread overview]
Message-ID: <1114670047.427083df114fb@imap.linux.ibm.com> (raw)
> You can find the patch, against current CVS GDB, at:
> http://return.false.org/~drow/gdb/combined-rvct-patches.diff
Got it, a really huge one. :-)
> You should give these a try with xlc++ and see if they help. If not,
> we'll need to discuss the differences in xlc output.
>
I just had a try. And it did help. No SEGV error any more. Followed is the
summary report against xlc++(I only run the testcases under gdb.cp directory):
# of expected passes 1514
# of unexpected failures 264
# of unexpected successes 1
# of known failures 29
# of unresolved testcases 2
I had some look at these failure report. Quite a lot of them are contributed by
"__vfp", which is the same as "_vptr.CLASSNAME". GDB treat it as a normal class
member. The debuginfo for "__vfp" is like this:
<2><36a>: Abbrev Number: 17 (DW_TAG_member)
DW_AT_name : __vfp
DW_AT_accessibility: 1 (public)
DW_AT_artificial : 1
DW_AT_data_member_location: 2 byte block: 23 0 (DW_OP_plus_uconst: 0)
DW_AT_type : <348>
<1><348>: Abbrev Number: 10 (DW_TAG_pointer_type)
DW_AT_address_class: 0
DW_AT_type : <30c>
<1><30c>: Abbrev Number: 16 (DW_TAG_union_type)
DW_AT_sibling : <348>
DW_AT_name : __vftTypeGCCV3
DW_AT_byte_size : 4
DW_AT_artificial : 1
<2><322>: Abbrev Number: 17 (DW_TAG_member)
DW_AT_name : __faddr
DW_AT_accessibility: 1 (public)
DW_AT_artificial : 1
DW_AT_data_member_location: 2 byte block: 23 0 (DW_OP_plus_uconst: 0)
DW_AT_type : <2ff>
<2><334>: Abbrev Number: 17 (DW_TAG_member)
DW_AT_name : __offset
DW_AT_accessibility: 1 (public)
DW_AT_artificial : 1
DW_AT_data_member_location: 2 byte block: 23 0 (DW_OP_plus_uconst: 0)
DW_AT_type : <305>
with which GDB will interpret as:
__vftTypeGCCV3 *__vfp;
Would you like to have a look at gdb.log. I could post that if you prefer.
Thanks
- Wu Zhou
next reply other threads:[~2005-04-28 6:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-28 6:34 woodzltc [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-05-09 12:42 Wu Zhou
2005-04-26 2:54 Wu Zhou
2005-04-26 3:18 ` Daniel Jacobowitz
2005-04-26 9:53 ` Wu Zhou
2005-04-26 13:20 ` Daniel Jacobowitz
2005-04-27 20:09 ` Daniel Jacobowitz
[not found] ` <019101c54bc9$20360cd0$4186b509@ibmcsdl9m89c83>
[not found] ` <20050428131902.GB29277@nevyn.them.org>
2005-04-29 2:37 ` Wu Zhou
2005-04-29 7:28 ` Wu Zhou
2005-04-29 13:10 ` 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=1114670047.427083df114fb@imap.linux.ibm.com \
--to=woodzltc@us.ibm.com \
--cc=drow@false.org \
--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