update on speedup project

[Tom Tromey <tromey at redhat dot com>]

At the meeting I promised some email about the status of my project
and branch.

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
speedup:

    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
  partial symbol.

  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
  says:

    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.

Tom