public inbox for archer@sourceware.org
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Roland McGrath <roland@redhat.com>
Cc: Daniel Jacobowitz <drow@false.org>, archer@sourceware.org
Subject: Re: Initial psymtab replacement results
Date: Wed, 16 Dec 2009 19:46:00 -0000	[thread overview]
Message-ID: <m3k4wmk8gp.fsf@fleche.redhat.com> (raw)
In-Reply-To: <20091216185721.52CD1D8@magilla.sf.frob.com> (Roland McGrath's message of "Wed, 16 Dec 2009 10:57:21 -0800 (PST)")

>>>>> "Roland" == Roland McGrath <roland@redhat.com> writes:

Tom> There's also an issue with knowing whether it is actually complete; I
Tom> didn't think of this until relatively recently:
Tom> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42288

Roland> I think we discussed this before and I've forgotten again why
Roland> that issue matters.  In the status quo there is a .debug_aranges
Roland> hunk for each CU from the beginning of the existing of the
Roland> corresponding .debug_info hunk at compile time, and that can
Roland> never be "stripped" except by strip et al that remove
Roland> .debug_info along with it.

Nothing requires a compiler to emit .debug_aranges for a CU.  It is an
optional index, at least by my reading:

    [6.1 Accelerated Access]
    ... a producer of DWARF information may provide...

So, if there is no aranges entry for a given CU, there is no way to tell
whether the CU has no addressable content, or whether the entry was
simply never created.

This is not an issue if you are willing to assume that the user is using
GCC, because AFAIK (modulo the bug we found) GCC always emits this with
-g.

GDB aspires to be more defensive, though.  So, on my current branch, if
GDB notices a missing aranges entry, it reads full symbols for the CU
just in case.  This triggers a number of times in OO.o.

The PR in question is suspended because I told rth that it wasn't clear
we would even be using aranges.

Overall this is fairly minor.  It isn't likely to affect Fedora.  I have
no idea what, if anything, other gdb maintainers might say about it.
Maybe we can just ignore it.

This issue affects .debug_pub* as well.

Tom

  reply	other threads:[~2009-12-16 19:46 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-10 21:54 Tom Tromey
2009-12-11 23:10 ` Tom Tromey
2009-12-11 23:59   ` Daniel Jacobowitz
2009-12-14 22:40     ` Tom Tromey
2009-12-14 23:09       ` Daniel Jacobowitz
2009-12-15 23:39         ` Tom Tromey
2009-12-16  3:01           ` Roland McGrath
2009-12-16 18:20             ` Tom Tromey
2009-12-16 18:57               ` Roland McGrath
2009-12-16 19:46                 ` Tom Tromey [this message]
2009-12-16 19:52                   ` Roland McGrath
2009-12-16 18:11           ` Daniel Jacobowitz
2009-12-16 19:31             ` Tom Tromey
2009-12-23 18:29           ` Tom Tromey
2009-12-23 18:35             ` Daniel Jacobowitz
2009-12-24 17:07             ` Tom Tromey
2010-01-06 23:05               ` Tom Tromey
2009-12-17 16:39         ` Paul Pluzhnikov
2009-12-17 16:53           ` Daniel Jacobowitz
2009-12-17 17:20             ` Paul Pluzhnikov
2009-12-17 18:16               ` Daniel Jacobowitz
2009-12-18 23:58                 ` Tom Tromey
2009-12-21 13:54                   ` Daniel Jacobowitz
2009-12-21 21:29                     ` Tom Tromey
2009-12-15  1:04       ` Roland McGrath
2009-12-15 18:36         ` Tom Tromey

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=m3k4wmk8gp.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=archer@sourceware.org \
    --cc=drow@false.org \
    --cc=roland@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).