[Bug binutils/30150] addr2line returns wrong results after several thousands of requests in pipe mode

[nickc at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30150

--- Comment #27 from Nick Clifton <nickc at redhat dot com> ---
(In reply to Alan Modra from comment #26)
Hi Alan,

> Tidied patch

Thanks - that is definitely a better version of the patch.  I am going to check
it in shortly.


> Note that I haven't looked into why it is also necessary to test line_offset
> so this patch is *not* a replacement for Nick's patch.

I think that this might be a bug/mis-feature in decode_line_info().  

I had assumed that this code:

  if (unit->line_offset == 0 && file->line_table)
    return file->line_table;

meant that the function was intended to be able to be called multiple times for
a given CU, each time loading a different line info table at a different offset
into the .debug_line section.  And the test was there only to short-cut the
case where the first line info table was being loaded again.  I also, naively,
assumed that the line info tables would be chained together, or possibly stored
separately somewhere.  

But upon inspection I found that decode_line_info() is only called from one
place - comp_unit_maybe_decode_line_info () - and then only if a table has not
already been loaded.  So the whole "unit->line_offset == 0 && file->line_table"
test appears to be spurious and could be dropped.

Anyway, the point is, I do not see any need to test line_offset in
comp_unit_may_contain_address() so I have gone ahead and applied your version
of the patch with only one small change - I replaced the do..while loop with a
for.. loop as this makes the code cleaner.

> I also don't want to take over the bug..

Darn - I guess that I will keep it then. :-)

Cheers
  Nick

-- 
You are receiving this mail because:
You are on the CC list for the bug.