diff options
Diffstat (limited to 'results/classifier/semantic-bugs/1820686')
| -rw-r--r-- | results/classifier/semantic-bugs/1820686 | 22 |
1 files changed, 2 insertions, 20 deletions
diff --git a/results/classifier/semantic-bugs/1820686 b/results/classifier/semantic-bugs/1820686 index f7fd19f6d..4f823b4f1 100644 --- a/results/classifier/semantic-bugs/1820686 +++ b/results/classifier/semantic-bugs/1820686 @@ -1,25 +1,7 @@ -instruction: 0.949 -device: 0.824 -network: 0.809 -other: 0.742 -socket: 0.724 -semantic: 0.691 -vnc: 0.683 -mistranslation: 0.678 -graphic: 0.598 -boot: 0.498 -KVM: 0.321 -assembly: 0.305 + 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. - - - -Thanks. If you spin a full patch (ie, "git commit -s" and then "git show") I can drop it on riscv-qemu-3.1, our backports branch. Otherwise hopefully we got the bug via the decodetree conversion. - -Since this bug isn't present in the decodetree version of the riscv decoder, we might as well just close this as fix-released; we won't be doing more point-releases of QEMU versions as old as 3.1. - +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 |