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

[nickc at redhat dot com]

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

Nick Clifton <nickc at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nickc at redhat dot com

--- Comment #2 from Nick Clifton <nickc at redhat dot com> ---
(In reply to Vsevolod Alekseyev from comment #1)
Hi Vsevolod,

> 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,

Thank you! :-)

> 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.

There is no one way that is "right", but my advice is this: readelf is
primarily intended to be tool to assist in diagnosing problems with the low
level features of ELF format binary files.  Hence an output that assists in
debugging is preferable to one that goes for accuracy over helpfulness.  

That said, the best solution would be one that caters for both camps.  For
example if the output showed the range lists only once, but also pointed out
which parts of each list were associated with specific DIEs, then this would be
even more helpful.  It would let the user know that the lists were being used
multiple times, and hence, by inference, that there are entities which share
the same range information and might therefore be related in other ways as
well.

Cheers
  Nick

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