From b89a938452613061c0f1f23e710281cf5c83cb29 Mon Sep 17 00:00:00 2001 From: Christian Krinitsin Date: Thu, 12 Jun 2025 09:56:59 +0200 Subject: add manually reviewed semantic bugs --- results/classifier/semantic-bugs/assembly/1612 | 64 ++ results/classifier/semantic-bugs/assembly/1620 | 107 +++ results/classifier/semantic-bugs/assembly/1649 | 30 + results/classifier/semantic-bugs/assembly/904 | 29 + results/classifier/semantic-bugs/boot/1748296 | 95 +++ results/classifier/semantic-bugs/graphic/1641637 | 743 +++++++++++++++++++++ results/classifier/semantic-bugs/graphic/1722 | 100 +++ results/classifier/semantic-bugs/graphic/2595 | 148 ++++ results/classifier/semantic-bugs/graphic/2672 | 33 + results/classifier/semantic-bugs/graphic/904308 | 201 ++++++ results/classifier/semantic-bugs/instruction/1057 | 36 + results/classifier/semantic-bugs/instruction/1062 | 29 + .../classifier/semantic-bugs/instruction/1079080 | 43 ++ results/classifier/semantic-bugs/instruction/1092 | 27 + .../classifier/semantic-bugs/instruction/1095857 | 29 + results/classifier/semantic-bugs/instruction/1156 | 14 + results/classifier/semantic-bugs/instruction/1204 | 42 ++ .../classifier/semantic-bugs/instruction/1245543 | 43 ++ .../classifier/semantic-bugs/instruction/1248168 | 42 ++ .../classifier/semantic-bugs/instruction/1328996 | 25 + results/classifier/semantic-bugs/instruction/1376 | 28 + results/classifier/semantic-bugs/instruction/1377 | 27 + results/classifier/semantic-bugs/instruction/1498 | 18 + .../classifier/semantic-bugs/instruction/1574346 | 41 ++ results/classifier/semantic-bugs/instruction/1637 | 14 + .../classifier/semantic-bugs/instruction/1719984 | 27 + results/classifier/semantic-bugs/instruction/1737 | 62 ++ .../classifier/semantic-bugs/instruction/1738434 | 50 ++ .../classifier/semantic-bugs/instruction/1751422 | 71 ++ .../classifier/semantic-bugs/instruction/1751494 | 38 ++ .../classifier/semantic-bugs/instruction/1756927 | 47 ++ results/classifier/semantic-bugs/instruction/1771 | 46 ++ .../classifier/semantic-bugs/instruction/1771948 | 51 ++ results/classifier/semantic-bugs/instruction/1780 | 30 + results/classifier/semantic-bugs/instruction/1790 | 42 ++ .../classifier/semantic-bugs/instruction/1793608 | 49 ++ .../classifier/semantic-bugs/instruction/1818075 | 133 ++++ .../classifier/semantic-bugs/instruction/1820686 | 25 + .../classifier/semantic-bugs/instruction/1824344 | 71 ++ .../classifier/semantic-bugs/instruction/1824778 | 30 + .../classifier/semantic-bugs/instruction/1828867 | 48 ++ .../classifier/semantic-bugs/instruction/1832422 | 33 + .../classifier/semantic-bugs/instruction/1863247 | 33 + .../classifier/semantic-bugs/instruction/1889288 | 26 + .../classifier/semantic-bugs/instruction/1898954 | 73 ++ results/classifier/semantic-bugs/instruction/1901 | 32 + .../classifier/semantic-bugs/instruction/1912934 | 78 +++ .../classifier/semantic-bugs/instruction/1915027 | 27 + .../classifier/semantic-bugs/instruction/1916269 | 70 ++ .../classifier/semantic-bugs/instruction/1926759 | 73 ++ results/classifier/semantic-bugs/instruction/1955 | 39 ++ results/classifier/semantic-bugs/instruction/1958 | 34 + results/classifier/semantic-bugs/instruction/2074 | 33 + results/classifier/semantic-bugs/instruction/2089 | 40 ++ results/classifier/semantic-bugs/instruction/2175 | 51 ++ results/classifier/semantic-bugs/instruction/2248 | 49 ++ results/classifier/semantic-bugs/instruction/2302 | 38 ++ results/classifier/semantic-bugs/instruction/2317 | 51 ++ results/classifier/semantic-bugs/instruction/2318 | 47 ++ results/classifier/semantic-bugs/instruction/2386 | 56 ++ results/classifier/semantic-bugs/instruction/2497 | 16 + results/classifier/semantic-bugs/instruction/2500 | 17 + results/classifier/semantic-bugs/instruction/2865 | 65 ++ results/classifier/semantic-bugs/instruction/2971 | 57 ++ results/classifier/semantic-bugs/instruction/361 | 14 + results/classifier/semantic-bugs/instruction/390 | 14 + results/classifier/semantic-bugs/instruction/514 | 38 ++ results/classifier/semantic-bugs/instruction/799 | 60 ++ results/classifier/semantic-bugs/instruction/824 | 25 + results/classifier/semantic-bugs/instruction/826 | 29 + results/classifier/semantic-bugs/instruction/925 | 31 + results/classifier/semantic-bugs/instruction/984 | 36 + .../semantic-bugs/mistranslation/1613817 | 130 ++++ .../semantic-bugs/mistranslation/1830872 | 612 +++++++++++++++++ .../semantic-bugs/mistranslation/1861404 | 223 +++++++ .../classifier/semantic-bugs/mistranslation/266 | 14 + .../classifier/semantic-bugs/mistranslation/427 | 14 + .../classifier/semantic-bugs/mistranslation/508 | 14 + results/classifier/semantic-bugs/mistranslation/83 | 14 + results/classifier/semantic-bugs/other/1267955 | 187 ++++++ results/classifier/semantic-bugs/other/2371 | 65 ++ results/classifier/semantic-bugs/other/2372 | 122 ++++ results/classifier/semantic-bugs/other/2374 | 124 ++++ results/classifier/semantic-bugs/semantic/1156313 | 128 ++++ results/classifier/semantic-bugs/semantic/1370 | 26 + results/classifier/semantic-bugs/semantic/1371 | 32 + results/classifier/semantic-bugs/semantic/1372 | 33 + results/classifier/semantic-bugs/semantic/1373 | 33 + results/classifier/semantic-bugs/semantic/1374 | 35 + results/classifier/semantic-bugs/semantic/1375 | 32 + results/classifier/semantic-bugs/semantic/1428352 | 63 ++ results/classifier/semantic-bugs/semantic/1809546 | 90 +++ results/classifier/semantic-bugs/semantic/1923197 | 149 +++++ results/classifier/semantic-bugs/vnc/1785734 | 129 ++++ 94 files changed, 6382 insertions(+) create mode 100644 results/classifier/semantic-bugs/assembly/1612 create mode 100644 results/classifier/semantic-bugs/assembly/1620 create mode 100644 results/classifier/semantic-bugs/assembly/1649 create mode 100644 results/classifier/semantic-bugs/assembly/904 create mode 100644 results/classifier/semantic-bugs/boot/1748296 create mode 100644 results/classifier/semantic-bugs/graphic/1641637 create mode 100644 results/classifier/semantic-bugs/graphic/1722 create mode 100644 results/classifier/semantic-bugs/graphic/2595 create mode 100644 results/classifier/semantic-bugs/graphic/2672 create mode 100644 results/classifier/semantic-bugs/graphic/904308 create mode 100644 results/classifier/semantic-bugs/instruction/1057 create mode 100644 results/classifier/semantic-bugs/instruction/1062 create mode 100644 results/classifier/semantic-bugs/instruction/1079080 create mode 100644 results/classifier/semantic-bugs/instruction/1092 create mode 100644 results/classifier/semantic-bugs/instruction/1095857 create mode 100644 results/classifier/semantic-bugs/instruction/1156 create mode 100644 results/classifier/semantic-bugs/instruction/1204 create mode 100644 results/classifier/semantic-bugs/instruction/1245543 create mode 100644 results/classifier/semantic-bugs/instruction/1248168 create mode 100644 results/classifier/semantic-bugs/instruction/1328996 create mode 100644 results/classifier/semantic-bugs/instruction/1376 create mode 100644 results/classifier/semantic-bugs/instruction/1377 create mode 100644 results/classifier/semantic-bugs/instruction/1498 create mode 100644 results/classifier/semantic-bugs/instruction/1574346 create mode 100644 results/classifier/semantic-bugs/instruction/1637 create mode 100644 results/classifier/semantic-bugs/instruction/1719984 create mode 100644 results/classifier/semantic-bugs/instruction/1737 create mode 100644 results/classifier/semantic-bugs/instruction/1738434 create mode 100644 results/classifier/semantic-bugs/instruction/1751422 create mode 100644 results/classifier/semantic-bugs/instruction/1751494 create mode 100644 results/classifier/semantic-bugs/instruction/1756927 create mode 100644 results/classifier/semantic-bugs/instruction/1771 create mode 100644 results/classifier/semantic-bugs/instruction/1771948 create mode 100644 results/classifier/semantic-bugs/instruction/1780 create mode 100644 results/classifier/semantic-bugs/instruction/1790 create mode 100644 results/classifier/semantic-bugs/instruction/1793608 create mode 100644 results/classifier/semantic-bugs/instruction/1818075 create mode 100644 results/classifier/semantic-bugs/instruction/1820686 create mode 100644 results/classifier/semantic-bugs/instruction/1824344 create mode 100644 results/classifier/semantic-bugs/instruction/1824778 create mode 100644 results/classifier/semantic-bugs/instruction/1828867 create mode 100644 results/classifier/semantic-bugs/instruction/1832422 create mode 100644 results/classifier/semantic-bugs/instruction/1863247 create mode 100644 results/classifier/semantic-bugs/instruction/1889288 create mode 100644 results/classifier/semantic-bugs/instruction/1898954 create mode 100644 results/classifier/semantic-bugs/instruction/1901 create mode 100644 results/classifier/semantic-bugs/instruction/1912934 create mode 100644 results/classifier/semantic-bugs/instruction/1915027 create mode 100644 results/classifier/semantic-bugs/instruction/1916269 create mode 100644 results/classifier/semantic-bugs/instruction/1926759 create mode 100644 results/classifier/semantic-bugs/instruction/1955 create mode 100644 results/classifier/semantic-bugs/instruction/1958 create mode 100644 results/classifier/semantic-bugs/instruction/2074 create mode 100644 results/classifier/semantic-bugs/instruction/2089 create mode 100644 results/classifier/semantic-bugs/instruction/2175 create mode 100644 results/classifier/semantic-bugs/instruction/2248 create mode 100644 results/classifier/semantic-bugs/instruction/2302 create mode 100644 results/classifier/semantic-bugs/instruction/2317 create mode 100644 results/classifier/semantic-bugs/instruction/2318 create mode 100644 results/classifier/semantic-bugs/instruction/2386 create mode 100644 results/classifier/semantic-bugs/instruction/2497 create mode 100644 results/classifier/semantic-bugs/instruction/2500 create mode 100644 results/classifier/semantic-bugs/instruction/2865 create mode 100644 results/classifier/semantic-bugs/instruction/2971 create mode 100644 results/classifier/semantic-bugs/instruction/361 create mode 100644 results/classifier/semantic-bugs/instruction/390 create mode 100644 results/classifier/semantic-bugs/instruction/514 create mode 100644 results/classifier/semantic-bugs/instruction/799 create mode 100644 results/classifier/semantic-bugs/instruction/824 create mode 100644 results/classifier/semantic-bugs/instruction/826 create mode 100644 results/classifier/semantic-bugs/instruction/925 create mode 100644 results/classifier/semantic-bugs/instruction/984 create mode 100644 results/classifier/semantic-bugs/mistranslation/1613817 create mode 100644 results/classifier/semantic-bugs/mistranslation/1830872 create mode 100644 results/classifier/semantic-bugs/mistranslation/1861404 create mode 100644 results/classifier/semantic-bugs/mistranslation/266 create mode 100644 results/classifier/semantic-bugs/mistranslation/427 create mode 100644 results/classifier/semantic-bugs/mistranslation/508 create mode 100644 results/classifier/semantic-bugs/mistranslation/83 create mode 100644 results/classifier/semantic-bugs/other/1267955 create mode 100644 results/classifier/semantic-bugs/other/2371 create mode 100644 results/classifier/semantic-bugs/other/2372 create mode 100644 results/classifier/semantic-bugs/other/2374 create mode 100644 results/classifier/semantic-bugs/semantic/1156313 create mode 100644 results/classifier/semantic-bugs/semantic/1370 create mode 100644 results/classifier/semantic-bugs/semantic/1371 create mode 100644 results/classifier/semantic-bugs/semantic/1372 create mode 100644 results/classifier/semantic-bugs/semantic/1373 create mode 100644 results/classifier/semantic-bugs/semantic/1374 create mode 100644 results/classifier/semantic-bugs/semantic/1375 create mode 100644 results/classifier/semantic-bugs/semantic/1428352 create mode 100644 results/classifier/semantic-bugs/semantic/1809546 create mode 100644 results/classifier/semantic-bugs/semantic/1923197 create mode 100644 results/classifier/semantic-bugs/vnc/1785734 diff --git a/results/classifier/semantic-bugs/assembly/1612 b/results/classifier/semantic-bugs/assembly/1612 new file mode 100644 index 000000000..aa2f4e529 --- /dev/null +++ b/results/classifier/semantic-bugs/assembly/1612 @@ -0,0 +1,64 @@ +assembly: 0.776 +instruction: 0.670 +graphic: 0.648 +semantic: 0.641 +device: 0.599 +other: 0.486 +network: 0.456 +socket: 0.453 +boot: 0.407 +vnc: 0.367 +mistranslation: 0.229 +KVM: 0.225 + +SVE first-faulting gather loads return incorrect data +Description of problem: +The results of `ldff1(b|h|w|d)` seem to be incorrect when ` == `. The first element is duplicated throughout the vector while the FFR indicates that all elements were successfully loaded. This happens since https://gitlab.com/qemu-project/qemu/-/commit/50de9b78cec06e6d16e92a114a505779359ca532, and still happens on the latest master. +Steps to reproduce: +1. This assembly sequence loads data with an `ldff1d` instruction (and also loads the ffr). Note that with `ldff1d`, ` == `. + +asmtest.s +``` + .type asmtest, @function + .balign 16 + .global asmtest +asmtest: + setffr + ptrue p0.d + index z1.d, #0, #1 + ldff1d z1.d, p0/z, [x0, z1.d, LSL #3] + rdffr p1.b + st1d {z1.d}, p0, [x1] + str p1, [x2] + ret +``` + +This harness for convenience intialises some data and checks the element at index 1, which should be 1. + +test.c +``` +#include +#include + +void asmtest(int64_t const * data, svint64_t * loaded, svbool_t * ffr); + +int main() { + const int64_t data[] = {42, 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, 26, 27, 28, 29, 30, 31}; + svint64_t loaded; + svbool_t ffr; + + asmtest(data, &loaded, &ffr); + + // Check value of element at index 1 + svuint64_t lanes = svindex_u64(0, 1); + svbool_t lane = svcmpeq_n_u64(svptrue_b64(), lanes, 1); + printf("%ld\n", svaddv_s64(lane, loaded)); +} +``` + +2. ```clang-15 -fuse-ld=lld -march=armv8-a+sve2 -target aarch64-unknown-linux-gnu -static *.c *.s -o svldffgathertest``` +3. ```qemu-aarch64 svldffgathertest``` - the value printed should be 1, but it can be seen that all values in the loaded vector are 42. +Additional information: +The above code was successfully tested on real SVE hardware. Normal gathers work fine in QEMU, as does a non-gather first-fault load. diff --git a/results/classifier/semantic-bugs/assembly/1620 b/results/classifier/semantic-bugs/assembly/1620 new file mode 100644 index 000000000..ecfad33cc --- /dev/null +++ b/results/classifier/semantic-bugs/assembly/1620 @@ -0,0 +1,107 @@ +assembly: 0.775 +other: 0.747 +device: 0.720 +KVM: 0.715 +instruction: 0.707 +mistranslation: 0.702 +semantic: 0.688 +graphic: 0.672 +vnc: 0.639 +socket: 0.616 +boot: 0.561 +network: 0.554 + +SME FMOPA outer product instruction gives incorrect result +Description of problem: +The SME outer product instructions operate on tiles of elements. In the +below example we are performing an outer product of a vector of 1.0 +by itself. This naturally should produce a matrix filled with 1.0 +values, however if we read the values of the tile and printf them we +instead observe 0.0 values. + +Without digging into the underlying QEMU code this appears to be a bug +in how elements are set based on the tile number, since the same code +using za0.s rather than za1.s correctly reports all 1.0 values as output +as expected. + +main.c +``` +#include + +void foo(float *dst); + +int main() { + float dst[16]; + foo(dst); + + // This should print: + // >>> 1.000000 1.000000 1.000000 1.000000 + // >>> 1.000000 1.000000 1.000000 1.000000 + // >>> 1.000000 1.000000 1.000000 1.000000 + // >>> 1.000000 1.000000 1.000000 1.000000 + for (int i=0; i<4; ++i) { + printf(">>> "); + for (int j=0; j<4; ++j) { + printf("%lf ", (double)dst[i * 4 + j]); + } + printf("\n"); + } +} +``` + +foo.S +``` +.global foo +foo: + stp x29, x30, [sp, -80]! + mov x29, sp + stp d8, d9, [sp, 16] + stp d10, d11, [sp, 32] + stp d12, d13, [sp, 48] + stp d14, d15, [sp, 64] + + smstart + + ptrue p0.s, vl4 + fmov z0.s, #1.0 + + // An outer product of a vector of 1.0 by itself should be a matrix of 1.0. + // Note that we are using tile 1 here (za1.s) rather than tile 0. + zero {za} + fmopa za1.s, p0/m, p0/m, z0.s, z0.s + + // Read the first 4x4 sub-matrix of elements from tile 1: + // Note that za1h should be interchangable here. + mov w12, #0 + mova z0.s, p0/m, za1v.s[w12, #0] + mova z1.s, p0/m, za1v.s[w12, #1] + mova z2.s, p0/m, za1v.s[w12, #2] + mova z3.s, p0/m, za1v.s[w12, #3] + + // And store them to the input pointer (dst in the C code): + st1w {z0.s}, p0, [x0] + add x0, x0, #16 + st1w {z1.s}, p0, [x0] + add x0, x0, #16 + st1w {z2.s}, p0, [x0] + add x0, x0, #16 + st1w {z3.s}, p0, [x0] + + smstop + + ldp d8, d9, [sp, 16] + ldp d10, d11, [sp, 32] + ldp d12, d13, [sp, 48] + ldp d14, d15, [sp, 64] + ldp x29, x30, [sp], 80 + ret +``` +Steps to reproduce: +``` +$ clang -target aarch64-linux-gnu -march=armv9-a+sme test.c -O1 -static +$ ~/qemu/build/qemu-aarch64 ./a.out +>>> 0.000000 0.000000 0.000000 0.000000 +>>> 0.000000 0.000000 0.000000 0.000000 +>>> 0.000000 0.000000 0.000000 0.000000 +>>> 0.000000 0.000000 0.000000 0.000000 +``` diff --git a/results/classifier/semantic-bugs/assembly/1649 b/results/classifier/semantic-bugs/assembly/1649 new file mode 100644 index 000000000..7d78cca98 --- /dev/null +++ b/results/classifier/semantic-bugs/assembly/1649 @@ -0,0 +1,30 @@ +assembly: 0.984 +instruction: 0.900 +graphic: 0.900 +device: 0.747 +semantic: 0.642 +vnc: 0.610 +network: 0.592 +socket: 0.542 +mistranslation: 0.500 +boot: 0.379 +KVM: 0.352 +other: 0.209 + +"slli" instruction before "la" and "csrw" sequence leads to failure in setting the cs register +Description of problem: +slli a0, a0, 8 (1) + la a0, mtimvec (2) + csrw mtvec, a0 (3) + mtimvec: (4) + +For the above assembly snippet, the mtvec could be successfully set to the value of a0 +without the presence of the line (1) or with the shift amount being zero. However, +the mtvec can never be set successfully with the presence of line (1). +Steps to reproduce: +1. Create a test.s file and put these 4 lines of assembly into the file +2. In terminal, run: "riscv64-unknown-elf-gcc -Ttext 0x80000000 -c test.s -o test", "riscv64-unknown-elf-objcopy test -S -O binary test", and "qemu-system-riscv64 test -s -S" +3. In another terminal window, run [riscv64-unknown-elf-gdb -ex "target remote localhost:1234" -ex "layout asm"]. Keep running si command in gdb until you are at 0x80000000 where you shall see the first instruction as shown in line (1). Then keep going till you have stepped over the instruction shown in line (3). Now, run "p $mtvec" in gdb, you shall see its value being 0. +4. Redo the above steps without line (1), you shall see mtvec loaded successfully with the correct value. +Additional information: + diff --git a/results/classifier/semantic-bugs/assembly/904 b/results/classifier/semantic-bugs/assembly/904 new file mode 100644 index 000000000..4946b8146 --- /dev/null +++ b/results/classifier/semantic-bugs/assembly/904 @@ -0,0 +1,29 @@ +assembly: 0.991 +instruction: 0.939 +graphic: 0.875 +device: 0.846 +semantic: 0.662 +network: 0.599 +mistranslation: 0.507 +vnc: 0.485 +boot: 0.425 +socket: 0.381 +KVM: 0.219 +other: 0.191 + +RISC-V: Cannot set SEIP bit of mip csr register in M mode +Description of problem: + +Steps to reproduce: +1. run assembly instructions **in M mode**: +``` +not t0, x0 // set t0 to 0b11..11 +csrs mip, t0 // write mip with t0, mip registers are WARL(Write Any Values, Reads Legal Values) +csrr t1, mip // read value from mip to t1 +``` +2. GDB enters the command `display/z $t1` to see that the content of the t1 register is 0x466, which means that the SEIP bit of mip is not set. +3. According to page 47 of [riscv-privileged-20211203](https://github.com/riscv/riscv-isa-manual/releases/download/Priv-v1.12/riscv-privileged-20211203.pdf), `SEIP is writable in mip`. +4. According to page 81 of the same manual,`If implemented, SEIP is read-only in sip`. +5. However, the above code and results show that the SEIP bit of mip cannot be set by software **in M mode**. +Additional information: + diff --git a/results/classifier/semantic-bugs/boot/1748296 b/results/classifier/semantic-bugs/boot/1748296 new file mode 100644 index 000000000..cab7dadc5 --- /dev/null +++ b/results/classifier/semantic-bugs/boot/1748296 @@ -0,0 +1,95 @@ +boot: 0.673 +device: 0.671 +semantic: 0.667 +other: 0.644 +instruction: 0.641 +mistranslation: 0.640 +network: 0.584 +graphic: 0.581 +assembly: 0.566 +KVM: 0.560 +socket: 0.552 +vnc: 0.462 + +TCG throws Invalid Opcode when executing x86 BMI shlx instruction + +I am unable to use BMI in my project when running under TCG. I narrowed the problem down to incorrect instruction decoding for BMI instructions (which have a 2 byte VEX prefix). The gen_sse function in translate.c reaches the goto label do_0f_38_fx, but b does not equal 0x1f7, 0x2f7, or 0x3f7, so the switch takes the default path and raises an invalid opcode exception. + +The code executes correctly and passes the test under KVM. + +I have created a complete repro here: https://github.com/doug65536/qemu-bmibug + +The makefile has the following utility targets: + +debug-kvm: Build and run the VM using KVM and wait for gdbstub attach + +run: Run the test case with TCG, make fails if the test fails. (It will fail) + +run-kvm: Run the test case with KVM, make fails if the test fails. (It will succeed) + +debug: Build and run the VM with TCG and wait for GDB attach + +attach-gdb: Run GDB and attach to KVM gdbstub + +The VM runs with -cpu max. CPUID reports support for BMI, BMI2, and ABM. + +You can quickly verify the issue by executing `make run-kvm` to confirm that KVM passes, then `make run` to confirm that TCG fails. + +I believe the bug affects other BMI, BMI2, and ABM instructions, but I have only completely verified incorrect execution of SHLX. + +I hit this today on QEMU head. The problem appears to crop up when: + + 1. Decoding a VEX instruction (see [1]) that uses the 0x66 mandatory + prefix; and + + 2. The OSFXSR bit in CR4 is clear (that is, SSE is disabled) + +This means that x86_64 instructions such as: + + c4 e2 f9 f7 c0 shlxq %rax, %rax, %rax + +fail. Similar instructions the use a different mandatory prefix +(such as `shrxq`, which uses prefix 0xf2) work fine. + +Most operating systems presumably set the OSFXSR bit fairly early on, which I +guess is why this problem isn't likely to be seen except in low-level or early +boot code. + +The culprit appears to be the block of code in `gen_sse` [2]: + + if (is_xmm + && !(s->flags & HF_OSFXSR_MASK) + && ((b != 0x38 && b != 0x3a) || (s->prefix & PREFIX_DATA))) { + goto unknown_op; + } + +Removing the check `... || (s->prefix & DATA_DATA)` causes QEMU to correctly +translate the instruction, and allows doug16k's test above to pass. + +I must confess, I'm not clear what this clause was testing for. My best guess +is that early code (e.g. 4242b1bd8ac) required it to avoid accessing invalid +opcode tables, but we seem to be handling that more gracefully today (e.g. +[3]), so I suspect it is no longer needed. + +[1]: https://wiki.osdev.org/X86-64_Instruction_Encoding#VEX.2FXOP_opcodes +[2]: https://github.com/qemu/qemu/blob/6b63d126121a9535784003924fcb67f574a6afc0/target/i386/tcg/translate.c#L3078 +[3]: https://github.com/qemu/qemu/blob/6b63d126121a9535784003924fcb67f574a6afc0/target/i386/tcg/translate.c#L3696-L3700 + + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + +Ah, never mind, posted the text before seeing that it still affects people in 2021 ... so I'm not changing this bug to "Incomplete". Sorry for the noise. + +Fix has been included here: +https://gitlab.com/qemu-project/qemu/-/commit/51909241d26fe6fe18a + diff --git a/results/classifier/semantic-bugs/graphic/1641637 b/results/classifier/semantic-bugs/graphic/1641637 new file mode 100644 index 000000000..dff815184 --- /dev/null +++ b/results/classifier/semantic-bugs/graphic/1641637 @@ -0,0 +1,743 @@ +graphic: 0.957 +instruction: 0.942 +semantic: 0.931 +mistranslation: 0.910 +other: 0.901 +assembly: 0.881 +device: 0.878 +socket: 0.874 +KVM: 0.857 +boot: 0.846 +network: 0.842 +vnc: 0.842 + +incorrect illegal SSE3 instructions reporting on x86_64 + +Hi all, we found 28 differently encoded illegal SSE3 instructions reporting on the most recent x86_64 user mode linux qemu (version 2.7.0). We believe these reporting should be incorrect because the same code can be executed on a real machine. The instructions are the following: + +pabsb %mm0, %mm1 +pabsb %xmm0, %xmm1 +pabsd %mm0, %mm1 +pabsd %xmm0, %xmm1 +pabsw %mm0, %mm1 +pabsw %xmm0, %xmm1 +phaddd %mm0, %mm1 +phaddd %xmm0, %xmm1 +phaddsw %mm0, %mm1 +phaddsw %xmm0, %xmm1 +phaddw %mm0, %mm1 +phaddw %xmm0, %xmm1 +phsubd %mm0, %mm1 +phsubd %xmm0, %xmm1 +phsubsw %mm0, %mm1 +phsubsw %xmm0, %xmm1 +phsubw %mm0, %mm1 +phsubw %xmm0, %xmm1 +pmaddubsw %mm0, %mm1 +pmaddubsw %xmm0, %xmm1 +pmulhrsw %mm0, %mm1 +pmulhrsw %xmm0, %xmm1 +psignb %mm0, %mm1 +psignb %xmm0, %xmm1 +psignd %mm0, %mm1 +psignd %xmm0, %xmm1 +psignw %mm0, %mm1 +psignw %xmm0, %xmm1 + +The following is the proof of code + +/********** Beginning of bug 1.c: pabsb %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("pabsb %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 1.c **********/ + + +/********** Beginning of bug 2.c: pabsb %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("pabsb %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 2.c **********/ + + +/********** Beginning of bug 3.c: pabsd %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("pabsd %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 3.c **********/ + + +/********** Beginning of bug 4.c: pabsd %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("pabsd %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 4.c **********/ + + +/********** Beginning of bug 5.c: pabsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("pabsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 5.c **********/ + + +/********** Beginning of bug 6.c: pabsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("pabsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 6.c **********/ + + +/********** Beginning of bug 7.c: phaddd %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phaddd %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 7.c **********/ + + +/********** Beginning of bug 8.c: phaddd %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phaddd %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 8.c **********/ + + +/********** Beginning of bug 9.c: phaddsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phaddsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 9.c **********/ + + +/********** Beginning of bug 10.c: phaddsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phaddsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 10.c **********/ + + +/********** Beginning of bug 11.c: phaddw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phaddw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 11.c **********/ + + +/********** Beginning of bug 12.c: phaddw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phaddw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 12.c **********/ + + +/********** Beginning of bug 13.c: phsubd %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phsubd %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 13.c **********/ + + +/********** Beginning of bug 14.c: phsubd %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phsubd %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 14.c **********/ + + +/********** Beginning of bug 15.c: phsubsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phsubsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 15.c **********/ + + +/********** Beginning of bug 16.c: phsubsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phsubsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 16.c **********/ + + +/********** Beginning of bug 17.c: phsubw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phsubw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 17.c **********/ + + +/********** Beginning of bug 18.c: phsubw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phsubw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 18.c **********/ + + +/********** Beginning of bug 19.c: pmaddubsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char i2[0x10]; +unsigned char i3[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i2)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i3)));; + asm("pmaddubsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 19.c **********/ + + +/********** Beginning of bug 20.c: pmaddubsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char i2[0x10]; +unsigned char i3[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i2)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i3)));; + asm("pmaddubsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 20.c **********/ + + +/********** Beginning of bug 21.c: pmulhrsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("pmulhrsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 21.c **********/ + + +/********** Beginning of bug 22.c: pmulhrsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("pmulhrsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 22.c **********/ + + +/********** Beginning of bug 23.c: psignb %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("psignb %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 23.c **********/ + + +/********** Beginning of bug 24.c: psignb %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("psignb %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 24.c **********/ + + +/********** Beginning of bug 25.c: psignd %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("psignd %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 25.c **********/ + + +/********** Beginning of bug 26.c: psignd %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("psignd %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 26.c **********/ + + +/********** Beginning of bug 27.c: psignw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("psignw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 27.c **********/ + + +/********** Beginning of bug 28.c: psignw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("psignw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 28.c **********/ + +For any of the above code, when compiled into x86-64 binary code with gcc, qemu reports the illegal instructions bug. However, these can be correctly executed on a real machine. For example, + +$ gcc 28.c -o 28 +$ qemu-x86_64 ./28 +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction +$ ./28 +00000000000000000000000000000000 + +Some information about the system: + +$ qemu-x86_64 --version +qemu-x86_64 version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers +$ uname -a +Linux cgos-System-Product-Name 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux +$ gcc --version +gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4 +Copyright (C) 2013 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + + +Thanks! + +Hi Jie, + +I can reproduce this by single-stepping through the bug1 testing code using gdb, and SIGILL was encountered when executing the pabsb SSE3 instruction. Maybe it was due to QEMU's translator, I'll look further into it. + +Hi Jie, + +Seems that the problem was caused by not specifying the cpu model when running QEMU. +when running +qemu-x86_64 ./28 +QEMU would recognize the cpu model as "qemu64", which act like a cpu doesn't support advanced instruction sets like SSSE3. To workaround, you can run +qemu-x86_86 -cpu core2duo ./28 +The cpu specifications could be found at target-i386/cpu.c. + +I haven't tested through all the cases yet, but I'm almost sure that was the problem, for all your test cases used SSSE3 instructions or something alike. +Please let me know if there are some more exceptions, thanks! + diff --git a/results/classifier/semantic-bugs/graphic/1722 b/results/classifier/semantic-bugs/graphic/1722 new file mode 100644 index 000000000..4dcbfc5fe --- /dev/null +++ b/results/classifier/semantic-bugs/graphic/1722 @@ -0,0 +1,100 @@ +graphic: 0.963 +semantic: 0.957 +device: 0.956 +mistranslation: 0.954 +other: 0.948 +vnc: 0.944 +instruction: 0.943 +assembly: 0.934 +network: 0.909 +socket: 0.896 +boot: 0.813 +KVM: 0.808 + +qemu-mipsn32: Illegal Instruction at `exts` instruction +Description of problem: +Run with the command above, I got this error: + +``` +qemu-mipsn32 run +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction (core dumped) +``` + +I then tried to debug the program with qemu option `-g 1234` and know that + +``` +$ gdb-multiarch run +... + +pwndbg> target remote 0:1234 +... + +pwndbg> c +Continuing. + +Program received signal SIGILL, Illegal instruction. +0x3f7d2434 in ?? () from /lib32/ld.so.1 +warning: GDB can't find the start of the function at 0x3f7d2434. +x/10i + +pwndbg> x/10i $pc +=> 0x3f7d2434: 0x7047f03a + 0x3f7d2438: lui a3,0x7000 + 0x3f7d243c: ori a3,a3,0x5e + 0x3f7d2440: b 0x3f7d241c + 0x3f7d2444: subu v0,a3,v0 + 0x3f7d2448: sltiu a7,a3,-3 + 0x3f7d244c: bnezl a7,0x3f7d246c + 0x3f7d2450: subu a3,a4,v0 + 0x3f7d2454: addiu a3,a3,1 + 0x3f7d2458: li v0,-4 +``` + +So I know the problem is in libc32/ld.so.1. When I dissasemble that file and look at offset 0x4434, it's an `exts` instruction as below: + +``` +$ file /lib32/ld.so.1 +/lib32/ld-2.15.so: ELF 32-bit MSB shared object, MIPS, N32 MIPS64 rel2 version 1 (SYSV), dynamically linked, stripped + +$ ./mips64-n32--glibc--stable-2022.08-1/bin/mips64-buildroot-linux-gnu-objdump -d /lib32/ld.so.1 | less + ... + 4434: 7047f03a exts a3,v0,0x0,0x1e + 4438: 3c077000 lui a3,0x7000 + 443c: 34e7005e ori a3,a3,0x5e + 4440: 1000fff6 b 441c + 4444: 00e21023 subu v0,a3,v0 + 4448: 2cebfffd sltiu a7,a3,-3 + 444c: 55600007 bnezl a7,446c + 4450: 01023823 subu a3,a4,v0 + 4454: 24e70001 addiu a3,a3,1 + 4458: 2402fffc li v0,-4 +``` +Steps to reproduce: +1. Download toolchain of mips64-n32 on toolchains.bootlin.com [here](https://toolchains.bootlin.com/releases_mips64-n32.html) +2. Write this c code to file `run.c`: + +```c +#include + +int main(){ + puts("hello world"); + while (1); +} +``` + +3. Compile file run.c with downloaded toolchain: + +``` +mips64-n32--glibc--stable-2022.08-1/bin/mips64-buildroot-linux-gnu-gcc run.c -o run +``` + +> Step 1, 2 and 3 can be skip if you download the attached `run` file. + +4. Download the attached ld +5. Make new dir at `/lib32` and move the file ld to `/lib32` +6. Run command `qemu-mipsn32 run` +Additional information: +[ld-2.15.so](/uploads/95f4da26e42d43d39aa2350670134bb5/ld-2.15.so) + +[run](/uploads/01be57442009a75cf2f59cbcf53474f4/run) diff --git a/results/classifier/semantic-bugs/graphic/2595 b/results/classifier/semantic-bugs/graphic/2595 new file mode 100644 index 000000000..e0e1afbe0 --- /dev/null +++ b/results/classifier/semantic-bugs/graphic/2595 @@ -0,0 +1,148 @@ +graphic: 0.959 +other: 0.957 +semantic: 0.951 +mistranslation: 0.934 +device: 0.919 +assembly: 0.915 +socket: 0.901 +boot: 0.896 +instruction: 0.895 +vnc: 0.886 +network: 0.861 +KVM: 0.850 + +Incorrect behavior with 64-bit element SDOT and UDOT instructions on ARM SVE when sve-default-vector-length>=64 +Description of problem: +The behavior of SDOT and UDOT instructions are incorrect when the Zresult.D register is used, which is the 64-bit svdot_lane\_{s,u}64 intrinsic in ACLE. + +I have tested the same code using [Arm Instruction Emulator](https://developer.arm.com/Tools%20and%20Software/Arm%20Instruction%20Emulator) (which is deprecated though) and gem5 which produced correct result, I believe that the SDOT and UDOT implementation in qemu is incorrect. +Steps to reproduce: +1. Get Arm Gnu toolchain from [Arm GNU Toolchain Downloads – Arm Developer](https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads), for x86 Linux hosts, download arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz and extract it. Alternatively, use any compiler that is able to cross compile for armv8.2-a+sve targets. +2. Compile the following program with these compiler arguments + + ``` + arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc -O3 -march=armv8.2-a+sve dot_lane.c -o dot_lane + ``` + + ```c + #include + #include + + int64_t a[32] = { 0 }; + int16_t b[128]; + int16_t c[128]; + int64_t r[32]; + int64_t expected_r[32]; + + #define IMM 0 + + int main(void) + { + for (size_t i = 0; i < 128; i++) { + b[i] = 1; + c[i] = i / 4; + } + + svint64_t av = svld1(svptrue_b64(), a); + svint16_t bv = svld1(svptrue_b16(), b); + svint16_t cv = svld1(svptrue_b16(), c); + + svint64_t result = svdot_lane_s64(av, bv, cv, IMM); + + svst1(svptrue_b64(), r, result); + + for (size_t i = 0; i < svcntd(); i++) { + expected_r[i] = + (int64_t)b[i * 4 + 0] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 0] + + (int64_t)b[i * 4 + 1] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 1] + + (int64_t)b[i * 4 + 2] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 2] + + (int64_t)b[i * 4 + 3] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 3] + + a[i]; + } + + printf("%12s", "r: "); + for (size_t i = 0; i < svcntd(); i++) { + printf("%4ld", r[i]); + } + printf("\n"); + printf("%12s", "expected_r: "); + for (size_t i = 0; i < svcntd(); i++) { + printf("%4ld", expected_r[i]); + } + printf("\n\t\t"); + for (size_t i = 0; i < svcntd(); i++) { + if (r[i] != expected_r[i]) { + printf("%4c", '^'); + } else { + printf("%4c", ' '); + } + } + printf("\n"); + printf("idx:\t\t"); + for (size_t i = 0; i < svcntd(); i++) { + if (r[i] != expected_r[i]) { + printf("%4d", i); + } else { + printf("%4c", ' '); + } + } + printf("\n"); + + return 0; + } + ``` +3. Execute it with the following commands: + + ``` + qemu-aarch64 -cpu max,sve-default-vector-length=16 -L arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu/bin/../aarch64-none-linux-gnu/libc dot_lane + ``` + + Change the value of `sve-default-vector-length` to 32, 64, 128, 256 and observe the outputs, we should see that for `sve-default-vector-length` \>= 64, the result is incorrect. + + `sve-default-vector-length=16` + + ``` + r: 0 0 + expected_r: 0 0 + + idx: + ``` + + `sve-default-vector-length=32` + + ``` + r: 0 0 8 8 + expected_r: 0 0 8 8 + + idx: + ``` + + `sve-default-vector-length=64` + + ``` + r: 0 0 8 8 8 8 24 24 + expected_r: 0 0 8 8 16 16 24 24 + ^ ^ + idx: 4 5 + ``` + + `sve-default-vector-length=128` + + ``` + r: 0 0 8 8 8 8 24 24 24 24 40 40 40 40 56 56 + expected_r: 0 0 8 8 16 16 24 24 32 32 40 40 48 48 56 56 + ^ ^ ^ ^ ^ ^ + idx: 4 5 8 9 12 13 + ``` + + `sve-default-vector-length=256` + + ``` + r: 0 0 8 8 8 8 24 24 24 24 40 40 40 40 56 56 56 56 72 72 72 72 88 88 88 88 104 104 104 104 120 120 + expected_r: 0 0 8 8 16 16 24 24 32 32 40 40 48 48 56 56 64 64 72 72 80 80 88 88 96 96 104 104 112 112 120 120 + ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ + idx: 4 5 8 9 12 13 16 17 20 21 24 25 28 29 + ``` +4. By passing `-S` to the compiler, we can see that sdot (or udot if using `svdot_lane_u64()`) is produced in assembly (`sdot z0.d, z1.h, z2.h[0]`), which is correct behavior according to [Intrinsics – Arm Developer](https://developer.arm.com/architectures/instruction-sets/intrinsics/svdot_lane%5B_s64%5D). +Additional information: + diff --git a/results/classifier/semantic-bugs/graphic/2672 b/results/classifier/semantic-bugs/graphic/2672 new file mode 100644 index 000000000..3a1f3f9a5 --- /dev/null +++ b/results/classifier/semantic-bugs/graphic/2672 @@ -0,0 +1,33 @@ +graphic: 0.901 +instruction: 0.868 +device: 0.714 +vnc: 0.423 +socket: 0.247 +boot: 0.240 +mistranslation: 0.222 +semantic: 0.216 +network: 0.205 +assembly: 0.203 +other: 0.148 +KVM: 0.040 + +Skipping a jal instruction in riscv64 baremetal emulation +Description of problem: +The binary contains an illegal instruction after a jal. Normally the jal should be taken but the illegal instructi[aia_tests2.elf](/uploads/b8b646b01d7bcc15b51c36ddbffacac7/aia_tests2.elf)on next to the jal is executed generating and illegal instruction exception: + +``` +0x80006070: 00200513 addi a0,zero,2 +0x80006074: 89cff0ef jal ra,-3940 # 0x80005110 + +---------------- +IN: _Z15int_switch_modehh +0x80006078: 0000 illegal + +---------------- +IN: mtvec_table +0x8000e600: 64d0406f j 20044 # 0x8001344c +``` +Steps to reproduce: +1. Execute the same binary with QEMU. +Additional information: + diff --git a/results/classifier/semantic-bugs/graphic/904308 b/results/classifier/semantic-bugs/graphic/904308 new file mode 100644 index 000000000..a32657642 --- /dev/null +++ b/results/classifier/semantic-bugs/graphic/904308 @@ -0,0 +1,201 @@ +graphic: 0.975 +other: 0.967 +assembly: 0.959 +device: 0.954 +semantic: 0.949 +instruction: 0.941 +boot: 0.934 +socket: 0.929 +network: 0.906 +vnc: 0.879 +mistranslation: 0.833 +KVM: 0.820 + +x86: BT/BTS/BTR/BTC: ZF flag is unaffected + +Hello! + +Bug was found in qemu.git. +See target-i386/translate.c: + + case 0x1ba: /* bt/bts/btr/btc Gv, im */ + ot = dflag + OT_WORD; + modrm = ldub_code(s->pc++); + op = (modrm >> 3) & 7; + mod = (modrm >> 6) & 3; + rm = (modrm & 7) | REX_B(s); + if (mod != 3) { + s->rip_offset = 1; + gen_lea_modrm(s, modrm, ®_addr, &offset_addr); + gen_op_ld_T0_A0(ot + s->mem_index); + } else { + gen_op_mov_TN_reg(ot, 0, rm); + } + /* load shift */ + val = ldub_code(s->pc++); + gen_op_movl_T1_im(val); + if (op < 4) + goto illegal_op; + op -= 4; + goto bt_op; + case 0x1a3: /* bt Gv, Ev */ + op = 0; + goto do_btx; + case 0x1ab: /* bts */ + op = 1; + goto do_btx; + case 0x1b3: /* btr */ + op = 2; + goto do_btx; + case 0x1bb: /* btc */ + op = 3; + do_btx: + ot = dflag + OT_WORD; + modrm = ldub_code(s->pc++); + reg = ((modrm >> 3) & 7) | rex_r; + mod = (modrm >> 6) & 3; + rm = (modrm & 7) | REX_B(s); + gen_op_mov_TN_reg(OT_LONG, 1, reg); + if (mod != 3) { + gen_lea_modrm(s, modrm, ®_addr, &offset_addr); + /* specific case: we need to add a displacement */ + gen_exts(ot, cpu_T[1]); + tcg_gen_sari_tl(cpu_tmp0, cpu_T[1], 3 + ot); + tcg_gen_shli_tl(cpu_tmp0, cpu_tmp0, ot); + tcg_gen_add_tl(cpu_A0, cpu_A0, cpu_tmp0); + gen_op_ld_T0_A0(ot + s->mem_index); + } else { + gen_op_mov_TN_reg(ot, 0, rm); + } + bt_op: + tcg_gen_andi_tl(cpu_T[1], cpu_T[1], (1 << (3 + ot)) - 1); + switch(op) { + case 0: + tcg_gen_shr_tl(cpu_cc_src, cpu_T[0], cpu_T[1]); + tcg_gen_movi_tl(cpu_cc_dst, 0); <<<<<<<<<<<<<<<<<<<<<< always set zf + break; + case 1: + tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]); + tcg_gen_movi_tl(cpu_tmp0, 1); + tcg_gen_shl_tl(cpu_tmp0, cpu_tmp0, cpu_T[1]); + tcg_gen_or_tl(cpu_T[0], cpu_T[0], cpu_tmp0); + break; + case 2: + tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]); + tcg_gen_movi_tl(cpu_tmp0, 1); + tcg_gen_shl_tl(cpu_tmp0, cpu_tmp0, cpu_T[1]); + tcg_gen_not_tl(cpu_tmp0, cpu_tmp0); + tcg_gen_and_tl(cpu_T[0], cpu_T[0], cpu_tmp0); + break; + default: + case 3: + tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]); + tcg_gen_movi_tl(cpu_tmp0, 1); + tcg_gen_shl_tl(cpu_tmp0, cpu_tmp0, cpu_T[1]); + tcg_gen_xor_tl(cpu_T[0], cpu_T[0], cpu_tmp0); + break; + } + s->cc_op = CC_OP_SARB + ot; + if (op != 0) { + if (mod != 3) + gen_op_st_T0_A0(ot + s->mem_index); + else + gen_op_mov_reg_T0(ot, rm); + tcg_gen_mov_tl(cpu_cc_src, cpu_tmp4); + tcg_gen_movi_tl(cpu_cc_dst, 0); <<<<<<<<<<<<<<<<<<<<<< always set zf + } + break; + +always set zf... + +There is fixed patch. + + + +It would be helpful if you could submit patches in line with the guidance documented on the wiki: +http://wiki.qemu.org/Contribute/SubmitAPatch + +In particular, patches should be sent to the mailing list in the right format, and we cannot apply any patch without a signed-off-by line. + +Thanks. + + +On 12/14/2011 06:08 PM, malc wrote: +> On Wed, 14 Dec 2011, Daniil Troshkov wrote: +> +> > Public bug reported: +> > +> > Hello! +> > +> > Bug was found in qemu.git. +> > See target-i386/translate.c: +> > +> +> [..snip..] +> +> Intel's documentation doesn't cover this, AMD's says that ZF is undefined, so, +> question is: why do you think QEMU is wrong here? + +The Intel documentation states that ZF is unaffected. + +-- +error compiling committee.c: too many arguments to function + + + +On 12/14/2011 06:22 PM, malc wrote: +> On Wed, 14 Dec 2011, Avi Kivity wrote: +> +> > On 12/14/2011 06:08 PM, malc wrote: +> > > On Wed, 14 Dec 2011, Daniil Troshkov wrote: +> > > +> > > > Public bug reported: +> > > > +> > > > Hello! +> > > > +> > > > Bug was found in qemu.git. +> > > > See target-i386/translate.c: +> > > > +> > > +> > > [..snip..] +> > > +> > > Intel's documentation doesn't cover this, AMD's says that ZF is undefined, so, +> > > question is: why do you think QEMU is wrong here? +> > +> > The Intel documentation states that ZF is unaffected. +> > +> +> Right, i was blind, anyways, AMD disagrees. +> + +Best to be conservative here. + +-- +error compiling committee.c: too many arguments to function + + + +>Best to be conservative here. +What is it means? + +On 12/14/2011 06:33 PM, malc wrote: +> > +> > Best to be conservative here. +> > +> +> Point being, any code that relies on it being in any particular state is +> broken (potentially, on AMD chips) + +Yes of course, but not all software is written to be portable. Probably +the only thing that will break here is a vendor test suite, but even so, +if we can comply to the spec, we should. + +-- +error compiling committee.c: too many arguments to function + + + +Looking at the previous comments ... is there anything left to do here? Or can we close this bug nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/semantic-bugs/instruction/1057 b/results/classifier/semantic-bugs/instruction/1057 new file mode 100644 index 000000000..5815e3deb --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1057 @@ -0,0 +1,36 @@ +instruction: 0.938 +semantic: 0.521 +device: 0.491 +other: 0.379 +assembly: 0.282 +graphic: 0.233 +network: 0.207 +mistranslation: 0.133 +socket: 0.065 +KVM: 0.060 +vnc: 0.056 +boot: 0.050 + +AArch64: ISV is set to 1 in ESR_EL2 when taking a data abort with post-indexed instructions +Description of problem: +I think that I have a Qemu bug in my hands, but, I could still be missing something. Consider the following instruction: +`0x0000000000000000: C3 44 00 B8 str w3, [x6], #4` + +notice the last #4, I think this is what we would call a post-indexed instruction (falls into the category of instructions with writeback). As I understand it, those instructions should not have ISV=1 in ESR_EL2 when faulting. + +Here is the relevant part of the manual: + +``` +For other faults reported in ESR_EL2, ISV is 0 except for the following stage 2 aborts: +• AArch64 loads and stores of a single general-purpose register (including the register specified with 0b11111, including those with Acquire/Release semantics, but excluding Load Exclusive or Store Exclusive and excluding those with writeback). +``` + +However, I can see that Qemu sets ISV to 1 here. The ARM hardware that I tested gave me a value of ISV=0 for similar instructions. + +Another example of instruction: `0x00000000000002f8: 01 1C 40 38 ldrb w1, [x0, #1]!` +Steps to reproduce: +1. Run some hypervisor in EL2 +2. Create a guest running at EL1 that executes one of the mentioned instructions (and make the instruction fault by writing to some unmapped page in SLP) +3. Observe the value of ESR_EL2 on data abort + +Unfortunately, I cannot provide an image to reproduce this (the software is not open-source). But, I would be happy to help test a patch. diff --git a/results/classifier/semantic-bugs/instruction/1062 b/results/classifier/semantic-bugs/instruction/1062 new file mode 100644 index 000000000..67d2da1cb --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1062 @@ -0,0 +1,29 @@ +instruction: 0.925 +graphic: 0.906 +assembly: 0.851 +device: 0.826 +mistranslation: 0.798 +socket: 0.727 +network: 0.651 +semantic: 0.646 +vnc: 0.606 +other: 0.562 +boot: 0.478 +KVM: 0.082 + +AArch64: SCR_EL3.RW behaves incorrectly for CPUs with no AArch32 +Description of problem: +In the ARM DDI 0487G.a, D13-3572, the SCR_EL3.RW bit is defined as RAO/WI if both EL2 and EL1 don't support Aarch32. However, the function `scr_write` in `target/arm/helper.c` does not reflect this behavior, even though it checks for Aarch32 EL1 support. + +This would break this EL3 code, which should run on cpu reset to attempt to return to EL1: +```asm +mov x1, #((1<<0)|(1<<2)|(1<<6)|(1<<7)|(1<<8)|(1<<9)) ; EL1h, DAIF masked +mov SPSR_EL3, x1 +adr x1, 1f +msr ELR_EL3, x1 +eret +1: +; something something +``` +Additional information: + diff --git a/results/classifier/semantic-bugs/instruction/1079080 b/results/classifier/semantic-bugs/instruction/1079080 new file mode 100644 index 000000000..c3723248d --- /dev/null +++ b/results/classifier/semantic-bugs/instruction/1079080 @@ -0,0 +1,43 @@ +instruction: 0.967 +graphic: 0.903 +device: 0.901 +semantic: 0.833 +network: 0.755 +socket: 0.707 +vnc: 0.648 +boot: 0.648 +other: 0.637 +mistranslation: 0.619 +assembly: 0.187 +KVM: 0.100 + +ARM instruction "srs" wrong behaviour + +Quote from ARM Architecture Reference Manual ARMv7-A and ARMv7-R : +"Store Return State stores the LR and SPSR of the current mode to the stack of a specified mode" + +Problem: +When executing this instruction, the register stored is CPSR instead of SPSR. + +Context: +Using QEMU 1.2.0 to simulate a Zynq application (processor Cortex-a9 mpcore) with the following command line: +qemu-system-arm -M xilinx-zynq-a9 -m 512 -serial null -serial mon:stdio -dtb /home/vcesson/workspace/xilinx_zynq.dtb -kernel install/tests/io/serial/current/tests/serial2 -S -s -nographic + +It looks like this is only a problem in Thumb mode; the equivalent bug in ARM mode was fixed in commit c67b6b71 back in 2009. + +Can you make the test case dtb and image available? That would help in testing... + + + + + + +Thanks -- I've submitted a patch which fixes this: http://patchwork.ozlabs.org/patch/220748/ + +If you'd like to give me a name/email [format "Full Name