search

pmachata / dwgrep

a tool for querying Dwarf (debuginfo) graphs
http://pmachata.github.io/dwgrep/
GNU General Public License v3.0
53 stars 10 forks source link

F21 vmlinux hits garbage ranges #21

Closed cuviper closed 9 years ago

cuviper commented 9 years ago

I encountered this error:

$ dwgrep -e entry /usr/lib/debug/lib/modules/3.18.5-201.fc21.x86_64/vmlinux
[b]     compile_unit
        stmt_list (data4)       0;
        ranges (data4)  Error: invalid DWARF
$ echo $?
2

That CU as shown by eu-readelf is:

 [Offset]
 Compilation unit at offset 0:
 Version: 2, Abbreviation section offset: 0, Address size: 8, Offset size: 4
 [     b]  compile_unit
           stmt_list            (data4) 0
           ranges               (data4) range list [     0]
           name                 (string) "arch/x86/kernel/head_64.S"
           comp_dir             (string) "/usr/src/debug////////kernel-3.18.fc21/linux-3.18.5-201.fc21.x86_64"
           producer             (string) "GNU AS 2.24"
           language             (data2) Mips_Assembler (32769)

The next CU has range list 250, so this one contains:

DWARF section [38] '.debug_ranges' at offset 0x9c6a570:
 [     0]  base address 000000000000000000 <irq_stack_union>
 [    10]  <UNUSED GARBAGE> ... 48 bytes ...
 [    40]  0xffffffff81d4b222 <reset_early_page_tables+0x1d>..0xffffffff81d4b248 <reset_early_page_tables+0x43>
           0xffffffff81d4b252 <reset_early_page_tables+0x4d>..0xffffffff81d4b255 <reset_early_page_tables+0x50>
 [    70]  0xffffffff81d4b36a <early_make_pgtable+0x6a>..0xffffffff81d4b372 <early_make_pgtable+0x72>
           0xffffffff81d4b376 <early_make_pgtable+0x76>..0xffffffff81d4b37a <early_make_pgtable+0x7a>
 [    a0]  0xffffffff81d4b484 <early_make_pgtable+0x184>..0xffffffff81d4b488 <early_make_pgtable+0x188>
           0xffffffff81d4b495 <early_make_pgtable+0x195>..0xffffffff81d4b49b <early_make_pgtable+0x19b>
 [    d0]  0xffffffff81d4b4e5 <x86_64_start_kernel+0xc>..0xffffffff81d4b4e9 <x86_64_start_kernel+0x10>
           0xffffffff81d4b52c <x86_64_start_kernel+0x53>..0xffffffff81d4b584 <x86_64_start_kernel+0xab>
 [   100]  0xffffffff81d4b4e5 <x86_64_start_kernel+0xc>..0xffffffff81d4b4e9 <x86_64_start_kernel+0x10>
           0xffffffff81d4b550 <x86_64_start_kernel+0x77>..0xffffffff81d4b557 <x86_64_start_kernel+0x7e>
           0xffffffff81d4b55f <x86_64_start_kernel+0x86>..0xffffffff81d4b562 <x86_64_start_kernel+0x89>
           0xffffffff81d4b566 <x86_64_start_kernel+0x8d>..0xffffffff81d4b570 <x86_64_start_kernel+0x97>
 [   150]  0xffffffff81d4b52c <x86_64_start_kernel+0x53>..0xffffffff81d4b550 <x86_64_start_kernel+0x77>
           0xffffffff81d4b557 <x86_64_start_kernel+0x7e>..0xffffffff81d4b55f <x86_64_start_kernel+0x86>
           0xffffffff81d4b562 <x86_64_start_kernel+0x89>..0xffffffff81d4b566 <x86_64_start_kernel+0x8d>
 [   190]  0xffffffff81d4b4f1 <x86_64_start_kernel+0x18>..0xffffffff81d4b4f4 <x86_64_start_kernel+0x1b>
           0xffffffff81d4b510 <x86_64_start_kernel+0x37>..0xffffffff81d4b52c <x86_64_start_kernel+0x53>
 [   1c0]  0xffffffff81d4b584 <x86_64_start_kernel+0xab>..0xffffffff81d4b58b <x86_64_start_kernel+0xb2>
           0xffffffff81d4b5a1 <x86_64_start_kernel+0xc8>..0xffffffff81d4b5a4 <x86_64_start_kernel+0xcb>
           0xffffffff81d4b5ac <x86_64_start_kernel+0xd3>..0xffffffff81d4b5af <x86_64_start_kernel+0xd6>
           0xffffffff81d4b5b3 <x86_64_start_kernel+0xda>..0xffffffff81d4b5c1 <x86_64_start_kernel+0xe8>
 [   210]  0xffffffff81d4b58b <x86_64_start_kernel+0xb2>..0xffffffff81d4b5a1 <x86_64_start_kernel+0xc8>
           0xffffffff81d4b5a4 <x86_64_start_kernel+0xcb>..0xffffffff81d4b5ac <x86_64_start_kernel+0xd3>
           0xffffffff81d4b5af <x86_64_start_kernel+0xd6>..0xffffffff81d4b5b3 <x86_64_start_kernel+0xda>

I suppose the "garbage" is the issue tripping up dwgrep...

cuviper commented 9 years ago

FWIW, binutils' readelf isn't annoyed by this:

    Offset   Begin    End
    00000000 ffffffffffffffff 0000000000000000 (base address)
    00000000 ffffffff81000000 ffffffff810001c7
    00000000 ffffffff81d4b000 ffffffff81d4b205
    00000000 <End of list>
    00000040 ffffffff81d4b222 ffffffff81d4b248
    00000040 ffffffff81d4b252 ffffffff81d4b255
    00000040 <End of list>
    00000040 ffffffff81d4b222 ffffffff81d4b248
    00000040 ffffffff81d4b252 ffffffff81d4b255
    00000040 <End of list>

And the raw dump is:

Hex dump of section [38] '.debug_ranges', 3274176 bytes at offset 0x9c6a570:
  0x00000000 ffffffff ffffffff 00000000 00000000 ................
  0x00000010 00000081 ffffffff c7010081 ffffffff ................
  0x00000020 00b0d481 ffffffff 05b2d481 ffffffff ................
  0x00000030 00000000 00000000 00000000 00000000 ................
  0x00000040 22b2d481 ffffffff 48b2d481 ffffffff ".......H.......
  0x00000050 52b2d481 ffffffff 55b2d481 ffffffff R.......U.......
  0x00000060 00000000 00000000 00000000 00000000 ................
  0x00000070 6ab3d481 ffffffff 72b3d481 ffffffff j.......r.......
...
pmachata commented 9 years ago

Thanks. This sort of looks like elfutils problem, but I'll need to look more closely.

pmachata commented 9 years ago

This will be fixed in elfutils upstream.