From: Daniel Jacobowitz <drow@false.org>
To: Keith Seitz <keiths@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFA] dwarf2_physname
Date: Mon, 14 Sep 2009 22:48:00 -0000 [thread overview]
Message-ID: <20090914224754.GA7012@caradoc.them.org> (raw)
In-Reply-To: <4AAE8DDB.3060005@redhat.com>
On Mon, Sep 14, 2009 at 11:39:23AM -0700, Keith Seitz wrote:
> I've spent the last 1.5 weeks investigating proprietary compilers,
> and I can only assume that no one seriously ever runs gdb's test
> suite on either RealView or ICC. CVS HEAD shows almost 1,000 test
> failures on each compiler.
Hi Keith,
I'm really sorry about the rathole. I expected you'd just ask me to
do it... you're correct that you are going to get a lot of failures
with RealView. I have patches for some of the worst, both in
testsuite patterns and in GDB proper. Part of the reason I haven't
posted them yet, though, is this exact issue - one of the patches in
our tree for RealView support is the stone-age ancestor of your
patches :-)
ICC, though, I'm pretty surprised; we get bug reports about people
using ICC once in a while, and I thought someone had tested it...
Now that you've gone to the trouble, though, let's make the most of
your work. Could I persuade you to put the wrappers you needed and
where to get appropriate compilers onto the GDB wiki?
> ARM RealView: My expr-cumulative branch introduces three regression
> failures -- two of them in C++ tests. However, it also allows
> RealView to pass over two hundred previously failing or erroring C++
> tests. I can provide diffs. On my "realcpp" test, RealView fails
> almost all of the template tests. This is because RealView relies on
> DW_AT_template_* attributes which gdb does not yet know about. [This
> will likely be my next task.]
This is excellent news.
Some things will blow up in new and exciting ways when we start
relying on the template arguments emitted by the compiler; they're
incomplete for some of the nasty examples I tried. But if we can
debug normal-ish templates, we've made great progress.
> <2><101>: Abbrev Number: 4 (DW_TAG_formal_parameter)
> <102> DW_AT_type : <0x147>
> <106> DW_AT_artificial : 1
> <107> DW_AT_name : this
> <10c> DW_AT_location : 2 byte block: 75 8 (DW_OP_breg5: 8)
> <3><134>: Abbrev Number: 7 (DW_TAG_formal_parameter)
> <135> DW_AT_type : <0x147>
> <139> DW_AT_name : $01
> Here you can see that DIE <134> is NOT marked artificial.
> Additionally, its DW_AT_name conflicts with the one previously
> listed, which I think is playing pretty loose with the standard (and
> certainly makes life difficult for the debugger). I did not even
> bother with my realcpp tests on this compiler.
Ouch. Though, why does this make life difficult for the debugger?
The problem of THIS not being artificial I've seen before - I think
RealView has the same problem; I may have a patch to work around it -
but I'm not sure why we care about the name of the parameter in the
declaration.
> Is there anything else you want me to investigate?
No, I'm happy. Is this patch still current? If so, I'll review it
tonight.
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2009-09-14 22:48 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-31 22:51 Keith Seitz
2009-08-31 23:10 ` Michael Eager
2009-08-31 23:23 ` Keith Seitz
2009-08-31 23:35 ` Michael Eager
2009-09-01 22:11 ` Daniel Jacobowitz
2009-09-01 22:27 ` Daniel Jacobowitz
2009-09-01 23:18 ` Michael Eager
2009-09-01 23:37 ` Daniel Jacobowitz
2009-09-02 1:12 ` Michael Eager
2009-09-01 23:26 ` Keith Seitz
2009-09-01 23:42 ` Daniel Jacobowitz
2009-09-14 18:39 ` Keith Seitz
2009-09-14 22:48 ` Daniel Jacobowitz [this message]
2009-09-14 23:56 ` Keith Seitz
2009-09-15 13:32 ` Daniel Jacobowitz
2009-09-15 15:53 ` Keith Seitz
2009-09-15 16:12 ` Daniel Jacobowitz
2009-09-16 20:27 ` Keith Seitz
2009-09-18 22:34 ` Tom Tromey
[not found] ` <m37hwjy2tl.fsf@fleche.redhat.com>
2009-09-01 0:06 ` Michael Eager
2009-09-01 21:27 ` Tom Tromey
2009-09-01 22:10 ` Keith Seitz
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=20090914224754.GA7012@caradoc.them.org \
--to=drow@false.org \
--cc=gdb-patches@sourceware.org \
--cc=keiths@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