This is the mail archive of the
mailing list for the Archer project.
Re: [RFC] Proposal for a new DWARF name index section
>>>>> "Daniel" == Daniel Jacobowitz <firstname.lastname@example.org> writes:
Daniel> Well, as long as I'm not the one who has to convert the C++ demangler
Daniel> into a specification, I guess it's not totally crazy. I still think
Daniel> this makes more sense as an internal cache, though, because it's so
Daniel> tied to the implementation of both the compiler and debugger. And
Daniel> the canonicalization isn't cheap, and doesn't match GCC's internal
Daniel> representation of the names; this would slow down GCC to speed up
I do think that slowing down the compiler to speed up the debugger would
be the wrong tradeoff. I was hoping we could get this for free in the
compiler, or nearly so, but now I unfortunately see that I was confused
on that point :-(. We could pick a representation close to what gcc
already emits -- but then that overly constrains gcc in the future.
Caching is interesting but it comes with other problems. We have to
manage the cache somehow. And, the cache would not be useful when an
object changes. So, I'd prefer a direct approach, if one can be made to
The index is still an improvement even if we have to do canonicalization
Some initial numbers:
warm cache cold cache
without canonicalization: ~0.5 sec 5 sec
gdb does canonicalization: ~1.7 sec 6 sec
gdb cvs head: ~2.4 sec 10 sec
There's a fair amount of noise in the warm cache numbers, I'd say +/-
This is timing "gdb -batch" on a smallish (80 KLOC) C++ program. I
still haven't tried my big tests, I'm still working on setting those up.
I also still haven't tried the pubnames/pubtypes index.
I guess canonicalization is not terrible -- I definitely notice it when
the cache is warm, but with a cold cache it doesn't matter.