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: Thu, 24 Mar 2022 09:01:38 +0100	[thread overview]
Message-ID: <YjwlYjYTlU913mB6@google.com> (raw)
In-Reply-To: <YjwAEy5hY4/yzBSc@squeak.grove.modra.org>

On Thu, Mar 24, 2022 at 03:52:27PM +1030, Alan Modra wrote:
> Huh, I remember looking at this code a while ago and finding it
> confusing.  I think the code would be clearer, and behave the same on
> normal line number info with the following patch:

An interesting question is: Do you want to keep searching through
compilation units once you've found a match with a line number?
Should we go straight to “goto done” then?

Currently, it seems that even if we find a match with line numbers, we
keep searching for a more specific match (range <= min_range) in
different compilation units... but only among compilation units we've
already parsed debug information for. If we have a line number by then,
we stop searching; we only parse new units if we're line-number-less
or have no match at all.

And if we find a match, no matter how bad, in those new units, we accept
it and stop searching, no matter whether we have line numbers or if it's
a more specific match or not. (Is that a correct interpretation?) Your
patch changes the exit-after-already-parsed to also include a match
_without_ line numbers. It's a change, but I don't know if it's
intended. My patch, as a side effect, introduces the more-specific logic
into the second loop, where it wasn't before.

/* Steinar */

  reply	other threads:[~2022-03-24  8: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 [this message]
2022-03-24 23:30         ` Alan Modra
2022-03-25  0:01           ` Steinar H. Gunderson
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=YjwlYjYTlU913mB6@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).