[LLVMdev] New ARM disassembler - unpredictable instructions

[Owen Anderson]

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>