bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug binutils/30880] New: readelf..debug-dump=loc displays bogus base ad


From: sevaa at sprynet dot com
Subject: [Bug binutils/30880] New: readelf..debug-dump=loc displays bogus base addresses
Date: Sat, 23 Sep 2023 21:38:24 +0000

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

            Bug ID: 30880
           Summary: readelf..debug-dump=loc displays bogus base addresses
           Product: binutils
           Version: 2.42 (HEAD)
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: binutils
          Assignee: unassigned at sourceware dot org
          Reporter: sevaa at sprynet dot com
  Target Milestone: ---

Created attachment 15122
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15122&action=edit
Test binary

When dumping location lists in rnglists section with offsets in unit headers,
all addresses are off. In general, it's impossible to retrieve the address
range of a loclist entry without tracking a loclist to its home CU, and readelf
doesn't seem to do that.

Run readelf --debug-dump=loc with the attached binary. The very first loclist
entry goes:

    0000012c 0000000000000000 0000000000000009 DW_OP_reg5 (rdi)

It's an entry of type DW_LLE_offset_pair, 0 and 9 are not addresses, those are
offsets from the base address in the CU's top DIE (the value of DW_AT_low_lc).
The latter is not zero.

Another issue exists when dumping DW_LLE_base_addressx (there is one in the
loclist at 29e50). Its first value is an index into .debug_addr relative to the
home CU's top DIE's DW_AT_base_addr, not relative to the section top, and yet
readelf interprets it as such. As a result, the displayed value is bogus.

The first one is sort of defensible, since it reflects the raw value in the
entry (if not particularly useful and inconsistent with the way V4/unindexed V5
loclists are dumped), the second one is straight up bogus. Check against
another parser, e. g. llvm-dwarfdump, if in doubt.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]