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

[Tom Tromey <tromey at redhat dot com>]

>>>>> "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