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
next 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).