[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 #19 from Nick Clifton <nickc at redhat dot com> ---
The problem, I think, is that the vmlinux file contains DWARF CUs that
have both address ranges specified via the DW_AT_low_pc, DW_AT_high_pc
and/or DW_AT_ranges attributes *and* implicitly via the table in the
.debug_line section associated with the CU.

When the _bfd_dwarf2_find_nearest_line_with_alt() function is called
it loads the CUs in turn, looking for any that cover the desired
address.  But this coverage is determined only from the addresses in
the attributes found in the CU, not from any found in its associated
line table.

If the CU is a likely candidate, then its line table is loaded as part
of the checks to make sure that a match has been found.  This can then
extend the address range covered by the CU.

So if addr2line is asked to decode an address that is outside of any
CU based solely upon the address attributes inside the CU's then it
will display "??:0".  But if a later address decoding does match a CU
then its line table will be loaded, extending the address range
covered by the CU, and hence a second attempt to decode the original
address will now display the correct desired information.

As an aside, it may be that the problematic addresses and associated
symbols are all associated with hand-written assembler code, rather
than high level source code.  Although I have not confirmed this.

The solution in the proposed patch is to extend the test for potential
CUs that are worth examining to include not only those for which no
address range has yet been computed, but also those for which no line
table has been loaded.

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