blob: f7fd19f6d2f59b7085ac4148a2be34f0f4452171 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
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.
|