Owen Anderson
2011-Aug-12 17:33 UTC
[LLVMdev] New ARM disassembler - unpredictable instructions
Hi James, On Aug 12, 2011, at 1:02 AM, James Molloy wrote:> I’ve got a load of examples for this, but I’ll pick one. > > echo '0xB0 0x00 0x00 0x00' |/work/llvm-cmake2/build/bin/llvm-mc -arch arm --disassemble – > strheq r0, [r0], -r0 > > This instruction encoding is marked UNPREDICTABLE. The question is: does a disassembly of it have value? One use case put to me was in a debugger, where one needs to know if an instruction was ARM-mode or Thumb-mode so it can correctly guess the mode of the previous instruction in the stream and disassemble that correctly.OK, I think I was misunderstanding what you wrote initially. I thought you meant there were ambiguous decodings where special UNPREDICTABLE handling was necessary for disambiguation, and was going to be very disturbed if that were true! The initial new disassembler implementation, as you've noticed, does very little UNPREDICTABLE checking. I'm adding more checking to it as I have time/inclination, but I'm more concerned with getting it to decode more correct instructions than with getting it to reject more invalid ones. That said, I do think it would be useful to a) have more UNPREDICTABLE checking, mostly in the form of greater operand validation, and b) to have a means of conveying that to the user. I'm not sure that adding a bit to MCInst is necessary, however. Perhaps we could just promote the return value of getInstruction() from bool to a trinary value that can indicate success, failure, or soft failure. Then it can be up to the client to handle that in some useful fashion. I'm not going to have the bandwidth to work on a structural change like that in the immediate future, but if you're interested it would be a great addition! --Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110812/6d000b75/attachment.html>
James Molloy
2011-Aug-12 18:39 UTC
[LLVMdev] New ARM disassembler - unpredictable instructions
Hi Owen, Sounds good, I'll work on this at some point in the near future. I've some more patches ready for you too, but they'll have to wait for Monday to be internally code reviewed and gatekeeper-checked. Cheers, James On 12 Aug 2011, at 18:33, "Owen Anderson" <resistor at mac.com<mailto:resistor at mac.com>> wrote: Hi James, On Aug 12, 2011, at 1:02 AM, James Molloy wrote: I’ve got a load of examples for this, but I’ll pick one. echo '0xB0 0x00 0x00 0x00' |/work/llvm-cmake2/build/bin/llvm-mc -arch arm --disassemble – strheq r0, [r0], -r0 This instruction encoding is marked UNPREDICTABLE. The question is: does a disassembly of it have value? One use case put to me was in a debugger, where one needs to know if an instruction was ARM-mode or Thumb-mode so it can correctly guess the mode of the previous instruction in the stream and disassemble that correctly. OK, I think I was misunderstanding what you wrote initially. I thought you meant there were ambiguous decodings where special UNPREDICTABLE handling was necessary for disambiguation, and was going to be very disturbed if that were true! The initial new disassembler implementation, as you've noticed, does very little UNPREDICTABLE checking. I'm adding more checking to it as I have time/inclination, but I'm more concerned with getting it to decode more correct instructions than with getting it to reject more invalid ones. That said, I do think it would be useful to a) have more UNPREDICTABLE checking, mostly in the form of greater operand validation, and b) to have a means of conveying that to the user. I'm not sure that adding a bit to MCInst is necessary, however. Perhaps we could just promote the return value of getInstruction() from bool to a trinary value that can indicate success, failure, or soft failure. Then it can be up to the client to handle that in some useful fashion. I'm not going to have the bandwidth to work on a structural change like that in the immediate future, but if you're interested it would be a great addition! --Owen -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.