public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "Steinar H. Gunderson" <sesse@google.com>
To: Alan Modra <amodra@gmail.com>
Cc: Nick Clifton <nickc@redhat.com>,
	binutils@sourceware.org, sesse@chromium.org
Subject: Re: [PATCH] Add a trie to map quickly from address range to compilation unit.
Date: Fri, 25 Mar 2022 01:01:14 +0100	[thread overview]
Message-ID: <Yj0GSpqi+U0adbDk@google.com> (raw)
In-Reply-To: <Yjz/Ff2AK+KJGqCo@squeak.grove.modra.org>

On Fri, Mar 25, 2022 at 10:00:29AM +1030, Alan Modra wrote:
> This would be reverting commit 240d6706c6a2.  In
> https://sourceware.org/bugzilla/show_bug.cgi?id=15935#c3 I came to the
> conclusion that the pr15935 testcase had bogus debug info and closed
> the bug as invalid.  The reporter apparently opened another bug,
> https://sourceware.org/bugzilla/show_bug.cgi?id=15994 a month later
> that Nick fixed by making _bfd_dwarf2_find_nearest_line do extra work.
> Which of course is unnecessary with good debug info, but in many cases
> we try to make binutils give the best result even with bad input.  I
> don't know the details beyond that.  It might have been that the
> compiler producing the bad debug info was one supported by RedHat.

Thanks for going through the history here. Note that my patch changes
the equation somewhat; as long as the debug info has been parsed for the
CU (I understand that this is done somewhat incrementally?), the cost of
looking through all CUs instead of stopping at the first one is nearly zero.
Generally, we pay a cost proportional to the number of ranges that
overlap with the given 256-byte region which should be very pretty few
in a well-behaved binary, and not a lot even in a really bad one.
(Well, that's not strictly true; if the number of such ranges is fewer
than 8, we could be testing up to 8 ranges. But it's still cheap.)

But of course, if we want to keep parsing debug info from new CUs,
that has a definite cost. But that cost is per-CU, not per lookup,
so if you're looking up lots of addresses, it's “only” startup cost.
Whether this matters depends on the use case, of course.

In any case, I think the decision here should be more clearly
communicated in the source :-) The existing comment saying that we keep
looking is very useful, but the decision to _not_ keep looking into
not-yet-parsed CUs (in some cases only!) is less clearly articulated.

/* Steinar */

  reply	other threads:[~2022-03-25  0:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-21  9:40 Steinar H. Gunderson
2022-03-23 14:14 ` Nick Clifton
2022-03-23 15:53   ` Steinar H. Gunderson
2022-03-23 22:24   ` Steinar H. Gunderson
2022-03-24  5:22     ` Alan Modra
2022-03-24  8:01       ` Steinar H. Gunderson
2022-03-24 23:30         ` Alan Modra
2022-03-25  0:01           ` Steinar H. Gunderson [this message]
2022-03-28 10:19           ` Jan Beulich
2022-03-28 23:47             ` Alan Modra
2022-03-29  6:07               ` Jan Beulich
2022-03-31  6:21                 ` Steinar H. Gunderson
2022-04-03 11:39                   ` Alan Modra
2022-04-04  7:29                     ` Steinar H. Gunderson

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=Yj0GSpqi+U0adbDk@google.com \
    --to=sesse@google.com \
    --cc=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=nickc@redhat.com \
    --cc=sesse@chromium.org \
    /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).