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