Re: [RFA 2/4] dwarf2_physname

[Keith Seitz <keiths at redhat dot com>]

I apologize for the delay... It's been a week of holidays and debugging...

On 11/20/2009 02:09 PM, Daniel Jacobowitz wrote:
> The related regressions, just with arm-none-eabi GCC and the default
> multilib:
>
> 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)

I've tracked this down to a misfeature I introduced to strcmp_iw to deal 
with "const" and "volatile". I've removed that, since I don't think that 
is the proper way to do this anymore. These tests now all pass. [I am 
also testing arm-eabi with the default multilib on the simulator.]

> 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

These are failing because the fully qualified name of 
"__cxxabiv1::__cxa_throw" is being shown in the backtraces instead of 
just "__cxa_throw".

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

I think we've already established that these are fixed by Sami's 
outstanding patch (under review).

> > 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.

Yeah, this is *really* bad. Really, really bad. But this was just a an 
attempt at "making it work." Now comes the "make it faster" part. I have 
a few ideas about redundant calls and whatnot, but it will undoubtedly 
take some real effort and refactoring to really make the best of this.

I'm working on some performance numbers now with OpenOffice.org Writer 
as Tom suggested. I'll follow up on this later in this thread when I 
have some more data collected.

Keith