This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA 2/4] dwarf2_physname
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