Re: [patch] Add printing of .gdb_index section to readelf

[Tom Tromey <tromey at redhat dot com>]

Mark> IMHO the current documentation is fine, it should just be moved
Mark> to a more easily discoverable location.

Ok.  I will give it a shot.

Tom> There are 3 indices in DWARF. AFAIK .debug_aranges doesn't really have
Tom> problems, except one theoretical one that everybody has agreed to
Tom> ignore. I'm not sure why I didn't just use this instead of putting the
Tom> ranges into .gdb_index; maybe I was too worried about this theoretical
Tom> problem. (Changing this might be a decent way to shrink .gdb_index.)

Mark> What is the theoretical problem?

There is no way to distinguish between a CU that does not have a
corresponding .debug_aranges entry, and a CU that simply has no
addresses to represent.  This is ambiguous because .debug_aranges is an
optional section.

This is semi-pathological, and anyway I think we all agreed to just
ignore it.

Tom> * Names are not canonicalized. To make GDB's symbol tables work
Tom> properly, it has to canonicalize C++ names. Doing this while reading
Tom> .debug_pubnames is too slow. The names in .gdb_index are run through
Tom> the canonicalizer.

Mark> Aha. That is where the language specific part comes in.
Mark> Is what you are after a quick way to get the scoping/parent
Mark> namespaces?

In C++ there are multiple valid ways to write a name.  For GDB's
purposes, though, it is best if (1) there is only one way to write a
name (since GDB has a flat global symbol table -- that is, overloads are
stored according to their full name), and (2) if there is a way to also
canonicalize user input according to the same rule.

Arguably it is better to fix this in GDB by changing how symbols are
stored.

Mark> I'll look that up. I assume this was this thread:
Mark> http://sourceware.org/ml/archer/2009-q3/threads.html#00105

Yeah, also "Initial psymtab replacement results" from December 2009.
And maybe "gdb index performance" from June 2010.

I couldn't quickly find the message where I posted the performance data
using .debug_pub*, sorry.

Tom