Re: [RFA 2/4] dwarf2_physname

Keith Seitz
2009-11-23T16:52:33Z

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