add zero-shot results

1 files changed, 11 insertions, 0 deletions

diff --git a/results/classifier/zero-shot-user-mode/output/instruction/1820686 b/results/classifier/zero-shot-user-mode/output/instruction/1820686
new file mode 100644
index 00000000..ad5531d2
--- /dev/null
+++ b/results/classifier/zero-shot-user-mode/output/instruction/1820686
@@ -0,0 +1,11 @@
+instruction: 0.875
+runtime: 0.095
+syscall: 0.030
+
+
+
+risc-v: 'c.unimp' instruction decoded as 'c.addi4spn fp, 0'
+
+QEMU 3.1 incorrectly decodes the "c.unimp" instruction (opcode 0x0000) as an "addi4spn fp, 0" when either of the two following bytes are non-zero. This is because the ctx->opcode value used when decoding the instruction is actually filled with a 32-bit load (to handle normal uncompressed instructions) but when a compressed instruction is found only the low 16 bits are valid. Other reserved/illegal bit patterns with the addi4spn opcode are also incorrectly decoded.
+
+I believe that the switch to decodetree on master happened to fix this issue, but hopefully it is helpful to have this recorded somewhere. I've included a simple one line patch if anyone wants to backport this.
\ No newline at end of file