This is the mail archive of the
mailing list for the Archer project.
Initial psymtab replacement results
- From: Tom Tromey <tromey at redhat dot com>
- To: Project Archer <archer at sourceware dot org>
- Date: Thu, 10 Dec 2009 14:54:09 -0700
- Subject: Initial psymtab replacement results
- Reply-to: tromey at redhat dot com
This week I added a new command to gdb to let me dump the
.debug_gnu_index section from psymtabs. This way I was able to
instrument the OO.o .debug files without recompiling the world. (If you
want to try this out, let me know. It required some obscure and
probably bogus BFD hacks to make objcopy not barf when splicing the new
section into the .debug files.)
The summary is, this approach seems solid.
Here are timings for a simple "attach" to a running OO.o writer, with
full debuginfo installed. These are representative figures, but there
is some noise.
CVS 26.05user 2.53system 1:08.86elapsed
F11 5.29user 1.09system 0:22.01elapsed
(The F11 gdb includes the delayed-symfile branch.)
Branch 10.64user 0.81system 0:22.63elapsed
Threaded 11.26user 0.87system 0:19.16elapsed
I can shave another 5 seconds off the new branch by assuming that the
.debug_gnu_index section has canonicalized C++ names. This is
significant, but I think it isn't a deal-breaker.
I don't have an explanation for why reading the index in a background
thread isn't faster than the above. I didn't look into it yet.
The other test is "thread apply all bt full". This requires a lot of
symbol reading and is the bane of the delayed-symfile branch. These
numbers come from "maint time 1" in gdb.
I didn't time this with the threaded branch but I would expect numbers
similar to the branch. The threading only helps hide reading the index,
Future work I'm planning on this branch:
* Test out using pubnames + pubtypes instead of the new section.
I remain skeptical about this but it seems important to be sure.
* Fix the remaining bugs. I still haven't implemented the needed Ada
* Change gdb to an "expand first" model. Right now it will search
symtabs and only then expand psymtabs looking for a match. This
yields inconsistent behavior, depending on what was already read.
This task would change gdb to expand matching psymtabs (or CUs) first,
then do symtab searching. I may do this as a completely separate
change (I can't remember offhand why I thought I needed this change
for this particular project).
* Investigate the threading stuff some more. This is the lowest
Your comments are welcome.