Re: [RFA 2/4] dwarf2_physname

[Keith Seitz <keiths@redhat.com>]

On 11/20/2009 02:09 PM, Daniel Jacobowitz wrote:

> I am generally opposed to committing known regressions.  If there are
> supporting patches we need to get in first, let's do that; if there
> are tests we decide to break, let's XFAIL or KFAIL them.  That's the
> only way we can make the testsuite more useful.

Sami has a follow-on patch that he could submit to fix all of these 
tests (they all pass on archer-keiths-expr-cumulative). Perhaps it would 
be acceptable for Sami to submit that patchset when/if this patch is 
accepted? [His patches rely on this patchset.]

> The related regressions, just with arm-none-eabi GCC and the default
> multilib:

I'm building an arm-elf toolchain now, and I will run it through testing.

> PASS ->  FAIL: default/gdb.sum:gdb.base/code-expr.exp: (@code signed long)
> PASS ->  FAIL: default/gdb.sum:gdb.base/code-expr.exp: (@data signed long)
> PASS ->  FAIL: default/gdb.sum:gdb.base/code-expr.exp: (signed long @code)
> PASS ->  FAIL: default/gdb.sum:gdb.base/code-expr.exp: (signed long @data)
> PASS ->  FAIL: default/gdb.sum:gdb.base/cvexpr.exp: (const signed long)
> PASS ->  FAIL: default/gdb.sum:gdb.base/cvexpr.exp: (signed long const)
> PASS ->  FAIL: default/gdb.sum:gdb.base/cvexpr.exp: (signed long volatile)
> PASS ->  FAIL: default/gdb.sum:gdb.base/cvexpr.exp: (volatile signed long)
> PASS ->  FAIL: default/gdb.sum:gdb.cp/exception.exp: backtrace after first catch
> PASS ->  FAIL: default/gdb.sum:gdb.cp/exception.exp: backtrace after first throw
> PASS ->  FAIL: default/gdb.sum:gdb.cp/exception.exp: backtrace after second catch
> PASS ->  FAIL: default/gdb.sum:gdb.cp/exception.exp: backtrace after second throw

Don't know about the above failures just yet, but...

> PASS ->  FAIL: default/gdb.sum:gdb.cp/namespace.exp: print X
> PASS ->  FAIL: default/gdb.sum:gdb.cp/namespace.exp: print cX

These are the two regressions that are addressed by Sami's (unsubmitted) 
patch.

> I'm going to skip the RealView regressions; those I'm willing to
> handle in followups.  Most template tests still fail with RealView.
> Some tests from namespace.exp improved, others regressed.

I think we discussed it earlier, but to be clear: RealView will 
demonstrate problems with templates, since it relies on 
DW_TAG_template_{value,type}_parameter, which gdb does not yet 
understand. [I've played with it a bit, but value parameters are *tough* 
on dwarf2_physname.]

> Any idea what the above failures might be?  I can send you logs
> offlist, they're large.

Yes, send the to me at this account.

>> Some warnings are in order. First, this is probably going to really
>> slow down large C++ applications, because we no longer use
>> DW_AT_MIPS_linkage_name as generated from the compiler. We
>> essentially build this name during DIE reading.
>
> We need to quantify the impact on a couple of C++ code bases, I think.

Indeed. I ran some contrived speed tests a long time ago, but I never 
really felt that the adequately represented reality. [I believe they 
were the equivalent of running "file XXX; info func".]

We did show a slowdown on OO.o, but I don't recall the exact numbers 
right now.

If we can define a suitable test procedure for this, I would be happy to 
produce some comparisons.

Keith