"Mark" == Mark Wielaard mjw@redhat.com writes:
Mark> Do you think it makes sense to support printing this format, or will you Mark> be arbitrarily changing it from time to time? Having it more prominently Mark> documented would be nice.
We do change it from time to time.
We could document it elsewhere. Where would you suggest?
Mark> It looks to me we would like to support it for other tools, or at least Mark> figure out what the deficiencies were with the other dwarf indexes so we Mark> can improve them to make them more useful to other dwarf consumers.
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.)
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?
* .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.
* 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.
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.
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.
A more "end-to-end" solution would be nice. What I mean by this is that right now the index generation is a separate step, and it involves running GDB, so for daily development it is basically not worth doing. It is only worthwhile in the RPM case. If instead the compiler emitting indices that were then somehow more usable (e.g., linker makes the hash table), it would be better. AFAIK nobody is working on this.
We've also discussed proposing this as a DWARF standard. However, DWARF is hard to work with, and writing this up as a standard would be a pain, mostly due to having to explain the details of name canonicalization. I suppose we could revisit this.
Tom