[Bug binutils/30792] Rnglists section dump in readelf outputs one rangelist per CU

[sevaa at sprynet dot com]

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

--- Comment #1 from Vsevolod Alekseyev <sevaa at sprynet dot com> ---
Looked at the sources - readelf straight up doesn't support rnglists sections
with no offset tables (which GCC happily emits, or used to in some versions).
Instead, it hard codes the offset count to 1 and dumps the first rangelist.
That's way incorrect. Offset tables are a good idea in DWARFv5, but not a
requirement. This logic may cause bogus output and bogue error messages, too,
if a CU in the rnglists section contains *no* rangelists.

Even if that was fixed in the straightforward way (unless the offset tables are
present, scroll through the section top to bottom), there would be an
inconsistency between the way v4 ranges section is treated and the way v5
section is treated. The problem is that of overlapping rangelists.

Compilers do that. There is a rangelist in the section, pointed to by some
DW_AT_ranges attribute in some DIE. Then another DW_AT_ranges points at the
middle of the same rangelist. Logically, it makes sense - variable A is
initialized and stays until the end of the scope, a bit later B is initialized
and stays for the same scope - the area of visibility for B is a subset of that
for A. The The DWARF standard doesn't prohibit that and I've seen it in the
wild.

This creates a problem of design philosophy: do you dump that as one rangelist,
or as two? For practical debugging utility, you want two (or more), so that
rangelist offsets can be followed. For faithfully representing the section
contents, you want one, so that physically the same rangelist entry is not
dumped several times. And readelf tries to have it both ways - for v4 sections,
it treats overlapping rangelists as distinct (enumerates the rangelist offsets
from DIEs and follows those), for v5 sections it dumps the section contents
(incorrectly in case of no offset tables).

I'd take a stab at fixing this, but please tell me which approach to
enumeration is right. If consistency with past versions (i. e. the half-here,
half-there approach of right now) is right, tell me that too.

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