Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

Unreachable triggered when parsing DWARF V5 line table with unsupported FORM #43230

Open Quuxplusone opened 4 years ago

Quuxplusone commented 4 years ago
Bugzilla Link PR44260
Status NEW
Importance P normal
Reported by James Henderson (jh7370.2008@my.bristol.ac.uk)
Reported on 2019-12-10 02:17:11 -0800
Last modified on 2019-12-10 11:50:49 -0800
Version trunk
Hardware PC Windows NT
CC cmtice@google.com, dblaikie@gmail.com, echristo@gmail.com, jdevlieghere@apple.com, keith.walker@arm.com, llvm-bugs@lists.llvm.org, paul_robinson@playstation.sony.com, tamur@google.com
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also
I ran into this when writing some llvm-dwarfdump tests. If a DWARF V5
.debug_line table header includes a file name or directory entry type with an
unsupported FORM value, and llvm-dwarfdump is used to dump the said line table,
an llvm_unreachable is triggered when parsing that field.

// example assembly
.section .debug_line,"",@progbits
    .long .Lunit0_end - .Lunit0_begin # unit_length
.Lunit0_begin:
    .short 5 ## version
    .byte 8  ## address_size
    .byte 0  ## segment_selector_size
    .long .Lheader0_end - .Lheader0_begin ## header_length
.Lheader0_begin:
    .byte 1  ## minimum_instruction_length
    .byte 1  ## maximum_operations_per_instruction
    .byte 1  ## default_is_stmt
    .byte -5 ## line_base
    .byte 7  ## line_range
    .byte 13 ## opcode_base
    .byte 0, 1, 1, 1, 1, 0, 0, 0, 1, 0, 0, 1 ## standard_opcode_lengths
    .byte 1  ## directory_entry_format_count
    .byte 0x1, 0x7F ## DW_LNCT_path, unknown form
    .byte 1  ## directories_count
    .byte 0  ## directory entry 0
    .asciz "dir1/dir2"
    .byte 1  ## file_name_entry_format_count
    .byte 0x1, 0xB ## DW_LNCT_path, DW_FORM_string
    .byte 0x2, 0x5 ## DW_LNCT_directory_index, DW_FORM_data1
    .byte 2  ## file_names_count
    .byte 0  ## file name entry 0
    .asciz "file1.c"
    .byte 1  ## file name entry 1
    .long 0x12345678
.Lheader0_end:
.Lunit0_end:

C:\Work> llvm-dwarfdump --debug-line test.o
test.o: file format ELF64-x86-64

.debug_line contents:
debug_line[0x00000000]
unsupported form
UNREACHABLE executed at C:\llvm\llvm-
project\llvm\lib\DebugInfo\DWARF\DWARFFormValue.cpp:350!
<stack dump...>

The unreachable has an associated comment which seems to imply that the
extractValue code was written for parsing .debug_info, and as such unsupported
DW_FORM_* values are not handled (because they should be handled earlier).
Clearly the code needs updating to allow for DW_FORM_* values coming from
.debug_line. It's probably reasonable to abort parsing of the line table when
an unsupported DW_FORM_* is hit, since it's impossible to know how to handle
the file/directory table in this case.
Quuxplusone commented 4 years ago

Aside: The assembly in the example with the FORM fixed will still cause a problem, but in a different way (warnings will be produced).