This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] dwarf2_physname


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]