public inbox for archer@sourceware.org
 help / color / mirror / Atom feed
From: Roland McGrath <roland@redhat.com>
To: tromey@redhat.com
Cc: Project Archer <archer@sourceware.org>, Jakub Jelinek <jakub@redhat.com>
Subject: Re: Fedora 14 debug proposal
Date: Sun, 13 Jun 2010 10:40:00 -0000	[thread overview]
Message-ID: <20100613104010.6D1174077C@magilla.sf.frob.com> (raw)
In-Reply-To: Tom Tromey's message of  Tuesday, 8 June 2010 14:38:19 -0600 <m3bpbljm4k.fsf@fleche.redhat.com>

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

Is this a magical gdb-internal format, or something that will really be
specified as a known file format?  Since the plan as stated is to
distribute this format in distro packages that will be around forever, the
format details become interesting from a long-term compatibility point of
view, not just as a gdb feature of today.

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

See /usr/lib/rpm/find-debuginfo.sh.  If DWARF compression ever gets
finished, its tools will probably replace most or all of that script.

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

Please do not lump .debug_aranges in with .debug_pub*.  They are
qualitatively different cases.  .debug_aranges is a direct low-level
derivative of the CU DIEs.  The others are made with language-specific
high-level knowledge.

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

libdw uses .debug_aranges and does not fall back to linear search of CUs.
Removing it breaks all existing users that do any kind of lookups by PC
address.

>    I think .debug_pub* are pretty useless.  [...]

I don't doubt that.

>    I can write the gcc patch for this.

For Fedora purposes, dropping .debug_pub* sections could just as well be
done in the stripping stage.  And, I don't think they really cost much
space in the grand scheme of things.  So there is little real motivation to
fiddle gcc at all until after we have completed basically everything else
in the related realms.  (There also isn't really any reason I know of not
to drop .debug_pub* from gcc yesterday if anyone really wants to.)

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

libdw does not yet handle .debug_types.  It of course will, but I wouldn't
like to have a gcc defaults change on any queue until we are quite concrete
with getting all the support in line.

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

It should be, yes.  I don't see any reason that .debug_types and
DW_FORM_ref_sig8 need to survive final linking.  The normal reference
forms are more efficient for consumers to use.  Replacing ref_sig8 forms
with direct ref_addr forms requires that the targets be in .debug_info
rather than .debug_types.  So I'd been imagining that DW_TAG_type_unit
would morph into DW_TAG_compile_unit anyway.  It's still possible that
emitting .debug_types during compilation could speed up the build
process, if plain ld COMDAT handling reduces a lot of duplication before
the brute-force DWARF duplicate-subtree finder has to run.


Thanks,
Roland

  parent reply	other threads:[~2010-06-13 10:40 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-08 20:38 Tom Tromey
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 [this message]
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=20100613104010.6D1174077C@magilla.sf.frob.com \
    --to=roland@redhat.com \
    --cc=archer@sourceware.org \
    --cc=jakub@redhat.com \
    --cc=tromey@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).