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.
