Hi Tom,
We could document it elsewhere. Where would you suggest?
I looked or it in the manual (either user or internal): http://sourceware.org/gdb/documentation/
Since the save gdb-index command is described in: http://sourceware.org/gdb/current/onlinedocs/gdb/Index-Files.html
IMHO the current documentation is fine, it should just be moved to a more easily discoverable location.
There are 3 indices in DWARF. AFAIK .debug_aranges doesn't really have problems, except one theoretical one that everybody has agreed to ignore. I'm not sure why I didn't just use this instead of putting the ranges into .gdb_index; maybe I was too worried about this theoretical problem. (Changing this might be a decent way to shrink .gdb_index.)
What is the theoretical problem?
The other indices have these problems, at least from the GDB POV:
- GCC had a number of historical bugs in .debug_pubnames generation.
It did not handle qualified names correctly. Some names were missing.
To me this means it is unreliable -- even if it exists, how would GDB know to trust it?
That is a problem indeed. But since you are (at least currently) relying on "post processing" anyway, we could add a check to dwarflint and somehow mark the file as "complete". This could even be added as a flag in your .gdb_index header ".debug_pubnames: OK". Or we could fixup .debug_pubnames instead of adding a new/duplicate list.
- .debug_pubnames only lists public names. This is insufficient; gdb
users are used to typing `break unique_static_function' at startup. This problem may apply to .debug_pubtypes as well.
OK. That is clearly a deficiency of the current "pub" indexes. Maybe add/propose a standardized .debug_priv variant?
- Names are not canonicalized. To make GDB's symbol tables work
properly, it has to canonicalize C++ names. Doing this while reading .debug_pubnames is too slow. The names in .gdb_index are run through the canonicalizer.
Aha. That is where the language specific part comes in. Is what you are after a quick way to get the scoping/parent namespaces?
IIRC, I did some tests where I:
- Changed GCC to generate .debug_priv{names,types} as well
- Disabled canonicalization in GDB
... and these sections were still too slow to read. All the data is somewhere in the Archer archives.
I'll look that up. I assume this was this thread: http://sourceware.org/ml/archer/2009-q3/threads.html#00105
Anyway, the nice thing about .gdb_index is we can just mmap it.
Maybe I was too hasty; the indices could probably be read in a background thread or something like that. I don't think I seriously considered this at the time.
The reason I stumbled upon this is that I was looking for other ways to compress the debuginfo on fedora. And compared to f14 the packages on f15 are about 10% bigger because of this extra index. If it is part of the actual .debug file then it might be nice to make other consumers also use it (or split it if it really is only for gdb private usage).
Cheers,
Mark