[LLVMdev] New ARM disassembler - unpredictable instructions

James Molloy James.Molloy at arm.com
Fri Aug 12 11:39:06 PDT 2011


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.




More information about the llvm-dev mailing list