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.
