Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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