ARM: Rework how unrecognized/unimplemented instructions are handled.

Instead of panic immediately when these instructions are executed, an
UndefinedInstruction fault is returned. In FS mode (not currently
implemented), this is the fault that should, to my knowledge, be triggered in
these situations and should be handled using the normal architected
mechanisms. In SE mode, the fault causes a panic when it's invoked that gives
the same information as the instruction did. When/if support for speculative
execution of ARM is supported, this will allow a mispeculated and unrecognized
and/or unimplemented instruction from causing a panic. Only once the
instruction is going to be committed will the fault be invoked, triggering the
panic.

1 files changed, 18 insertions, 0 deletions

diff --git a/src/arch/arm/faults.cc b/src/arch/arm/faults.cc
index 2f939ea8c..9e32a23a3 100644
--- a/src/arch/arm/faults.cc
+++ b/src/arch/arm/faults.cc
@@ -142,6 +142,24 @@ ArmFaultBase::invoke(ThreadContext *tc)
     tc->setPC(newPc);
     tc->setNextPC(newPc + cpsr.t ? 2 : 4 );
 }
+
+#else
+
+void
+UndefinedInstruction::invoke(ThreadContext *tc)
+{
+    assert(unknown || mnemonic != NULL);
+    if (unknown) {
+        panic("Attempted to execute unknown instruction "
+              "(inst 0x%08x, opcode 0x%x, binary:%s)",
+              machInst, machInst.opcode, inst2string(machInst));
+    } else {
+        panic("Attempted to execute unimplemented instruction '%s' "
+              "(inst 0x%08x, opcode 0x%x, binary:%s)",
+              mnemonic, machInst, machInst.opcode, inst2string(machInst));
+    }
+}
+
 #endif // FULL_SYSTEM
 
 // return via SUBS pc, lr, xxx; rfe, movs, ldm