This is the mail archive of the
mailing list for the Archer project.
shared library scalability estimate
- From: Tom Tromey <tromey at redhat dot com>
- To: Project Archer <archer at sourceware dot org>
- Date: Mon, 18 Aug 2008 20:00:08 -0600
- Subject: shared library scalability estimate
- Reply-to: Tom Tromey <tromey at redhat dot com>
The goal here is to speed up gdb when presented with an inferior that
has many shared libraries. Most of the history of the research is on
the list, so I won't repeat it here.
Implement debug_pubnames, debug_pubtypes, and debug_aranges support
in the gdb dwarf reader.
Benchmark before and after.
Fix whatever fallout there is.
Optionally, investigate some of the other speed improvements
mentioned earlier. (We suspect these won't help much since they
primarily impact CPU time.)
Using debug_pubnames would mean a user-visible change in gdb. It
isn't clear how annoying this would be. So, some experimentation
here would be needed.
debug_pubtypes is only generated on Darwin. We have to fix this.
If we want no user-visible changes, then we have to either modify
GCC to put more names into debug_pubnames, or we have to add a new
section, e.g., debug_privnames.
Neither of these is hard, though I assume that the latter task would
require some negotiation.
I don't think this goal affects MI.
1 month for the base implementation. The reader code is relatively
isolated. The required GCC change is not difficult. (I think this
is probably smaller than one month, actually, but as I said, I think
1 month granularity is fine for now.)
If we need private names, add another month, to account for
negotiating which approach is best and then implementing it. Again,
this is probably overshooting.
I didn't include any optional work here, since I assume we won't be
doing it. We can revisit this if need be.