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: unassignedb...@nondot.org
Reporter: tcorr...@amd.com
CC: llvm-bugs@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._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
