Fedora 14 debug proposal

[Tom Tromey]

Hi all.

This week I want to file a Fedora 14 feature proposal touching on
debuginfo.  I thought we could discuss it here first.

The proposal has 2 or maybe 3 parts.

1. Generate index files for the separate .debug files.  This involves
   running gdb to dump the index, something like:

   cd $dir
   gdb --batch-silent -ex 'maintenance save-gnu-index .' whatever.debug

   The generated index files are architecture-neutral, if it matters.

   The point of this change is that it makes gdb startup much, much
   faster.  The indices can be mapped directly and make both by-name and
   by-address lookups very fast.

   I think this should help things like ABRT, plus of course anybody who
   wants to debug into any library we ship.

   I don't know where the debuginfo stripping is done right now, but
   that seems like the best place to run this script.

   These gdb changes aren't upstream yet.  I wanted to get Fedora buy-in
   before dealing with that.

2. Change GCC so that it no longer emits .debug_aranges,
   .debug_pubnames, and .debug_pubtypes.

   From what I can tell, no program uses these sections.  They just
   waste space.

   Well... Fedora gdb does use .debug_aranges, but that use is replaced
   by the index.  .debug_aranges is a reasonable-enough section; it is
   just that we really also need by-name indices to get good
   performance, and having the whole index be mmap()able gives better
   startup performance.

   I think .debug_pub* are pretty useless.  GCC didn't even generate
   pubtypes for years, and it had a lot of pubnames bugs... maybe it
   still does.  What this means is that we can't really make gdb rely on
   them.  Also, based on earlier experiments, reading these sections is
   actually still too slow.  The index is better.

   I can write the gcc patch for this.

3. If we are shipping GCC 4.5 in F14, I think we should enable the
   .debug_types stuff by default.  This will shrink debuginfo and it
   makes gdb use less memory.

   This one is optional, in particular I assume it will be subsumed by
   the other DWARF compression work.

Tom