public inbox for archer@sourceware.org
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Project Archer <archer@sourceware.org>
Cc: Jakub Jelinek <jakub@redhat.com>
Subject: Fedora 14 debug proposal
Date: Tue, 08 Jun 2010 20:38:00 -0000	[thread overview]
Message-ID: <m3bpbljm4k.fsf@fleche.redhat.com> (raw)

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

             reply	other threads:[~2010-06-08 20:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-08 20:38 Tom Tromey [this message]
2010-06-09 13:54 ` Dodji Seketeli
2010-06-09 16:11   ` Tom Tromey
2010-06-11 20:31     ` Tom Tromey
2010-06-14 10:17       ` Jakub Jelinek
2010-06-11 20:39         ` Tom Tromey
2010-06-11 20:33 ` Tom Tromey
2010-06-13 10:40 ` Roland McGrath
2010-06-14 20:06   ` Tom Tromey
2010-06-15 19:46   ` Tom Tromey
2010-06-15 22:26     ` Roland McGrath

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3bpbljm4k.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=archer@sourceware.org \
    --cc=jakub@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).