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

[Jan Beulich <jbeulich@suse.com>]

On 25.03.2022 00:30, Alan Modra via Binutils wrote:
> 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?

Since I ended up working on that function as well, I did notice another
potentially relevant aspect: The adjustment done back at the time was
only for the case of already processed CUs. The subsequent loop reading
any remaining ones doesn't similarly attempt to find a better match.
IOW the effects of that change can only have been partial anyway.

Jan