New ARM disassembler - unpredictable instructions


I’m looking at the new ARM disassembler, and performing testing to see if there are any obvious bugs I can fix. Overall it looks really nice – I’ve only found one obvious bug that I’m packaging up a patch for now.

Glad you're liking it! I haven't really done comprehensive testing yet—it passes all the decoding tests that the previous disassembler passed, but I'm sure there are many cases that it does not yet get right. Patches welcome.

Currently it does not provide information as to whether a particular bitpattern was UNPREDICTABLE or not. For example, an invalid bitpattern may return correct disassembly for an alternative, predictable instruction meaning that the sequence X -> disassemble -> assemble -> Y could end up with X being different to Y.

Can you give an example of this?


Hi Owen,

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.

So I think that “return false” on all UNPREDICTABLEs is losing functionality that could potentially be useful. Naturally you don’t want to do the current behaviour and have UNPREDICTABLEs erroneously decoded as valid instructions (as it looks above, until you try to assemble it at which point an error is raised).

Our internal disassembly mechanism prints the following:

strheq r0, [r0], -r0 ; ?

With the trailing “; ?” meaning that the instruction is unpredictable. It also gives a hint that the disassembly cannot be correctly assembled - there might be a (correct) assumption otherwise that assembly and disassembly are the exact opposites of each other, and anything that is successfully disassembled must be able to be assembled again (indeed, this can be an extremely useful test for a disassembler/assembler combo such as MC).

The question is whether or not a “soft fail” such as the above has value – I think it does. What do you think?



Hi James,

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.