Normally, in the verbose output the first pair of values for a rangelist entry displays the untranslated offsets, as seen in the entry, and the second pair displays the actual PC values in a loaded binary. For DW_RLE_offset_pair type entries like the ones in my binary, the translation involves adding the base PC of the compile unit, as seen in the top DIE's DW_AT_low_pc attribute.
Notice the contents of the last CU's rangelists, the one that starts at 0x000105e9 in debug_rnglists. In that CU, the first and the second pair of values are identical thoughout, as if the tool fails to find the corresponding CU and/or its DW_AT_low_pc. Meanwhile, the CU is perfectly present at offset 0x6b7b9 in debug_info, and the DIE at 0x6cfac contains the DW_AT_ranges with value 0x105f5, which points right at the first rangelist in this CU's block.
The top DIE in said CU contains DW_AT_low_pc with value 0x4b040.
Consider the binary in #56339 . Run the following:
Normally, in the verbose output the first pair of values for a rangelist entry displays the untranslated offsets, as seen in the entry, and the second pair displays the actual PC values in a loaded binary. For
DW_RLE_offset_pair
type entries like the ones in my binary, the translation involves adding the base PC of the compile unit, as seen in the top DIE'sDW_AT_low_pc
attribute.Notice the contents of the last CU's rangelists, the one that starts at 0x000105e9 in debug_rnglists. In that CU, the first and the second pair of values are identical thoughout, as if the tool fails to find the corresponding CU and/or its
DW_AT_low_pc
. Meanwhile, the CU is perfectly present at offset 0x6b7b9 in debug_info, and the DIE at 0x6cfac contains the DW_AT_ranges with value 0x105f5, which points right at the first rangelist in this CU's block.The top DIE in said CU contains
DW_AT_low_pc
with value 0x4b040.