Re: readelf: Displaying "raw' .debug_aranges

[Mark Wielaard <mjw at redhat dot com>]

On Fri, Mar 22, 2013 at 01:41:42PM -0700, Roland McGrath wrote:
> I think it's a sound plan to have an independent raw-data decoder in
> readelf.  It's not clear to me from what you showed whether the output
> text formatting looks different from the old one (aside from contents
> differing by being unsorted).  If it looks a lot different, then
> perhaps it should be a separate option --debug-info=rawaranges (akin
> to binutils readelf's line vs decodedline).  But OTOH perhaps nobody
> ever looks at the existing dumps at all, so just changing the meaning
> of --debug-info=aranges is fine.  I'm just not really sure.

O, --debug-dump=decodedline is nice. I like to have that for eu-readelf
too. Would be really useful in a case I was just looking at where the
"raw" .debug_line encoding is really odd/slightly bogus.

I don't think anybody was using the old --debug-dump=aranges output.
We also didn't have any tests relying on its output. I am not sure the
decoded version is that useful, but we could resurrect it as
--debug-dump=decodedaranges. If only so one can see what libdw would
make of the raw input.

So --debug-dump=aranges will give the raw output:

DWARF section [27] '.debug_aranges' at offset 0x1044:

Table at offset 0:

 Length:            28
 DWARF version:      2
 CU offset:          0
 Address size:       4
 Segment size:       0

   0x080482f0 <main>..0x08048323 <main+0x33>

Table at offset 32:

 Length:            36
 DWARF version:      2
 CU offset:        136
 Address size:       4
 Segment size:       0

   0x08048440 <bar>..0x08048451 <bar+0x11>
   0x08048330 <nobar>..0x0804833a <nobar+0xa>

Table at offset 72:

 Length:            36
 DWARF version:      2
 CU offset:        1d1
 Address size:       4
 Segment size:       0

   0x08048460 <baz>..0x080484bb <baz+0x5b>
   0x08048340 <nobaz>..0x0804834a <nobaz+0xa>

And --debug-dump=decodedaranges will give what we used to give:

DWARF section [27] '.debug_aranges' at offset 0x1044 contains 5 entries:
 [0] start: 0x080482f0, length:    52, CU DIE offset:     11
 [1] start: 0x08048330, length:    11, CU DIE offset:    321
 [2] start: 0x08048340, length:    11, CU DIE offset:    476
 [3] start: 0x08048440, length:    18, CU DIE offset:    321
 [4] start: 0x08048460, length:    92, CU DIE offset:    476

So you get a sorted list of addresses instead of addresses grouped per
CU, and DIE offsets instead of CU offsets.

I'll also implement --debug-dump=decodedline.

Cheers,

Mark