[llvm-bugs] [Bug 36347] New: [AMDGPU]{MC] Improve disassembler error handling

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=36347

            Bug ID: 36347
           Summary: [AMDGPU]{MC] Improve disassembler error handling
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: AMDGPU
          Assignee: unassignedbugs at nondot.org
          Reporter: tcorring at amd.com
                CC: llvm-bugs at lists.llvm.org

Currently AMDGPUDisassembler::getInstruction() follows the standard LLVM
disassembler documented behavior for reporting an instruction that cannot be
disassembled - it returns an empty string and reports 0 bytes as consumed.

This has the result that the 4 byte instruction is reported as unknown, but the
disassembler steps just 1 byte before attempting to decode the next
instruction. As amdgcn instructions are multiples of 4 bytes, a 1 byte step
almost guarantees that the result will either be another failed instruction or
the bogus disassembly of an instruction encoding that is made up from part of
one instruction and part of another. In the best case this results in a cascade
of four invalid instructions, but can result in much longer cascades. In either
case the remainder of the disassembly can't be trusted.

There are two approaches to improve this:

1) change the disassembler to report 4 bytes consumed when reporting an
instruction disassembly failure. This is a trivial one character change, but
does go against the LLVM Disassembler behavior - some other targets have
already made this change.

2) disassemble unrecognized opcodes as data using the .long directive (assuming
the unknown instruction is 4 bytes). This avoids disassembly failures, so the
change at 1) isn't required. However, it doesn't guarantee valid disassembly is
always valid, as the unrecognized instruction may be 8 bytes, leading to
further errors or bogus disassembly - this is likely to be in fewer cases than
previously though. An advantage of this approach is that the resulting
disassembly is in a format that is suitable for re-assembly.

I favor 2), as this has more advantages. There isn't a solution that is always
correct in the presence of unknown opcodes, but this is probably as close as is
possible, and much better than the current behavior.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180212/54e7eb45/attachment-0001.html>