[Bug binutils/29267] readelf..info misreports DW_FORM_loclistx, DW_FORM_rnglistx

[sevaa at sprynet dot com]

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

--- Comment #10 from Vsevolod Alekseyev <sevaa at sprynet dot com> ---
There is a bit of parsing complication here that I don't think the current
parser quite appreciates. The DWARF bitness may vary between CUs in indexed
sections, and short of going through the headers, linked list style, there is
no way to determine the bitness for any given section from the DIE data.

The structure of debug_loclists goes like this:

CU_header_0:
  length AKA bitness indicator (4 or 12)
  version (2)
  address_size (1)
  selector_size (1)
  offset_entry_count (4)
  offsets[0] (4 or 8)    <-- DW_AT_loclists_base points here
  offsets[1] (4 or 8)
  ...more offsets
...the actual loclists

The offsets table contain the offsets of the target loclists, relative to the
offsets table start. The size of the offset (4 or 8) is determined by the
length field in the header, the usual DWARF style.

Now, from the value of DW_AT_loclists_base alone, it's pretty much impossible
to tell whether the section is 32- or 64-bit DWARF (except for the 0th CU,
where the DW_AT_loclists_base can be either 12 or 20). In subsequent CUs, you
can't seek back from the offset table to the top of header, because it's
variable length. If you look at the dword at DW_AT_loclists_base-20, it may be
0xffffffff by pure accident. 

Similar situation in debug_rnglists, debug_addr, debug_str_offsets.

A proper parser should go through all CU headers in the section (you can sort
of fast-forward through them by skipping by length), determine and store the
bitness of each, and then recover the bitness of any particular CU by matching
the DW_AT_rnglists_base against that.

One *slightly* better alternative would be - reuse the bitness from the 
corresponding CU in the debug_info. While it is possible to compose a correct
DWARF dataset where the bitness between contributions from the same compile
unit in different section varies, it would be a pain in the neck for the
compiler vendor.

Or you can just assume 32 bits. The spec encourages the implementors not to use
64-bit DWARF unless absolutely necessary. How often does one see 4GB+ sections
in a binary?

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