This is the mail archive of the
mailing list for the Archer project.
update on speedup project
- From: Tom Tromey <tromey at redhat dot com>
- To: Project Archer <archer at sourceware dot org>
- Date: Fri, 05 Sep 2008 12:45:27 -0600
- Subject: update on speedup project
- Reply-to: Tom Tromey <tromey at redhat dot com>
At the meeting I promised some email about the status of my project
I looked more seriously into making pubnames work, to speed up
operations like attaching to a program with many shared libraries.
I implemented a rough draft of this -- it does not completely work,
but it reads what data does exist. This is good for a reasonable
before 31.40user 2.67system 1:03.69elapsed
after 13.01user 2.62system 0:45.91elapsed
(Note that this is still reading the debug_info section ... the goal
is not to read it at all, but I didn't implement that. So, we could
probably do better.)
However, there are some drawbacks to pubnames:
* They don't encode all the info that gdb wants. This is a gdb
limitation, IMO. In particular if we just want to read pubnames,
pubtypes, and aranges, we have no way to set the location of a
I think we could introduce a new LOC_* constant that calls back into
the dwarf reader to get this info. There are some cases here I am
not sure about.
* The dwarf spec is a bit strange on the topic of qualification. It
In the case of the name of a function member or static data member
of a C++ structure, class or union, the name presented in the
.debug_pubnames section is not the simple name given by the
DW_AT_name attribute of the referenced debugging entry, but rather
the fully qualified name of the data or function member.
This omits namespaces, which is weird and (IMO) not useful.
* pubtypes does not encode information about whether a name is a
typedef or a struct or union tag. We could read the DIE, of course,
but the goal of this approach is not to read debug_info. So, this
is kind of ugly.
* Supposedly, no existing debugger actually uses pubnames.
So, now I am quite skeptical that this can be made to work in a
reasonable way. I wish I'd dug a bit deeper during the estimation
phase -- whoops. I'm also even contemplating suggesting that GCC stop
emitting the pubnames section :-)
Now I am looking at something Apple implemented: defer reading of
shared library symbols until they are actually needed. I think this
may be a simpler way to achieve the same goal of speeding up "attach".
I can push the branch I have with its various hacks, if anybody is
curious. Otherwise I probably will not bother.