This is the mail archive of the mailing list for the Archer project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Initial psymtab replacement results

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.

GDB        Time
===        ===================================
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.

GDB        Time
===        =========
CVS         1.824723
F11        27.235860
Branch      1.695742

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,
nothing else.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]