Re: [PATCH] Add a trie to map quickly from address range to compilation unit.

[Alan Modra <amodra@gmail.com>]

On Thu, Mar 24, 2022 at 09:01:38AM +0100, Steinar H. Gunderson wrote:
> 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?

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.

Now we have pr28592 and others complaining that objdump or addr2line
have significantly slowed.  Given that pr15935 dates back to 2013, I
would presume that people have moved on from whatever broken compiler
produced bad line info, and that we should indeed revert commit
240d6706c6a2.  Nick?

-- 
Alan Modra
Australia Development Lab, IBM