diff options
62 files changed, 4289 insertions, 0 deletions
diff --git a/results/classifier/semantic-bugs-usermode/test/1245543 b/results/classifier/semantic-bugs-usermode/test/1245543 new file mode 100644 index 000000000..99966ab81 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1245543 @@ -0,0 +1,43 @@ +instruction: 0.966 +other: 0.798 +device: 0.770 +semantic: 0.629 +socket: 0.619 +network: 0.548 +vnc: 0.529 +graphic: 0.455 +boot: 0.437 +mistranslation: 0.417 +assembly: 0.269 +KVM: 0.262 + +Wrong implementation of SSE4.1 pmovzxbw and similar instructions + +QEMU 1.5.0 (and git version, as far as I can tell from the source code) has incorrect implementation of pmovzxbw and similar SSE4.1 instructions. The instruction zero-extends the first 8 8-bit elements of a vector to 16bit vector and puts them to another vector. The current implementation applies this operation only to the first element and zeros out the rest. + +To verify, compile the attached program for SSE4.1 (g++ -msse4.1 cvtint.cc). On real hardware, it produces the following output: + +$ ./a.out +1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 + +On QEMU, the output is as follows: + +$ ./a.out +1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 + +QEMU is invoked as: + +qemu-system-x86_64 \ + -M pc -cpu Haswell,+sse4.1,+avx,+avx2,+fma,enforce -m 512 \ + -serial stdio -no-reboot \ + -kernel vmlinuz -initrd initrd.img \ + -netdev user,id=user.0 -device rtl8139,netdev=user.0 -redir tcp:2222::22 \ + -hda ubuntu-amd64.ext3 \ + --append "rw console=tty root=/dev/sda" + + + +Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/semantic-bugs-usermode/test/1267955 b/results/classifier/semantic-bugs-usermode/test/1267955 new file mode 100644 index 000000000..fe1635901 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1267955 @@ -0,0 +1,187 @@ +other: 0.979 +assembly: 0.959 +device: 0.954 +KVM: 0.953 +vnc: 0.950 +instruction: 0.947 +semantic: 0.945 +graphic: 0.944 +network: 0.942 +mistranslation: 0.913 +socket: 0.912 +boot: 0.895 + +[i386] Parity Flag Not Set On xor %eax,%eax + +Tested against qemu-1.7.0 as well as qemu-1.7.50 on Debian Sid + +Steps To Reproduce + +$ cat > prog.hex << EOF + +7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 +02 00 03 00 01 00 00 00 54 80 04 08 34 00 00 00 +00 00 00 00 00 00 00 00 34 00 20 00 01 00 28 00 +00 00 00 00 01 00 00 00 00 00 00 00 00 80 04 08 +00 80 04 08 76 00 00 00 76 00 00 00 05 00 00 00 +00 10 00 00 + +31 c0 +9c + +b8 04 00 00 00 +bb 01 00 00 00 +89 e1 +ba 04 00 00 00 +cd 80 + +b8 01 00 00 00 +bb 00 00 00 00 +cd 80 + +EOF + +$ xxd -p -r prog.hex > prog +$ chmod 700 prog + +$ ./prog | hexdump -vC +00000000 46 02 00 00 |F...| +00000004 + +$ qemu-i386 ./prog | hexdump -vC +00000000 42 02 00 00 |B...| +00000004 + +On the other hand if [xor %eax, %eax] (31 c0) is replaced with sub %eax,%eax (29 c0), then the parity flag is set correctly. + +Parity should be set for a zero result. + +Signed-off-by: Richard Henderson <email address hidden> +--- + target-i386/cc_helper.c | 2 +- + target-i386/translate.c | 2 +- + 2 files changed, 2 insertions(+), 2 deletions(-) + +diff --git a/target-i386/cc_helper.c b/target-i386/cc_helper.c +index ee04092..05dd12b 100644 +--- a/target-i386/cc_helper.c ++++ b/target-i386/cc_helper.c +@@ -103,7 +103,7 @@ target_ulong helper_cc_compute_all(target_ulong dst, target_ulong src1, + case CC_OP_EFLAGS: + return src1; + case CC_OP_CLR: +- return CC_Z; ++ return CC_Z | CC_P; + + case CC_OP_MULB: + return compute_all_mulb(dst, src1); +diff --git a/target-i386/translate.c b/target-i386/translate.c +index b0f2279..34f35e7 100644 +--- a/target-i386/translate.c ++++ b/target-i386/translate.c +@@ -748,7 +748,7 @@ static void gen_compute_eflags(DisasContext *s) + return; + } + if (s->cc_op == CC_OP_CLR) { +- tcg_gen_movi_tl(cpu_cc_src, CC_Z); ++ tcg_gen_movi_tl(cpu_cc_src, CC_Z | CC_P); + set_cc_op(s, CC_OP_EFLAGS); + return; + } +-- +1.8.4.2 + + + +On Fri, Jan 10, 2014 at 12:39:56PM -0800, Richard Henderson wrote: +> Parity should be set for a zero result. +> +> Signed-off-by: Richard Henderson <email address hidden> + +Reviewed-by: Edgar E. Iglesias <email address hidden> + + +> --- +> target-i386/cc_helper.c | 2 +- +> target-i386/translate.c | 2 +- +> 2 files changed, 2 insertions(+), 2 deletions(-) +> +> diff --git a/target-i386/cc_helper.c b/target-i386/cc_helper.c +> index ee04092..05dd12b 100644 +> --- a/target-i386/cc_helper.c +> +++ b/target-i386/cc_helper.c +> @@ -103,7 +103,7 @@ target_ulong helper_cc_compute_all(target_ulong dst, target_ulong src1, +> case CC_OP_EFLAGS: +> return src1; +> case CC_OP_CLR: +> - return CC_Z; +> + return CC_Z | CC_P; +> +> case CC_OP_MULB: +> return compute_all_mulb(dst, src1); +> diff --git a/target-i386/translate.c b/target-i386/translate.c +> index b0f2279..34f35e7 100644 +> --- a/target-i386/translate.c +> +++ b/target-i386/translate.c +> @@ -748,7 +748,7 @@ static void gen_compute_eflags(DisasContext *s) +> return; +> } +> if (s->cc_op == CC_OP_CLR) { +> - tcg_gen_movi_tl(cpu_cc_src, CC_Z); +> + tcg_gen_movi_tl(cpu_cc_src, CC_Z | CC_P); +> set_cc_op(s, CC_OP_EFLAGS); +> return; +> } +> -- +> 1.8.4.2 +> +> + + +Quoting Richard Henderson (2014-01-10 14:39:56) +> Parity should be set for a zero result. +> +> Signed-off-by: Richard Henderson <email address hidden> + +ping for 1.7.1 + +> --- +> target-i386/cc_helper.c | 2 +- +> target-i386/translate.c | 2 +- +> 2 files changed, 2 insertions(+), 2 deletions(-) +> +> diff --git a/target-i386/cc_helper.c b/target-i386/cc_helper.c +> index ee04092..05dd12b 100644 +> --- a/target-i386/cc_helper.c +> +++ b/target-i386/cc_helper.c +> @@ -103,7 +103,7 @@ target_ulong helper_cc_compute_all(target_ulong dst, target_ulong src1, +> case CC_OP_EFLAGS: +> return src1; +> case CC_OP_CLR: +> - return CC_Z; +> + return CC_Z | CC_P; +> +> case CC_OP_MULB: +> return compute_all_mulb(dst, src1); +> diff --git a/target-i386/translate.c b/target-i386/translate.c +> index b0f2279..34f35e7 100644 +> --- a/target-i386/translate.c +> +++ b/target-i386/translate.c +> @@ -748,7 +748,7 @@ static void gen_compute_eflags(DisasContext *s) +> return; +> } +> if (s->cc_op == CC_OP_CLR) { +> - tcg_gen_movi_tl(cpu_cc_src, CC_Z); +> + tcg_gen_movi_tl(cpu_cc_src, CC_Z | CC_P); +> set_cc_op(s, CC_OP_EFLAGS); +> return; +> } +> -- +> 1.8.4.2 + + + +Fix had been included here: +http://git.qemu.org/?p=qemu.git;a=commitdiff;h=d2fe51bda8adf33d07c21 +==> Closing + diff --git a/results/classifier/semantic-bugs-usermode/test/1328996 b/results/classifier/semantic-bugs-usermode/test/1328996 new file mode 100644 index 000000000..b48ededc8 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1328996 @@ -0,0 +1,25 @@ +instruction: 0.932 +device: 0.871 +mistranslation: 0.798 +graphic: 0.713 +semantic: 0.618 +network: 0.577 +socket: 0.504 +other: 0.463 +vnc: 0.395 +boot: 0.376 +assembly: 0.134 +KVM: 0.107 + +[AArch64] - blr x30 is handled incorrectly + +Whenever x30 is used as the operand for blr, the result will be incorrect. There is no restriction on using x30 (LR) with the blr instruction in the ARMv8 manual. There are two statically linked 64-bit executables in files.tar.gz: good and bad. The executable "good" uses "blr x9", and the output is what is expected: "func". The executable "bad" uses "blr x30" and nothing is printed out. It prints "func" on the actual device. + + + +I think this should already be fixed in master by commit 1b505f93bcf60 (about a month ago). Can you try a newer QEMU build, please? + + + +Thanks, Peter. I just built the latest development build, and it now passes. Sorry for the false alarm. + diff --git a/results/classifier/semantic-bugs-usermode/test/1370 b/results/classifier/semantic-bugs-usermode/test/1370 new file mode 100644 index 000000000..c7f125abf --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1370 @@ -0,0 +1,26 @@ +semantic: 0.986 +instruction: 0.949 +graphic: 0.878 +assembly: 0.842 +device: 0.806 +socket: 0.681 +vnc: 0.658 +network: 0.606 +boot: 0.546 +mistranslation: 0.502 +other: 0.474 +KVM: 0.210 + +x86 BLSI and BLSR semantic bug +Description of problem: +The result of instruction BLSI and BLSR is different from the CPU. The value of CF is different. +Steps to reproduce: +1. Compile this code +``` +void main() { + asm("blsi rax, rbx"); +} +``` +2. Execute and compare the result with the CPU. The value of `CF` is exactly the opposite. This problem happens with BLSR, too. +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/semantic-bugs-usermode/test/1371 b/results/classifier/semantic-bugs-usermode/test/1371 new file mode 100644 index 000000000..16aca0c8f --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1371 @@ -0,0 +1,32 @@ +semantic: 0.995 +instruction: 0.970 +assembly: 0.852 +graphic: 0.824 +device: 0.665 +mistranslation: 0.491 +boot: 0.468 +vnc: 0.465 +socket: 0.452 +network: 0.307 +other: 0.217 +KVM: 0.064 + +x86 BLSMSK semantic bug +Description of problem: +The result of instruction BLSMSK is different with from the CPU. The value of CF is different. +Steps to reproduce: +1. Compile this code +``` +void main() { + asm("mov rax, 0x65b2e276ad27c67"); + asm("mov rbx, 0x62f34955226b2b5d"); + asm("blsmsk eax, ebx"); +} +``` +2. Execute and compare the result with the CPU. + - CPU + - CF = 0 + - QEMU + - CF = 1 +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/semantic-bugs-usermode/test/1372 b/results/classifier/semantic-bugs-usermode/test/1372 new file mode 100644 index 000000000..a5a86bb81 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1372 @@ -0,0 +1,33 @@ +semantic: 0.995 +instruction: 0.963 +graphic: 0.860 +device: 0.736 +assembly: 0.728 +mistranslation: 0.574 +vnc: 0.420 +boot: 0.411 +socket: 0.263 +network: 0.171 +other: 0.159 +KVM: 0.083 + +x86 BEXTR semantic bug +Description of problem: +The result of instruction BEXTR is different with from the CPU. The value of destination register is different. I think QEMU does not consider the operand size limit. +Steps to reproduce: +1. Compile this code +``` +void main() { + asm("mov rax, 0x17b3693f77fb6e9"); + asm("mov rbx, 0x8f635a775ad3b9b4"); + asm("mov rcx, 0xb717b75da9983018"); + asm("bextr eax, ebx, ecx"); +} +``` +2. Execute and compare the result with the CPU. + - CPU + - RAX = 0x5a + - QEMU + - RAX = 0x635a775a +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/semantic-bugs-usermode/test/1373 b/results/classifier/semantic-bugs-usermode/test/1373 new file mode 100644 index 000000000..d4cf2ba67 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1373 @@ -0,0 +1,33 @@ +semantic: 0.996 +assembly: 0.951 +instruction: 0.948 +graphic: 0.898 +device: 0.784 +vnc: 0.746 +mistranslation: 0.642 +boot: 0.505 +socket: 0.502 +network: 0.373 +other: 0.248 +KVM: 0.113 + +x86 ADOX and ADCX semantic bug +Description of problem: +The result of instruction ADOX and ADCX are different from the CPU. The value of one of EFLAGS is different. +Steps to reproduce: +1. Compile this code +``` +void main() { + asm("push 512; popfq;"); + asm("mov rax, 0xffffffff84fdbf24"); + asm("mov rbx, 0xb197d26043bec15d"); + asm("adox eax, ebx"); +} +``` +2. Execute and compare the result with the CPU. This problem happens with ADCX, too (with CF). + - CPU + - OF = 0 + - QEMU + - OF = 1 +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/semantic-bugs-usermode/test/1374 b/results/classifier/semantic-bugs-usermode/test/1374 new file mode 100644 index 000000000..0db6a0198 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1374 @@ -0,0 +1,35 @@ +semantic: 0.993 +instruction: 0.952 +graphic: 0.807 +device: 0.700 +assembly: 0.661 +boot: 0.382 +vnc: 0.341 +socket: 0.314 +network: 0.272 +mistranslation: 0.272 +other: 0.093 +KVM: 0.044 + +x86 BZHI semantic bug +Description of problem: +The result of instruction BZHI is different from the CPU. The value of destination register and SF of EFLAGS are different. +Steps to reproduce: +1. Compile this code +``` +void main() { + asm("mov rax, 0xb1aa9da2fe33fe3"); + asm("mov rbx, 0x80000000ffffffff"); + asm("mov rcx, 0xf3fce8829b99a5c6"); + asm("bzhi rax, rbx, rcx"); +} +``` +2. Execute and compare the result with the CPU. + - CPU + - RAX = 0x0x80000000ffffffff + - SF = 1 + - QEMU + - RAX = 0xffffffff + - SF = 0 +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/semantic-bugs-usermode/test/1375 b/results/classifier/semantic-bugs-usermode/test/1375 new file mode 100644 index 000000000..3d7746382 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1375 @@ -0,0 +1,32 @@ +semantic: 0.988 +instruction: 0.945 +graphic: 0.792 +device: 0.739 +other: 0.687 +assembly: 0.675 +vnc: 0.520 +network: 0.458 +boot: 0.413 +socket: 0.407 +mistranslation: 0.269 +KVM: 0.247 + +x86 SSE/SSE2/SSE3 instruction semantic bugs with NaN +Description of problem: +The result of SSE/SSE2/SSE3 instructions with NaN is different from the CPU. From Intel manual Volume 1 Appendix D.4.2.2, they defined the behavior of such instructions with NaN. But I think QEMU did not implement this semantic exactly because the byte result is different. +Steps to reproduce: +1. Compile this code +``` +void main() { + asm("mov rax, 0x000000007fffffff; push rax; mov rax, 0x00000000ffffffff; push rax; movdqu XMM1, [rsp];"); + asm("mov rax, 0x2e711de7aa46af1a; push rax; mov rax, 0x7fffffff7fffffff; push rax; movdqu XMM2, [rsp];"); + asm("addsubps xmm1, xmm2"); +} +``` +2. Execute and compare the result with the CPU. This problem happens with other SSE/SSE2/SSE3 instructions specified in the manual, Volume 1 Appendix D.4.2.2. + - CPU + - xmm1[3] = 0xffffffff + - QEMU + - xmm1[3] = 0x7fffffff +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/semantic-bugs-usermode/test/1376 b/results/classifier/semantic-bugs-usermode/test/1376 new file mode 100644 index 000000000..3f75ca7c9 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1376 @@ -0,0 +1,28 @@ +instruction: 0.954 +assembly: 0.897 +device: 0.854 +graphic: 0.701 +vnc: 0.674 +socket: 0.609 +network: 0.505 +boot: 0.489 +semantic: 0.444 +KVM: 0.243 +other: 0.223 +mistranslation: 0.191 + +x86 LSL and LAR fault +Description of problem: +From the description of LSL and LAR instructions in manual, `If the segment descriptor cannot be accessed or is an invalid type for the instruction, the ZF flag is cleared and no value is loaded in the destination operand.`. When it happens at the CPU, it seems they do nothing (nop). However, in QEMU, it crashes. +Steps to reproduce: +1. Compile this code +``` +void main() { + asm("mov rax, 0xa02e698e741f5a6a"); + asm("mov rbx, 0x20959ddd7a0aef"); + asm("lsl ax, bx"); +} +``` +2. Execute. QEMU crashes but CPU does not. This problem happens with LAR, too. +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/semantic-bugs-usermode/test/1377 b/results/classifier/semantic-bugs-usermode/test/1377 new file mode 100644 index 000000000..f3d87d4fe --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1377 @@ -0,0 +1,27 @@ +instruction: 0.973 +assembly: 0.847 +device: 0.773 +vnc: 0.768 +graphic: 0.742 +boot: 0.462 +socket: 0.412 +KVM: 0.326 +semantic: 0.321 +network: 0.279 +other: 0.095 +mistranslation: 0.073 + +x86 CVT* series instructions fault +Description of problem: +For example, CVTSD2SS instruction converts SRC[63:0] double precision floating point to DEST[31:0] single precision floating point. Although the CVTSD2SS instruction uses only 8 bytes, if it overlaps page boundary, I think QEMU tries to access over the valid memory and crashes. +Steps to reproduce: +1. Compile this code +``` +void main() { + mmap(0x555555559000, 0x1000, flag, ~~, 0); + asm("cvtsd2ss xmm1, qword ptr [0x555555559ff8]"); +} +``` +2. Execute. QEMU crashes but CPU does not. +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/semantic-bugs-usermode/test/1574346 b/results/classifier/semantic-bugs-usermode/test/1574346 new file mode 100644 index 000000000..410bb5bab --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1574346 @@ -0,0 +1,41 @@ +instruction: 0.779 +other: 0.750 +graphic: 0.731 +device: 0.728 +mistranslation: 0.635 +semantic: 0.551 +network: 0.544 +socket: 0.467 +vnc: 0.421 +boot: 0.390 +assembly: 0.341 +KVM: 0.339 + +TCG: mov to segment register is incorrectly emulated for AMD CPUs + +In TCG mode, the effect of: + +xorl %eax, %eax +movl %eax, %gs + +is to mark the GS segment unusable and set its base to zero. After doing this, reading MSR_GS_BASE will return zero and using a GS prefix in long mode will treat the GS base as zero. + +This is correct for Intel CPUs but is incorrect for AMD CPUs. On an AMD CPU, writing 0 to %gs using mov, pop, or (I think) lgs will leave the base unchanged. + +To make it easier to use TCG to validate behavior on different CPUs, please consider changing the TCG behavior to match actual CPU behavior when emulating an AMD CPU. + +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. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/semantic-bugs-usermode/test/1612 b/results/classifier/semantic-bugs-usermode/test/1612 new file mode 100644 index 000000000..aa2f4e529 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/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 `<Zt> == <Zm>`. 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`, `<Zt> == <Zm>`. + +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 <arm_sve.h> +#include <stdio.h> + +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-usermode/test/1620 b/results/classifier/semantic-bugs-usermode/test/1620 new file mode 100644 index 000000000..ecfad33cc --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/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 <stdio.h> + +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-usermode/test/1637 b/results/classifier/semantic-bugs-usermode/test/1637 new file mode 100644 index 000000000..9656c06fd --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1637 @@ -0,0 +1,14 @@ +instruction: 0.919 +device: 0.840 +graphic: 0.655 +boot: 0.219 +other: 0.214 +vnc: 0.201 +semantic: 0.196 +network: 0.164 +assembly: 0.162 +socket: 0.081 +mistranslation: 0.070 +KVM: 0.044 + +Crash when executing `ucomiss` instructions emulating an x86-64 CPU on an AArch64 host diff --git a/results/classifier/semantic-bugs-usermode/test/1641637 b/results/classifier/semantic-bugs-usermode/test/1641637 new file mode 100644 index 000000000..dff815184 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/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-usermode/test/1719984 b/results/classifier/semantic-bugs-usermode/test/1719984 new file mode 100644 index 000000000..909f6f0d9 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1719984 @@ -0,0 +1,27 @@ +instruction: 0.917 +graphic: 0.887 +mistranslation: 0.851 +device: 0.786 +network: 0.762 +semantic: 0.650 +boot: 0.624 +socket: 0.597 +vnc: 0.595 +KVM: 0.312 +other: 0.185 +assembly: 0.157 + +wrgsbase misemulated in x86_64-softmmu + +qemu revision: cfe4cade054c0e0d00d0185cdc433a9e3ce3e2e4 +command: ./qemu-system-x86_64 -m 2048 -nographic -net none -smp 4,threads=2 -machine q35 -kernel zircon.bin -cpu Haswell,+smap,-check -initrd bootdata.bin -append 'TERM=screen kernel.halt-on-panic=true ' + +On this revision, the VM reports CPUID.07H.0H.EBX[0] = 1. In this VM, with CR4[16] set to 1, wrgsbase triggers #UD, which mismatches the behavior described in Intel's instruction reference. + +For further data, the faulting instruction is +f3 48 0f ae df wrgsbase %rdi + +Fix is in staging: https://github.com/ehabkost/qemu/commit/cdcc80d41360e278b45c91de29a29d797264e85d + +Fix is in master: https://github.com/qemu/qemu/commit/e0dd5fd41a1a38766009f442967fab700d2d0550 + diff --git a/results/classifier/semantic-bugs-usermode/test/1722 b/results/classifier/semantic-bugs-usermode/test/1722 new file mode 100644 index 000000000..4dcbfc5fe --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/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 <GLIBC_2.0@@GLIBC_2.0+0x441c> + 4444: 00e21023 subu v0,a3,v0 + 4448: 2cebfffd sltiu a7,a3,-3 + 444c: 55600007 bnezl a7,446c <GLIBC_2.0@@GLIBC_2.0+0x446c> + 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 <stdio.h> + +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-usermode/test/1737 b/results/classifier/semantic-bugs-usermode/test/1737 new file mode 100644 index 000000000..3b07da097 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1737 @@ -0,0 +1,62 @@ +instruction: 0.968 +graphic: 0.919 +device: 0.848 +assembly: 0.842 +socket: 0.826 +vnc: 0.774 +network: 0.701 +semantic: 0.687 +boot: 0.686 +mistranslation: 0.642 +other: 0.581 +KVM: 0.346 + +qemu-aarch64: Incorrect result for ssra instruction when using vector lengths of 1024-bit or higher. +Description of problem: +``` +#include <arm_sve.h> +#include <stdio.h> + +#define SZ 32 + +int main(int argc, char* argv[]) { + svbool_t pg = svptrue_b64(); + uint64_t VL = svcntd(); + + fprintf(stderr, "One SVE vector can hold %li uint64_ts\n", VL); + + int64_t sr[SZ], sx[SZ], sy[SZ]; + uint64_t ur[SZ], ux[SZ], uy[SZ]; + + for (uint64_t i = 0; i < SZ; ++i) { + sx[i] = ux[i] = 0; + sy[i] = uy[i] = 1024; + } + + for (uint64_t i = 0; i < SZ; i+=VL) { + fprintf(stderr, "Processing elements %li - %li\n", i, i + VL - 1); + + svint64_t SX = svld1(pg, sx + i); + svint64_t SY = svld1(pg, sy + i); + svint64_t SR = svsra(SX, SY, 4); + svst1(pg, sr + i, SR); + + svuint64_t UX = svld1(pg, ux + i); + svuint64_t UY = svld1(pg, uy + i); + svuint64_t UR = svsra(UX, UY, 4); + svst1(pg, ur + i, UR); + } + + for (uint64_t i = 0; i < SZ; ++i) { + fprintf(stderr, "sr[%li]=%li, ur[%li]\n", i, sr[i], ur[i]); + } + + return 0; +} +``` +Steps to reproduce: +1. Build the above C source using "gcc -march=armv9-a -O1 ssra.c", can also use clang. +2. Run with "qemu-aarch64 -cpu max,sve-default-vector-length=64 ./a.out" and you'll see the expected result of 64 (signed and unsigned) +3. Run with "qemu-aarch64 -cpu max,sve-default-vector-length=128 ./a.out" and you'll see the expected result of 64 for unsigned but the signed result is 0. This suggests the emulation of SVE2 ssra instruction is incorrect for this and bigger vector lengths. +Additional information: + diff --git a/results/classifier/semantic-bugs-usermode/test/1748296 b/results/classifier/semantic-bugs-usermode/test/1748296 new file mode 100644 index 000000000..cab7dadc5 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/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-usermode/test/1751422 b/results/classifier/semantic-bugs-usermode/test/1751422 new file mode 100644 index 000000000..df415ac99 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1751422 @@ -0,0 +1,71 @@ +instruction: 0.738 +mistranslation: 0.597 +semantic: 0.524 +graphic: 0.506 +socket: 0.497 +other: 0.473 +device: 0.451 +vnc: 0.425 +network: 0.386 +boot: 0.348 +assembly: 0.324 +KVM: 0.292 + +some instructions translate error in x86 + +There is some instructions translation error on target i386 in many versions, such as 2.11.1, 2.10.2, 2.7.1 and so on. +The error translation instructions include les, lds. I has got a patch, but I have no idea how to apply it. + +Could you please provide some more information about the problem? What's exactly the error? If you've already got a patch, please have a look at https://wiki.qemu.org/Contribute/SubmitAPatch to get some information how to submit it. + +The patch is In this mail attachments, which is patch for version 2.11.1 target/i386/translate.c. +The patch is created by diff. +my English is so poor to explain how the error come, but you can see the patch result to get it. + + + + + + + + +At 2018-02-25 17:41:15, "Thomas Huth" <email address hidden> wrote: +>Could you please provide some more information about the problem? What's +>exactly the error? If you've already got a patch, please have a look at +>https://wiki.qemu.org/Contribute/SubmitAPatch to get some information +>how to submit it. +> +>** Changed in: qemu +> Status: New => Incomplete +> +>-- +>You received this bug notification because you are subscribed to the bug +>report. +>https://bugs.launchpad.net/bugs/1751422 +> +>Title: +> some instructions translate error in x86 +> +>Status in QEMU: +> Incomplete +> +>Bug description: +> There is some instructions translation error on target i386 in many versions, such as 2.11.1, 2.10.2, 2.7.1 and so on. +> The error translation instructions include les, lds. I has got a patch, but I have no idea how to apply it. +> +>To manage notifications about this bug go to: +>https://bugs.launchpad.net/qemu/+bug/1751422/+subscriptions + + +[Expired for QEMU because there has been no activity for 60 days.] + +We shouldn't really have let this expire, the submitter has a patch attached to the bug. + +Yabi: do you have a simple test program which fails without this patch and works with it? If so can you attach it to the bug ? + + +I believe this to be fixed by cfcca361d77, which is present in 2.12 but not 2.11. + +Since Richard pointed out a commit which fixed this in 2.12 and we haven't heard back from the submitter, I'm going to close this bug as fixed. + + diff --git a/results/classifier/semantic-bugs-usermode/test/1771 b/results/classifier/semantic-bugs-usermode/test/1771 new file mode 100644 index 000000000..3195f46f5 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1771 @@ -0,0 +1,46 @@ +instruction: 0.977 +graphic: 0.917 +device: 0.843 +socket: 0.778 +semantic: 0.749 +vnc: 0.729 +network: 0.581 +boot: 0.572 +other: 0.534 +mistranslation: 0.523 +assembly: 0.491 +KVM: 0.118 + +Missing CASA instruction handling for SPARC qemu-user +Description of problem: +Qemu-sparc does not handle the CASA instruction, even if the selected CPU (in this case, LEON3) support it. +Steps to reproduce: +1. Launch a program that use CASA instruction (any program, also "ls" on a recent glibc [>=2.31]) +2. qemu-sparc will raise "Illegal instruction" +Additional information: +The following patch remove the missing handling, but it needs asi load/store that is not implemented for sparc32 user-space. + +``` +diff -urp qemu-20230327.orig/target/sparc/translate.c qemu-20230327/target/sparc/translate.c +--- qemu-20230327.orig/target/sparc/translate.c 2023-03-27 15:41:42.000000000 +0200 ++++ qemu-20230327/target/sparc/translate.c 2023-04-01 15:24:18.293176711 +0200 +@@ -5521,7 +5522,7 @@ static void disas_sparc_insn(DisasContex + case 0x37: /* stdc */ + goto ncp_insn; + #endif +-#if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64) ++//#if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64) + case 0x3c: /* V9 or LEON3 casa */ + #ifndef TARGET_SPARC64 + CHECK_IU_FEATURE(dc, CASA); +@@ -5529,8 +5530,8 @@ static void disas_sparc_insn(DisasContex + rs2 = GET_FIELD(insn, 27, 31); + cpu_src2 = gen_load_gpr(dc, rs2); + gen_cas_asi(dc, cpu_addr, cpu_src2, insn, rd); ++//#endif + break; +-#endif + default: + goto illegal_insn; + } +``` diff --git a/results/classifier/semantic-bugs-usermode/test/1780 b/results/classifier/semantic-bugs-usermode/test/1780 new file mode 100644 index 000000000..354a178d0 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1780 @@ -0,0 +1,30 @@ +instruction: 0.971 +graphic: 0.882 +device: 0.724 +network: 0.589 +semantic: 0.561 +vnc: 0.436 +boot: 0.398 +socket: 0.311 +assembly: 0.172 +mistranslation: 0.130 +other: 0.041 +KVM: 0.040 + +PowerPC mishandles xscmpudp instruction +Description of problem: +xscmpudp instruction is mishandled +Steps to reproduce: +1. Compile the attached program with VSX (e.g. `RUSTFLAGS=-Ctarget-feature=+vsx cargo build --target=powerpc64-unknown-linux-gnu`) +2. Run the program and expect assertions to pass. +3. See assertions fail. +Additional information: +When VSX is disabled, the `fcmpu` instruction is emitted instead (and handled properly). See the offending program: +``` +pub fn main() { + use std::hint::black_box; + assert!(black_box(f64::NAN) + .clamp(black_box(0f64), black_box(0f64)) + .is_nan()); +} +``` diff --git a/results/classifier/semantic-bugs-usermode/test/1785734 b/results/classifier/semantic-bugs-usermode/test/1785734 new file mode 100644 index 000000000..127f85c5e --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1785734 @@ -0,0 +1,129 @@ +vnc: 0.771 +KVM: 0.765 +mistranslation: 0.764 +other: 0.750 +device: 0.674 +graphic: 0.667 +instruction: 0.658 +assembly: 0.629 +socket: 0.621 +semantic: 0.612 +boot: 0.579 +network: 0.578 + +movdqu partial write at page boundary + +In TCG mode, when a 16-byte write instruction (such as movdqu) is executed at a page boundary and causes a page fault, a partial write is executed in the first page. See the attached code for an example. + +Tested on the qemu-3.0.0-rc1 release. + + +% gcc -m32 qemu-bug2.c && ./a.out && echo && qemu-i386 ./a.out +*(0x70000ff8+ 0) = aa +*(0x70000ff8+ 1) = aa +*(0x70000ff8+ 2) = aa +*(0x70000ff8+ 3) = aa +*(0x70000ff8+ 4) = aa +*(0x70000ff8+ 5) = aa +*(0x70000ff8+ 6) = aa +*(0x70000ff8+ 7) = aa +*(0x70000ff8+ 8) = 55 +*(0x70000ff8+ 9) = 55 +*(0x70000ff8+10) = 55 +*(0x70000ff8+11) = 55 +*(0x70000ff8+12) = 55 +*(0x70000ff8+13) = 55 +*(0x70000ff8+14) = 55 +*(0x70000ff8+15) = 55 +page fault: addr=0x70001000 err=0x7 +*(0x70000ff8+ 0) = aa +*(0x70000ff8+ 1) = aa +*(0x70000ff8+ 2) = aa +*(0x70000ff8+ 3) = aa +*(0x70000ff8+ 4) = aa +*(0x70000ff8+ 5) = aa +*(0x70000ff8+ 6) = aa +*(0x70000ff8+ 7) = aa +*(0x70000ff8+ 8) = 55 +*(0x70000ff8+ 9) = 55 +*(0x70000ff8+10) = 55 +*(0x70000ff8+11) = 55 +*(0x70000ff8+12) = 55 +*(0x70000ff8+13) = 55 +*(0x70000ff8+14) = 55 +*(0x70000ff8+15) = 55 + +*(0x70000ff8+ 0) = aa +*(0x70000ff8+ 1) = aa +*(0x70000ff8+ 2) = aa +*(0x70000ff8+ 3) = aa +*(0x70000ff8+ 4) = aa +*(0x70000ff8+ 5) = aa +*(0x70000ff8+ 6) = aa +*(0x70000ff8+ 7) = aa +*(0x70000ff8+ 8) = 55 +*(0x70000ff8+ 9) = 55 +*(0x70000ff8+10) = 55 +*(0x70000ff8+11) = 55 +*(0x70000ff8+12) = 55 +*(0x70000ff8+13) = 55 +*(0x70000ff8+14) = 55 +*(0x70000ff8+15) = 55 +page fault: addr=0x70001000 err=0x6 +*(0x70000ff8+ 0) = 77 +*(0x70000ff8+ 1) = 66 +*(0x70000ff8+ 2) = 55 +*(0x70000ff8+ 3) = 44 +*(0x70000ff8+ 4) = 33 +*(0x70000ff8+ 5) = 22 +*(0x70000ff8+ 6) = 11 +*(0x70000ff8+ 7) = 0 +*(0x70000ff8+ 8) = 55 +*(0x70000ff8+ 9) = 55 +*(0x70000ff8+10) = 55 +*(0x70000ff8+11) = 55 +*(0x70000ff8+12) = 55 +*(0x70000ff8+13) = 55 +*(0x70000ff8+14) = 55 +*(0x70000ff8+15) = 55 + + + +This is a part of a class of related problems for qemu linux-user, in that any non-atomic store is not validated before initiating a partial write. + +For instance, qemu-x86_64, built for arm32, would show this same partial store problem for any 64-bit write crossing a page boundary because we are forced by the limits of the host to split the store into two 32-bit pieces. + +While we could probably fix this specific case fairly easily, because it is implemented with an external helper in the first place, we would need some new infrastructure to handle the more general problem. Exactly what form that should take would need some thought and discussion. + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/semantic-bugs-usermode/test/1790 b/results/classifier/semantic-bugs-usermode/test/1790 new file mode 100644 index 000000000..2a0a409bf --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1790 @@ -0,0 +1,42 @@ +instruction: 0.969 +graphic: 0.821 +boot: 0.809 +semantic: 0.738 +device: 0.730 +mistranslation: 0.585 +assembly: 0.543 +network: 0.505 +vnc: 0.500 +other: 0.437 +socket: 0.425 +KVM: 0.068 + +[AARCH64] STGP instruction is not writing the value of the second register to memory +Description of problem: +My application is built with Clang 16 and the option -fsanitize=memtag-stack. +It means the the MTE protection is activated for the stack. +The local variables are tagged and the compiler is often using the STGP instruction "Store Allocation Tag and Pair of registers" in order to transfer the value of two 64-bit registers to memory. +The following instruction was not working as expected: + 18004: 69000895 stgp x21, x2, [x4] +The value of the second register x2 is not transferred to the memory. +Only x21 is written. + +I think that the issue is in trans_STGP(). +We don't call finalize_memop_pair() like we do for in the general trans_STP(). + +``` +diff --git a/target/arm/tcg/translate-a64.c b/target/arm/tcg/translate-a64.c +index 7d0c8f79a7..f599f3e136 100644 +--- a/target/arm/tcg/translate-a64.c ++++ b/target/arm/tcg/translate-a64.c +@@ -3034,6 +3034,8 @@ static bool trans_STGP(DisasContext *s, arg_ldstpair *a) + + tcg_rt = cpu_reg(s, a->rt); + tcg_rt2 = cpu_reg(s, a->rt2); ++ mop = a->sz + 1; ++ mop = finalize_memop_pair(s, mop); + + assert(a->sz == 3); +``` + +With this fix, my OS (Kinibi) is now able to boot. diff --git a/results/classifier/semantic-bugs-usermode/test/1793608 b/results/classifier/semantic-bugs-usermode/test/1793608 new file mode 100644 index 000000000..b6a6faa1b --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1793608 @@ -0,0 +1,49 @@ +instruction: 0.899 +mistranslation: 0.794 +graphic: 0.781 +semantic: 0.777 +assembly: 0.747 +device: 0.645 +other: 0.636 +network: 0.605 +socket: 0.600 +vnc: 0.548 +KVM: 0.477 +boot: 0.423 + +qemu doesn't seem to support lxvwsx for POWER9 target + +When running a simple program built for POWER9 on QEMU 3.0.0 in linux-user mode, it crashes with a message: "illegal instruction". It turns out that lxvwsx instruction "Load Word and Splat Indexed" is not supported. If workaround is implemented by issuing two separate instructions (first load then splat) then all tests pass correctly. + +Operating system: Ubuntu Mate 16.04.2 64-bit (or Linux Mint 18 64-bit). +Cross-compiler for gcc-powerpc64le-linux-gnu is installed (gcc-5 series). +QEMU 3.0.0 is built from source and installed with: sudo make install + +The program in question: https://github.com/VectorChief/UniSIMD-assembler +Turn off the workaround: RT_ELEM_COMPAT_PW9 should be set to 1 in the following file: +https://github.com/VectorChief/UniSIMD-assembler/blob/master/core/config/rtarch_p32_128x1v2.h + +Change to the "test" directory and type "make -f simd_make_p64.mk". +powerpc64le-linux-gnu-objdump -d simd_test.p64_32Lp9 > simd_test_p64_32Lp9.txt +Open newly created text file simd_test_p64_32Lp9.txt and search for lxvwsx (in s_test01, ...) +The instruction shows up in objdump correctly. + +Small clarification to the bug description above. + +Host architecture: x86_64 (AMD64) +Instructions used for building QEMU 3.0.0 from source are here: +https://github.com/VectorChief/UniSIMD-assembler/blob/master/INSTALL + +The command line for emulating POWER9 target is below: +qemu-ppc64le -cpu POWER9 simd_test.p64_32Lp9 -c 1 + +With the workaround for lxvwsx instruction turned off (as described above) +QEMU crashes in s_test08 function of the following common SIMD test file: +https://github.com/VectorChief/UniSIMD-assembler/blob/master/test/simd_test.cpp + +A patch has been posted here: +https://lists.gnu.org/archive/html/qemu-devel/2020-11/msg02218.html +("ppc/translate: Implement lxvwsx opcode") + +Released with QEMU v5.2.0. + diff --git a/results/classifier/semantic-bugs-usermode/test/1818075 b/results/classifier/semantic-bugs-usermode/test/1818075 new file mode 100644 index 000000000..26b345c17 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1818075 @@ -0,0 +1,133 @@ +instruction: 0.940 +graphic: 0.906 +assembly: 0.878 +other: 0.877 +device: 0.848 +KVM: 0.820 +vnc: 0.809 +network: 0.800 +semantic: 0.791 +socket: 0.778 +mistranslation: 0.773 +boot: 0.655 + +qemu x86 TCG doesn't support AVX insns + +I'm trying to execute code that has been built with -march=skylake -mtune=generic -mavx2 under qemu-user x86-64 with -cpu Skylake-Client. However this code just hangs at 100% CPU. + +Adding input tracing shows that it is likely hanging when dealing with an AVX instruction: + +warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.f16c [bit 29] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.rdrand [bit 30] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.hle [bit 4] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 10] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.rtm [bit 11] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.rdseed [bit 18] +warning: TCG doesn't support requested feature: CPUID.80000001H:ECX.3dnowprefetch [bit 8] +warning: TCG doesn't support requested feature: CPUID.0DH:EAX.xsavec [bit 1] + +IN: +0x4000b4ef3b: c5 fb 5c ca vsubsd %xmm2, %xmm0, %xmm1 +0x4000b4ef3f: c4 e1 fb 2c d1 vcvttsd2si %xmm1, %rdx +0x4000b4ef44: 4c 31 e2 xorq %r12, %rdx +0x4000b4ef47: 48 85 d2 testq %rdx, %rdx +0x4000b4ef4a: 79 9e jns 0x4000b4eeea + +[ hangs ] + +Attaching a gdb produces this stacktrace: + +(gdb) bt +#0 canonicalize (status=0x55a20ff67a88, parm=0x55a20bb807e0 <float64_params>, part=...) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:350 +#1 float64_unpack_canonical (s=0x55a20ff67a88, f=0) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:547 +#2 float64_sub (a=0, b=4890909195324358656, status=0x55a20ff67a88) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:776 +#3 0x000055a20baa1949 in helper_subsd (env=<optimized out>, d=0x55a20ff67ad8, s=<optimized out>) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/target/i386/ops_sse.h:623 +#4 0x000055a20cfcfea8 in static_code_gen_buffer () +#5 0x000055a20ba3f764 in cpu_tb_exec (itb=<optimized out>, cpu=0x55a20cea2180 <static_code_gen_buffer+15684720>) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:171 +#6 cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, + cpu=0x55a20cea2180 <static_code_gen_buffer+15684720>) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:615 +#7 cpu_exec (cpu=cpu@entry=0x55a20ff5f4d0) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:725 +#8 0x000055a20ba6d728 in cpu_loop (env=0x55a20ff67780) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/x86_64/../i386/cpu_loop.c:93 +#9 0x000055a20ba049ff in main (argc=<optimized out>, argv=0x7ffc58572868, envp=<optimized out>) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/main.c:819 + +<pm215> my guess is we're doing something unhelpful with the AVX insn, and so the guest code which is checking the result and using it as its loop condition for the jns is just looping forever + +<rburton> in_asm log just stopped with this as the last line +<rburton> 0x4000b4ef4a: 79 9e jns 0x4000b4eeea + + +Further debugging on IRC reveals that QEMU itself is not hanging, but the guest code is looping infinitely, because QEMU doesn't implement the AVX instruction set and isn't generating an undefined-instruction exception either. So the %rdx output from the AVX insn is wrong and the guest code never exits the loop (whose condition depends on %rdx). + +We should ideally: + * make the x86 decoder properly handle insns that don't exist for the CPU being emulated (not too difficult, but doesn't actually help in running this test program) + * implement AVX (a fair chunk of effort; it is being proposed as a GSoC project for this summer) + + +If I may be so free: + +It seems that QEMU has stopped emphasizing the EMU part of the name, and is too much focused on virtualization. + +My interest is at running legacy operating systems, and as such, they must run on foreign CPU platforms. m68 on intel, intel on ARM, etc. +Time doesn't stand still, and reliance on KVM and similar x86-on-x86 tricks, which allow the delegation of certain CPU features to the host CPU is going to not work going forward. + +If the rumored transition of Apple to ARM is going to take place, people will want to e.g. emulate for testing or legacy purposes a variety of operating systems, incl. earlier versions of MacOS. + +Testing that scenario, i.e. macOS on an ARM board with the lowest possible CPU capable of running modern macOS, results in these problems (and of course utter failure achieving the goal): + +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.80000007H:EDX.invtsc [bit 8] +qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.0DH:EAX.xsavec [bit 1] + +And this is emulating a lowly Penryn CPU with the required CPU flags for macOS: +-cpu Penryn,vendor=GenuineIntel,+sse3,+sse4.2,+aes,+xsave,+avx,+xsaveopt,+xsavec,+xgetbv1,+avx2,+bmi2,+smep,+bmi1,+fma,+movbe,+invtsc + +Attempting to emulate a more feature laden intel CPU results in even more issues. + +I would propose that no CPU should be considered supported unless it can be fully handled by TCG on a non-native host. KVM, native-on-native etc. are nice to have, but peripheral to qEMUlation when it boils down to it. + +We do care about emulation; but as always with open source software projects, the parts that get more care and attention are the parts that people are either paid to work on or are personally interested in. x86 guest emulation in particular is not very well maintained (though it is better than some targets), because mostly people are happy to use x86 hardware, and adding support for emulation of large new architectural features like AVX is a lot of work. If you would like to help improve x86 guest emulation, you are welcome to submit patches to fix bugs or add new features. Merely saying "X should be better and you should somehow magically find three months worth of developer time to make it so" doesn't really do anything to move the situation forwards. + + +QEMU, like most open source projects, relies on contributors who have motivation, skills and available time to work on implementing particular features. They naturally tend to focus on features that result in the greatest benefit to their own use cases. Thus simply declaring that an open source project, must support something won't magically make it happen. + +IOW, the lack of coverage of newer x86 instructions is largely a reflection of the relative priorities of the current pool of contributors and where/what they feel are the best places/features to spend their time on. + +If any person does want to work on improving x86 TCG though, the project would happily receive patches, and existing contributors can offer guidance & advice along the way to help get to a successful outcome. + + +Of course it’s open source, I get that. When I say „xyz should be done“ then in the sense of „2+2 should be 4“ not in the sense of „you must implement xyz right now“ ;) + +Nonetheless, if you run e.g. on an ARM platform the command + +qemu-system-x86_64 -cpu help + +then it shouldn’t list a slew of CPUs as „available“ that clearly aren’t working. + +It should then list fully implemented CPUs separately from partially implemented CPUs (if listing them at all), and if it does list incomplete implementations, it should indicate what’s missing. +It’s just a horrible user experience, if based on such output, one spends significant time trying to get some emulation running, only to then discover from runtime error messages, that an „available“ CPU isn’t actually available. + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/164 + + diff --git a/results/classifier/semantic-bugs-usermode/test/1820686 b/results/classifier/semantic-bugs-usermode/test/1820686 new file mode 100644 index 000000000..f7fd19f6d --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1820686 @@ -0,0 +1,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. + diff --git a/results/classifier/semantic-bugs-usermode/test/1824344 b/results/classifier/semantic-bugs-usermode/test/1824344 new file mode 100644 index 000000000..9886d36a4 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1824344 @@ -0,0 +1,71 @@ +instruction: 0.928 +assembly: 0.842 +device: 0.543 +semantic: 0.396 +network: 0.367 +socket: 0.356 +other: 0.327 +boot: 0.303 +vnc: 0.251 +graphic: 0.236 +mistranslation: 0.196 +KVM: 0.008 + +x86: retf or iret pagefault sets wrong error code + +With a x86_64 or i386 guest, non-KVM, when trying to execute a +"iret/iretq/retf" instruction in userspace with invalid stack pointer +(under a protected mode OS, like Linux), wrong bits are set in the +pushed error code; bit 2 is not set, indicating the error comes from +kernel space. + +If the guest OS is using this flag to decide whether this was a kernel +or user page fault, it will mistakenly decide a kernel has irrecoverably +faulted, possibly causing guest OS panic. + + +How to reproduce the problem a guest (non-KVM) Linux: +Note, on recent Linux kernel version, this needs a CPU with SMAP support +(eg. -cpu max) + +$ cat tst.c +int main() +{ +__asm__ volatile ( +"mov $0,%esp\n" +"retf" +); +return 0; +} + +$ gcc tst.c +$ ./a.out +Killed + + +"dmesg" shows the kernel has in fact triggered a "BUG: unable to handle +kernel NULL pointer dereference...", but it has "recovered" by killing +the faulting process (see attached screenshot). + + +Using self-compiled qemu from git: +commit 532cc6da74ec25b5ba6893b5757c977d54582949 (HEAD -> master, tag: v4.0.0-rc3, origin/master, origin/HEAD) +Author: Peter Maydell <email address hidden> +Date: Wed Apr 10 15:38:59 2019 +0100 + + Update version for v4.0.0-rc3 release + + Signed-off-by: Peter Maydell <email address hidden> + + + +This appears to be similar to https://bugs.launchpad.net/qemu/+bug/1866892 (and much simpler) + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/265 + + diff --git a/results/classifier/semantic-bugs-usermode/test/1824778 b/results/classifier/semantic-bugs-usermode/test/1824778 new file mode 100644 index 000000000..d9e3e95db --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1824778 @@ -0,0 +1,30 @@ +instruction: 0.756 +device: 0.493 +semantic: 0.280 +graphic: 0.275 +network: 0.264 +other: 0.245 +boot: 0.202 +vnc: 0.194 +socket: 0.151 +mistranslation: 0.124 +KVM: 0.054 +assembly: 0.052 + +PowerPC64: tlbivax does not work for addresses above 4G + +The tlbivax instruction in QEMU does not work for address above 4G. The reason behind this is a simple 32bit trunction of an address. +Changing the argument ea from uint32_t to target_ulong for the function booke206_invalidate_ea_tlb() in target/ppc/mmu_helper.c solves the issue. + +I did not reproduce this using Linux so I have no public example for reproducing it. However it's a pretty straight forward change. + +Issue can be seen in all version of QEMU. + + +This is an automated cleanup. This bug report has been moved +to QEMU's new bug tracker on gitlab.com and thus gets marked +as 'expired' now. Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/52 + + diff --git a/results/classifier/semantic-bugs-usermode/test/1828867 b/results/classifier/semantic-bugs-usermode/test/1828867 new file mode 100644 index 000000000..05260e5d1 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1828867 @@ -0,0 +1,48 @@ +instruction: 0.527 +device: 0.454 +socket: 0.435 +mistranslation: 0.388 +assembly: 0.285 +network: 0.264 +vnc: 0.258 +graphic: 0.231 +semantic: 0.225 +boot: 0.171 +other: 0.169 +KVM: 0.124 + +QEmu translation is incorrect when using REX in combination with LAHF/SAHF + +When translating code that is using LAHF and SAHF in combination with the REX prefix then qemu translates incorrectly. +These two instructions only ever use the AH register. Contrary to other instructions where if you use REX + high bit offsets then it'll pull in rsp and a few other registers. +On hardware the REX prefix doesn't effect behaviour of these instructions at all. +QEMU incorrectly selects RSP as the register of choice here due to this combination of REX + AH register usage. + +I've attached a patch that is super terrible just so I can work around the issue locally and to sort of show off how it is to be "fixed" + + + +Here's also a basic test that can be run on hardware and have rflags and rsp inspected after each instruction just to see how hardware doesn't effect it. + +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. + +This is still relevant. + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/130 + + diff --git a/results/classifier/semantic-bugs-usermode/test/1832422 b/results/classifier/semantic-bugs-usermode/test/1832422 new file mode 100644 index 000000000..39c39a63d --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1832422 @@ -0,0 +1,33 @@ +instruction: 0.815 +device: 0.667 +network: 0.510 +socket: 0.486 +graphic: 0.457 +semantic: 0.453 +vnc: 0.413 +boot: 0.294 +other: 0.278 +mistranslation: 0.276 +assembly: 0.233 +KVM: 0.224 + +SSE CMP ops with 8bit immediate throw sigill with oversized byte + +The SSE comparison ops that use an 8bit immediate as a comparison type selector throws a sigill when the immediate is oversized. + +Test op that I found this on is here `66 0f c2 c0 d1 cmppd xmm0,xmm0,0xd1` +According to the x86-64 documentation only bits [2:0] are used for these ops (and [4:0] for the AVX variant) +Currently qemu just checks if the value is >=8 and will throw a sigill in that case. It instead needs to mask. + +I have a small patch that fixes the issue for the SSE variant. + + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/184 + + diff --git a/results/classifier/semantic-bugs-usermode/test/1861404 b/results/classifier/semantic-bugs-usermode/test/1861404 new file mode 100644 index 000000000..f905e83ae --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1861404 @@ -0,0 +1,223 @@ +mistranslation: 0.825 +instruction: 0.821 +assembly: 0.797 +other: 0.797 +device: 0.782 +graphic: 0.773 +socket: 0.740 +network: 0.740 +semantic: 0.730 +KVM: 0.709 +boot: 0.708 +vnc: 0.697 + +AVX instruction VMOVDQU implementation error for YMM registers + +Hi, + +Tested with Qemu 4.2.0, and with git version bddff6f6787c916b0e9d63ef9e4d442114257739. + +The x86 AVX instruction VMOVDQU doesn't work properly with YMM registers (32 bytes). +It works with XMM registers (16 bytes) though. + +See the attached test case `ymm.c`: when copying from memory-to-ymm0 and then back from ymm0-to-memory using VMOVDQU, Qemu only copies the first 16 of the total 32 bytes. + +``` +user@ubuntu ~/Qemu % gcc -o ymm ymm.c -Wall -Wextra -Werror + +user@ubuntu ~/Qemu % ./ymm +00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F + +user@ubuntu ~/Qemu % ./x86_64-linux-user/qemu-x86_64 -cpu max ymm +00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +``` + +This seems to be because in `translate.c > gen_sse()`, the case handling the VMOVDQU instruction calls `gen_ldo_env_A0` which always performs a 16 bytes copy using two 8 bytes load and store operations (with `tcg_gen_qemu_ld_i64` and `tcg_gen_st_i64`). + +Instead, the `gen_ldo_env_A0` function should generate a copy with a size corresponding to the used register. + + +``` +static void gen_sse(CPUX86State *env, DisasContext *s, int b, + target_ulong pc_start, int rex_r) +{ + [...] + case 0x26f: /* movdqu xmm, ea */ + if (mod != 3) { + gen_lea_modrm(env, s, modrm); + gen_ldo_env_A0(s, offsetof(CPUX86State, xmm_regs[reg])); + } else { + [...] +``` + +``` +static inline void gen_ldo_env_A0(DisasContext *s, int offset) +{ + int mem_index = s->mem_index; + tcg_gen_qemu_ld_i64(s->tmp1_i64, s->A0, mem_index, MO_LEQ); + tcg_gen_st_i64(s->tmp1_i64, cpu_env, offset + offsetof(ZMMReg, ZMM_Q(0))); + tcg_gen_addi_tl(s->tmp0, s->A0, 8); + tcg_gen_qemu_ld_i64(s->tmp1_i64, s->tmp0, mem_index, MO_LEQ); + tcg_gen_st_i64(s->tmp1_i64, cpu_env, offset + offsetof(ZMMReg, ZMM_Q(1))); +} +``` + + + +Note: Qemu has been built with the following commands: +``` +% ./configure --target-list=x86_64-linux-user && make +OR +% ./configure --target-list=x86_64-linux-user --enable-avx2 && make +``` + +On Friday, January 31, 2020, Alex Bennée <email address hidden> wrote: + +> ** Tags added: tcg testcase +> +> -- +> You received this bug notification because you are a member of qemu- +> devel-ml, which is subscribed to QEMU. +> https://bugs.launchpad.net/bugs/1861404 +> +> Title: +> AVX instruction VMOVDQU implementation error for YMM registers +> +> +If I remember well, there is no support for AVX instructions in linux-user +mode. + +If that is true, how come handling of unsupported instruction went that far? + +Did you try other AVX instructions? + +Aleksandar + + + + +> Status in QEMU: +> New +> +> Bug description: +> Hi, +> +> Tested with Qemu 4.2.0, and with git version +> bddff6f6787c916b0e9d63ef9e4d442114257739. +> +> The x86 AVX instruction VMOVDQU doesn't work properly with YMM registers +> (32 bytes). +> It works with XMM registers (16 bytes) though. +> +> See the attached test case `ymm.c`: when copying from memory-to-ymm0 +> and then back from ymm0-to-memory using VMOVDQU, Qemu only copies the +> first 16 of the total 32 bytes. +> +> ``` +> user@ubuntu ~/Qemu % gcc -o ymm ymm.c -Wall -Wextra -Werror +> +> user@ubuntu ~/Qemu % ./ymm +> 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 +> 18 19 1A 1B 1C 1D 1E 1F +> +> user@ubuntu ~/Qemu % ./x86_64-linux-user/qemu-x86_64 -cpu max ymm +> 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00 00 00 00 00 00 00 00 +> 00 00 00 00 00 00 00 00 +> ``` +> +> This seems to be because in `translate.c > gen_sse()`, the case +> handling the VMOVDQU instruction calls `gen_ldo_env_A0` which always +> performs a 16 bytes copy using two 8 bytes load and store operations +> (with `tcg_gen_qemu_ld_i64` and `tcg_gen_st_i64`). +> +> Instead, the `gen_ldo_env_A0` function should generate a copy with a +> size corresponding to the used register. +> +> +> ``` +> static void gen_sse(CPUX86State *env, DisasContext *s, int b, +> target_ulong pc_start, int rex_r) +> { +> [...] +> case 0x26f: /* movdqu xmm, ea */ +> if (mod != 3) { +> gen_lea_modrm(env, s, modrm); +> gen_ldo_env_A0(s, offsetof(CPUX86State, xmm_regs[reg])); +> } else { +> [...] +> ``` +> +> ``` +> static inline void gen_ldo_env_A0(DisasContext *s, int offset) +> { +> int mem_index = s->mem_index; +> tcg_gen_qemu_ld_i64(s->tmp1_i64, s->A0, mem_index, MO_LEQ); +> tcg_gen_st_i64(s->tmp1_i64, cpu_env, offset + offsetof(ZMMReg, +> ZMM_Q(0))); +> tcg_gen_addi_tl(s->tmp0, s->A0, 8); +> tcg_gen_qemu_ld_i64(s->tmp1_i64, s->tmp0, mem_index, MO_LEQ); +> tcg_gen_st_i64(s->tmp1_i64, cpu_env, offset + offsetof(ZMMReg, +> ZMM_Q(1))); +> } +> ``` +> +> To manage notifications about this bug go to: +> https://bugs.launchpad.net/qemu/+bug/1861404/+subscriptions +> +> + + +Because the sse code is sloppy, and it was interpreted +as the sse instruction movdqu. + +AVX support was coded for GSoC last year, + +https://lists.nongnu.org/archive/html/qemu-devel/2019-08/msg05369.html + +but it has not been completely reviewed and committed. + +There is no support for AVX in master. + +Thanks for your answers. + +I thought the fact that there was not any warning/exception meant that VMOVDQU was supported, but if it's mistakenly interpreted as MOVDQU then I understand. + +I read the mailing list messages on the AVX GSoC you point out, but couldn't find any branch where this work is located. Is there a non-released version of this that can be tested? + +If I understand correctly, Qemu (or more precisely TCG) supports x86 SIMD instructions up to SSE4.1, but not AVX/AVX2/AVX-512? + +Thanks. + +Hi, + +I also noticed that the 4.2.0 release changelog mentions support for some AVX512 instructions. + +https://wiki.qemu.org/ChangeLog/4.2#x86 +``` +Support for AVX512 BFloat16 extensions. +``` + +Is this support in TCG or in another component? +If so, it would mean that TCG support some AVX512 instructions but not AVX. + +Also, allow me to ask again, where can I find the work of last year's GSoC on AVX support for TCG? + +> AVX support was coded for GSoC last year, +> https://lists.nongnu.org/archive/html/qemu-devel/2019-08/msg05369.html + +Thanks. + +The "AVX512 BFloat16" patch is for KVM support. + +As for finding the GSoC work, please follow that link, +and the ones buried inside that. There are hundreds +of patches involved. + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/132 + + diff --git a/results/classifier/semantic-bugs-usermode/test/1863247 b/results/classifier/semantic-bugs-usermode/test/1863247 new file mode 100644 index 000000000..072da78e3 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1863247 @@ -0,0 +1,33 @@ +instruction: 0.742 +device: 0.668 +graphic: 0.540 +semantic: 0.501 +other: 0.498 +mistranslation: 0.393 +socket: 0.384 +network: 0.383 +vnc: 0.341 +boot: 0.254 +assembly: 0.250 +KVM: 0.178 + +AArch64 EXT instruction for V register does not clear MSB side bits + +On AArch64 CPU with SVE register, there seems to be a bug in the operation when executing EXT instruction to V registers. Bits above the 128 bits of the SVE register must be cleared to 0, but qemu-aarch64 seems to hold the value. + +Example +ext v0.16b, v1.16b v2.16b, 8 + +After executing above instruction, (N-1) to 128 bits of z0 register must be 0, where N is SVE register width. + +Yep. + +Fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=78cedfabd53b + + +Thank you for bug fix. +I found trn1, trn2, zip1, zip2, uz1, uz2 instructions seem to have same bug. + +All of those, and tbl, tbx, ins, are fixed in the three subsequent commits. + diff --git a/results/classifier/semantic-bugs-usermode/test/1901 b/results/classifier/semantic-bugs-usermode/test/1901 new file mode 100644 index 000000000..33ec55668 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1901 @@ -0,0 +1,32 @@ +instruction: 0.968 +graphic: 0.871 +device: 0.723 +semantic: 0.696 +other: 0.517 +network: 0.432 +socket: 0.404 +vnc: 0.392 +mistranslation: 0.243 +boot: 0.231 +assembly: 0.079 +KVM: 0.079 + +qemu-sparc64 / sparc32plus apparent wrong results from VIS fmul8x16 instruction +Description of problem: +Experimenting with SPARC emulation, I noticed that the results of the UltraSparc fmul8x16 instruction don't appear to match the behaviour of real silicon (aka it doesn't appear to work at all -- in the test program, the result seems to be always 0). Other VIS instructions I tried seem to be OK (I have not tried all of them). + +The same problem is observed both in 64-bit (qemu-sparc64) and 32-bit (qemu-sparc32plus) applications. +Steps to reproduce: +1. Compile the attached test program (which exhaustively tests all possible combinations of 16-bit and 8-bit inputs) with gcc: + ``` + sparc64-unknown-linux-gnu-gcc -static -Os -mcpu=ultrasparc -mvis -o test_fmul8x16 test_fmul8x16.c + ``` +2. Run it in qemu-sparc64: + ``` + qemu-sparc64 -cpu 'TI UltraSparc II' ./test_fmul8x16 + ``` +3. Observe almost all tests fail. + + Running the exact same compiled binary on a real UltraSparc II CPU gives all pass results. +Additional information: +[test_fmul8x16.c](/uploads/2bf68e53652fba2ed69ac3ebb3f4b5e9/test_fmul8x16.c) diff --git a/results/classifier/semantic-bugs-usermode/test/1912934 b/results/classifier/semantic-bugs-usermode/test/1912934 new file mode 100644 index 000000000..f487e30df --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1912934 @@ -0,0 +1,78 @@ +instruction: 0.655 +device: 0.618 +semantic: 0.589 +mistranslation: 0.555 +graphic: 0.466 +socket: 0.360 +vnc: 0.325 +assembly: 0.276 +network: 0.262 +boot: 0.230 +other: 0.223 +KVM: 0.145 + +QEMU emulation of fmadds instruction on powerpc64le is buggy + +The attached program test-fmadds.c tests the fmadds instruction on powerpc64le. + +Result on real hardware (POWER8E processor): +$ ./a.out ; echo $? +0 + +Result in Alpine Linux 3.13/powerpcle, emulated by QEMU 5.0.0 on Ubuntu 16.04: +$ ./a.out ; echo $? +32 + +Result in Debian 8.6.0/ppc64el, emulated by QEMU 2.9.0 on Ubuntu 16.04: +$ ./a.out ; echo $? +32 + +Through 'nm --dynamic qemu-system-ppc64 | grep fma' I can see that QEMU is NOT using the fmaf() or fma() function from the host system's libc; this function is working fine in glibc of the host system (see https://www.gnu.org/software/gnulib/manual/html_node/fmaf.html ). + + + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +The situation is still the same in QEMU 6.0.0. + +$ powerpc64le-linux-gnu-gcc-5 test-fmadds.c -static +$ ~/inst-qemu/6.0.0/bin/qemu-ppc64le ./a.out ; echo $? +32 + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/312 + + diff --git a/results/classifier/semantic-bugs-usermode/test/1915027 b/results/classifier/semantic-bugs-usermode/test/1915027 new file mode 100644 index 000000000..4df7ceb4b --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1915027 @@ -0,0 +1,27 @@ +instruction: 0.816 +assembly: 0.781 +graphic: 0.759 +other: 0.744 +device: 0.634 +semantic: 0.632 +mistranslation: 0.442 +vnc: 0.284 +network: 0.181 +boot: 0.140 +socket: 0.116 +KVM: 0.044 + +RISC-V 64, CPUs do ilegal 0x00 write with SMP + +When QEMU is runt like this: + +qemu-system-riscv64 -d unimp,guest_errors -smp 8 + +Other harts will do a illegal write on address 0x00. + +This could be mostly (i think) because the initial assembly code is only loaded on the first hart and the others do a mess because there is no code to execute. + +Even with -smp 1 you will see the same errors. The problem is because there is nothing to run after OpenSBI jumps to the next stage. + +If you load a kernel you will not see the error messages. + diff --git a/results/classifier/semantic-bugs-usermode/test/1916269 b/results/classifier/semantic-bugs-usermode/test/1916269 new file mode 100644 index 000000000..45a2ef615 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1916269 @@ -0,0 +1,70 @@ +instruction: 0.884 +socket: 0.821 +graphic: 0.779 +device: 0.775 +other: 0.721 +network: 0.656 +semantic: 0.654 +vnc: 0.626 +mistranslation: 0.626 +boot: 0.615 +assembly: 0.473 +KVM: 0.297 + +TCG: QEMU incorrectly raises exception on SSE4.2 CRC32 instruction + +If I run FreeBSD on QEMU 5.2 with TCG acceleration -cpu Nehalem, I get a FPU exception when executing crc32 (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253617). This is not a problem with the default CPU (or KVM) since that does not support SSE 4.2. + +Attaching GDB shows this is triggered in target/i386/tcg/translate.c:3067 + + /* simple MMX/SSE operation */ + if (s->flags & HF_TS_MASK) { + gen_exception(s, EXCP07_PREX, pc_start - s->cs_base); + return; + } + +However, according to https://software.intel.com/sites/default/files/m/8/b/8/D9156103.pdf, page 61 the CRC32 instruction works no matter what the value of the TS bit. + +The code sequence in question is: +0xffffffff8105a4de <+126>: f2 48 0f 38 f1 de crc32q %rsi,%rbx +0xffffffff8105a4e4 <+132>: f2 48 0f 38 f1 ca crc32q %rdx,%rcx. + +This should work even with the FPU disabled. + +Could someone familiar with the target/i386 decode logic could have a look at this? It should be a rather simple change to avoid the exception for the crc32 encoding. However, I am not familiar with x86 instruction encodings so it would take me a long time to come up with a correct patch. +Thanks! + +The QEMU project is currently moving 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 the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + +Reported on GitLab as https://gitlab.com/qemu-project/qemu/-/issues/427 + diff --git a/results/classifier/semantic-bugs-usermode/test/1926759 b/results/classifier/semantic-bugs-usermode/test/1926759 new file mode 100644 index 000000000..753b9e4d4 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1926759 @@ -0,0 +1,73 @@ +instruction: 0.938 +semantic: 0.770 +graphic: 0.694 +other: 0.656 +device: 0.644 +vnc: 0.552 +assembly: 0.506 +socket: 0.491 +network: 0.398 +boot: 0.365 +mistranslation: 0.349 +KVM: 0.297 + +WFI instruction results in unhandled CPU exception + +Hi + +I refer to the WFI instruction. The bytecode is 0xe320f003. After the execution, qemu exit with the following crash log. + +qemu: unhandled CPU exception 0x10001 - aborting +R00=00000001 R01=40800b34 R02=40800b3c R03=000102ec +R04=00010a28 R05=00010158 R06=00087460 R07=00010158 +R08=00000000 R09=00000000 R10=00085b7c R11=408009f4 +R12=40800a08 R13=408009f0 R14=0001057c R15=000102f8 +PSR=60000010 -ZC- A usr32 +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x7f5c21d0fa12 + +WFI aims to enter a low-power state and wait for interrupt. The raised exception seems not a right behavior. I can provide a testcase if you needed. Many thanks. + +Regards +Muhui + +Please provide a test case binary and your QEMU command line. + + +Oh, and the QEMU version you're using as well, please. + + +cmd： ~/qemu-5.1.0/arm-linux-user/qemu-arm ~/test2 + +QEMU version: qemu-arm version 5.1.0 + +Sorry that I didn't test it on the latest version of QEMU. + +Crash repros on current QEMU. + +This is a bug, in that we shouldn't crash like this. However, it doesn't really make any sense for a userspace program (which is what a binary run by qemu-arm is) to execute the WFI instruction, which is largely intended for OSes to use. If your guest binary needs to use WFI, you should probably be running it on the system emulation QEMU, which does handle WFI correctly. + + +The aarch64 kernel traps and handles WFI as a NOP: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c219bc4e9205 -- so that's probably the most sensible implementation for our linux-user mode. (The aarch32 kernel doesn't trap it, yet, but +"WFI is a NOP" is a valid architectural implementation anyway.) + + +I agree with this implementation. Though WFI seems make no sense for a userspace program, we should not have assumption that the userspace program will not use this instruction. + +It seems ARM manual does not defined the implementation of function EnterLowPowerState(); However, before executing this instruction, there are some checks like below: + +if PSTATE.EL == EL0 then + // Check for traps described by the OS which may be EL1 or EL2. + AArch32.CheckForWFxTrap(EL1, FALSE); + +I am not sure whether it is complex/required to implement this in QEMU. Maybe patch the WFI as a NOP looks like the best idea at this moment. + +We do implement those traps, but only in the system mode emulator, because it makes no sense to trap to EL2 in the usermode emulator where EL2 doesn't exist. + + +Should be fixed by: +https://<email address hidden>/ + + +Fix has been merged: +https://gitlab.com/qemu-project/qemu/-/commit/5b2c8af89b82a671137a + diff --git a/results/classifier/semantic-bugs-usermode/test/1955 b/results/classifier/semantic-bugs-usermode/test/1955 new file mode 100644 index 000000000..17cd3a9de --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/1955 @@ -0,0 +1,39 @@ +instruction: 0.950 +graphic: 0.840 +semantic: 0.801 +device: 0.645 +other: 0.493 +socket: 0.420 +network: 0.394 +mistranslation: 0.346 +boot: 0.280 +vnc: 0.269 +assembly: 0.183 +KVM: 0.107 + +powerpc instruction 'mffsl' not emulated on POWER8 +Description of problem: +Since 2019, the function feenableexcept() in GNU libc makes use of the "mffsl" instruction. +See https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/powerpc/fpu/feenablxcpt.c;h=b111ceaa4e2e1864fcbe043ccda34e03e9f14062;hb=HEAD#l28 +and https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/powerpc/fpu/fenv_libc.h;h=a2a12d914b47e99746003482b349a0675cc5ad34;hb=HEAD#l57 + +In the emulated Debian system, executables that make use of this instruction crash with SIGILL. +Likewise, under gdb (in the emulated system), there is a SIGILL at the 'mffsl' instruction. + +From the comments in the above glibc source, added by Paul A. Clarke <pc@us.ibm.com>: + "Nicely, it turns out that the 'mffsl' instruction will decode to + 'mffs' on architectures older than "power9" because the additional + bits set for 'mffsl' are "don't care" for 'mffs'. 'mffs' is a superset + of 'mffsl'." + +This is indeed what I observe by compiling and running the attached program foo.c on a hardware machine with a POWER8 CPU: That program does not crash with a SIGILL. +Steps to reproduce: +1. Either run the attached 'test-fenv-except-tracking-5.ppc' (32-bit) program under qemu-system-ppc. +2. Or run the the attached 'test-fenv-except-tracking-5.ppc64' (64-bit) program under qemu-system-ppc64 with -cpu POWER8. +3. Or compile and run the attached foo.c and run it under QEMU. +Additional information: +[test-fenv-except-tracking-5.ppc.xz](/uploads/8222ebac115e8a865d5e520b25d423ff/test-fenv-except-tracking-5.ppc.xz) + +[test-fenv-except-tracking-5.ppc64.xz](/uploads/d0522723541a46e11ab55b8f45dfb574/test-fenv-except-tracking-5.ppc64.xz) + +[foo.c](/uploads/35d8b3b1e5b39ecb6a2a899132858ded/foo.c) diff --git a/results/classifier/semantic-bugs-usermode/test/2089 b/results/classifier/semantic-bugs-usermode/test/2089 new file mode 100644 index 000000000..4241b84e5 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/2089 @@ -0,0 +1,40 @@ +instruction: 0.901 +semantic: 0.855 +graphic: 0.833 +device: 0.746 +vnc: 0.500 +assembly: 0.466 +network: 0.405 +socket: 0.335 +boot: 0.172 +mistranslation: 0.117 +KVM: 0.086 +other: 0.022 + +aarch64: incorrect emulation of sqshrn instruction +Description of problem: +`sqshrn` instruction test fails with qemu-aarch64, but passes on real aarch64 hardware. +Steps to reproduce: +1. Build [inline_asm_tests](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/libs/binary_translation/tests/inline_asm_tests/) and run with qemu-aarch64 +2. Observe two failures + +``` +[ RUN ] Arm64InsnTest.SignedSaturatingShiftRightNarrowInt16x1 +frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc:6697: Failure +Expected equality of these values: + res1 + Which is: 4294967188 + MakeUInt128(0x94U, 0U) + Which is: 148 +[ FAILED ] Arm64InsnTest.SignedSaturatingShiftRightNarrowInt16x1 (5 ms) +[ RUN ] Arm64InsnTest.SignedSaturatingRoundingShiftRightNarrowInt16x1 +frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc:6793: Failure +Expected equality of these values: + res3 + Which is: 4294967168 + MakeUInt128(0x0000000000000080ULL, 0x0000000000000000ULL) + Which is: 128 +[ FAILED ] Arm64InsnTest.SignedSaturatingRoundingShiftRightNarrowInt16x1 (2 ms) +``` +Additional information: +[Direct link to SignedSaturatingShiftRightNarrowInt16x1 test source](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc;l=6692;drc=4ee2c3035fa5dc0b7a48b6c6dc498296be071861) diff --git a/results/classifier/semantic-bugs-usermode/test/2175 b/results/classifier/semantic-bugs-usermode/test/2175 new file mode 100644 index 000000000..874c3bcde --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/2175 @@ -0,0 +1,51 @@ +instruction: 0.883 +device: 0.776 +graphic: 0.745 +assembly: 0.701 +network: 0.686 +vnc: 0.644 +other: 0.619 +socket: 0.611 +mistranslation: 0.593 +KVM: 0.567 +semantic: 0.514 +boot: 0.511 + +Intel BLSI CF computation bug +Description of problem: +CF flag computation of BLSI instruction is wrong. It seems #1370 was not completely fixed. +Steps to reproduce: +1. Compile `example.c` using this command: `gcc -o example.bin example.c`. My gcc version is 12.3.0, but other versions may work. +``` +int main() { + __asm__ ( + "movq $0x1, %r8\n" + "mov $0xedbf530a, %r9\n" + "push $0x1\n" + "popf\n" + "blsi %r9d, %r8d\n" + "pushf\n" + "pop %rax\n" + "pop %rbp\n" + "ret\n" + ); + + return 0; +} +``` +2. Run `./example.bin`. Then check the return code using `echo $?`. It should be 3. +``` +$ ./example.bin +$ echo $? +3 +``` +3. Run `./qemu-x86_64 ./example.bin`. Then check the return code using `echo $?`. It should be 2. +``` +$ ./qemu-x86_64 ./example.bin +$ echo $? +2 +``` + +The return code of `./example.bin` contains the value of the `RFLAGS` register after executing the `BLSI` instruction. +Additional information: + diff --git a/results/classifier/semantic-bugs-usermode/test/2248 b/results/classifier/semantic-bugs-usermode/test/2248 new file mode 100644 index 000000000..ae3a6196e --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/2248 @@ -0,0 +1,49 @@ +instruction: 0.883 +graphic: 0.837 +assembly: 0.815 +device: 0.776 +vnc: 0.746 +network: 0.743 +socket: 0.741 +other: 0.592 +boot: 0.547 +semantic: 0.539 +KVM: 0.475 +mistranslation: 0.466 + +qemu-aarch64: wrong execution result when executing the code +Description of problem: +The following aarch64 code results in the wrong execution result `4611686018427387903`, which is `0x3fffffffffffffff`. (The correct result is `-1`) The bug seems to be introduced in between v8.1.5 and v8.2.1 since the results are correct in v8.1.5. + +```c +// foo.c +#include <stdio.h> +#include <stdint.h> + +int64_t callme(size_t _1, size_t _2, int64_t a, int64_t b, int64_t c); + +int main() { + int64_t ret = callme(0, 0, 0, 1, 2); + printf("%ld\n", ret); + return 0; +} +``` + +```s +// foo.S +.global callme +callme: + cmp x2, x3 + cset x12, lt + and w11, w12, #0xff + cmp w11, #0x0 + csetm x14, ne + lsr x13, x14, x4 + sxtb x0, w13 + ret +``` +Steps to reproduce: +1. Build the code with `aarch64-linux-gnu-gcc foo.c foo.S -o foo` (`aarch64-linux-gnu-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0`) +2. Run the code with `qemu-aarch64 -L /usr/aarch64-linux-gnu -E LD_LIBRARY_PATH=/usr/aarch64-linux-gnu/lib foo` and see the result +Additional information: +- Original discussion is held in [this wasmtime issue](https://github.com/bytecodealliance/wasmtime/issues/8233). Thanks to Alex Crichton for clarifying this bug. diff --git a/results/classifier/semantic-bugs-usermode/test/2302 b/results/classifier/semantic-bugs-usermode/test/2302 new file mode 100644 index 000000000..dd607123b --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/2302 @@ -0,0 +1,38 @@ +instruction: 0.900 +graphic: 0.787 +device: 0.692 +assembly: 0.569 +socket: 0.543 +semantic: 0.466 +vnc: 0.348 +network: 0.348 +mistranslation: 0.316 +other: 0.274 +boot: 0.240 +KVM: 0.084 + +qemu-x86_64 crashes with "Illegal Instruction" on SPECCPU2017 Benchmarks +Description of problem: +I am running qemu-x86_64 with SPEC CPU 2017 benchmarks, and the compiled benchmarks such as Perlbench will crash unexpectedly. I have changed to three other machines to run it and still get crashes on two of them, I don't know what's the problem and want some help. +Steps to reproduce: +1. Compile SPEC CPU 2017 basic Perlbench binary. +2. Use the above command line to run it. +Additional information: +I have added some debugging flags to qemu-x86_64 to test it. The "-d in_asm" flag gives me the instructions before the crash like this: +``` +---------------- +IN: Perl_lex_start +0x555555678a79: 48 89 83 a8 00 00 00 movq %rax, 0xa8(%rbx) +0x555555678a80: e9 01 ff ff ff jmp 0x555555678986 + +---------------- +IN: Perl_lex_start +0x555555678986: 48 8b 50 10 movq 0x10(%rax), %rdx +0x55555567898a: 41 83 e4 16 andl $0x16, %r12d +0x55555567898e: 48 89 93 d0 00 00 00 movq %rdx, 0xd0(%rbx) +0x555555678995: 48 89 93 c0 00 00 00 movq %rdx, 0xc0(%rbx) +0x55555567899c: 62 .byte 0x62 + +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction (core dumped) +``` diff --git a/results/classifier/semantic-bugs-usermode/test/2317 b/results/classifier/semantic-bugs-usermode/test/2317 new file mode 100644 index 000000000..0acfd4575 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/2317 @@ -0,0 +1,51 @@ +instruction: 0.951 +device: 0.841 +socket: 0.672 +graphic: 0.665 +vnc: 0.650 +network: 0.620 +semantic: 0.613 +assembly: 0.550 +boot: 0.545 +mistranslation: 0.480 +other: 0.332 +KVM: 0.048 + +SH4: ADDV instruction not emulated properly +Description of problem: +ADDV opcode is emulated incorrectly. + +The documentation says: + +`ADDV Rm, Rn Rn + Rm -> Rn, overflow -> T` + +What Qemu actually emulates: + +`ADDV Rm, Rn Rn + Rm -> Rm, overflow -> T` +Steps to reproduce: +```c +#include <stdio.h> + +int main(void) +{ + register unsigned int a asm("r8") = 0x7fffffff; + register unsigned int b asm("r9") = 1; + register unsigned int c asm("r10"); + + asm volatile("clrt\n" + "addv %2,%0\n" + "movt %1\n" + : "+r"(a), "=r"(c) : "r"(b) :); + + printf("Values: a=0x%x b=0x%x c=0x%x\n", a, b, c); + + return 0; +} + +``` +Additional information: +Tested on real hardware (SEGA Dreamcast, GCC 15.0), the program above prints: +`Values: a=0x80000000 b=0x1 c=0x1` + +Running with Qemu (and GCC 13.0), the same program prints: +`Values: a=0x7fffffff b=0x80000000 c=0x1` diff --git a/results/classifier/semantic-bugs-usermode/test/2318 b/results/classifier/semantic-bugs-usermode/test/2318 new file mode 100644 index 000000000..3defce0d6 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/2318 @@ -0,0 +1,47 @@ +instruction: 0.871 +device: 0.679 +graphic: 0.495 +assembly: 0.485 +vnc: 0.479 +semantic: 0.460 +boot: 0.291 +socket: 0.281 +network: 0.239 +other: 0.133 +mistranslation: 0.100 +KVM: 0.006 + +SH4: SUBV instruction not emulated properly +Description of problem: +SUBV opcode is emulated incorrectly. + +The documentation says: + +`SUBV Rm, Rn Rn - Rm -> Rn, underflow -> T` + +Qemu seems to perform the subtraction correctly, but will not detect an underflow. +Steps to reproduce: +```c +#include <stdio.h> + +int main(void) +{ + register unsigned int a asm("r8") = 0x80000001; + register unsigned int b asm("r9") = 0x2; + register unsigned int c asm("r10"); + + asm volatile("subv %2,%0\n" + "movt %1\n" + : "+r"(a), "=r"(c) : "r"(b) :); + + printf("Values: a=0x%x b=0x%x c=0x%x\n", a, b, c); + + return 0; +} +``` +Additional information: +Tested on real hardware (SEGA Dreamcast, GCC 15.0), the program above prints: +`Values: a=0x7fffffff b=0x2 c=0x1` + +Running with Qemu (and GCC 13.0), the same program prints: +`Values: a=0x7fffffff b=0x2 c=0x0` diff --git a/results/classifier/semantic-bugs-usermode/test/2371 b/results/classifier/semantic-bugs-usermode/test/2371 new file mode 100644 index 000000000..2db65ca18 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/2371 @@ -0,0 +1,65 @@ +other: 0.840 +semantic: 0.839 +graphic: 0.831 +mistranslation: 0.816 +vnc: 0.770 +socket: 0.722 +network: 0.699 +instruction: 0.679 +device: 0.671 +assembly: 0.628 +boot: 0.550 +KVM: 0.531 + +A bug in RISC-V froundnx.h instruction +Description of problem: +According to the RISCV ISA manual, the froundnx.h instruction rounds a half-precision floating-point number in the source register to an integer and writes the integer, represented as a half-precision floating-point number, to the destination register. Because the values are stored in 64-bit width registers, they must be NaN-unboxed/boxed before/after the operation. When an input value lacks the proper form of NaN-boxing, it should be treated as a canonical NaN. +However, when an incorrectly NaN-boxed value is passed to froundnx.h, QEMU produces 0 instead of the canonical NaN. This is because there is a typo in the definition of helper_froundnx_h: +``` +// target/riscv/fpu_helper.c +uint64_t helper_froundnx_h(CPURISCVState *env, uint64_t rs1) +{ + float16 frs1 = check_nanbox_s(env, rs1); // This should be check_nanbox_h. + frs1 = float16_round_to_int(frs1, &env->fp_status); + return nanbox_h(env, frs1); +} +``` +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdio.h> + +char i_F6[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; +char o_F5[8]; + +void __attribute__ ((noinline)) show_state() { + for (int i = 0; i < 8; i++) { + printf("%02x ", o_F5[i]); + } + printf("\n"); +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + "lui t5, %hi(i_F6)\n" + "addi t5, t5, %lo(i_F6)\n" + "fld ft6, 0(t5)\n" + ".insn 0x445372d3\n" // froundnx.h ft5, ft6 + "lui t5, %hi(o_F5)\n" + "addi t5, t5, %lo(o_F5)\n" + "fsd ft5, 0(t5)\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + + return 0; +} +``` +2. Compile `test.bin` using this command: `riscv64-linux-gnu-gcc-12 -O2 -no-pie -march=rv64iv ./test.c -o ./test.bin`. +3. Run QEMU using this command: `qemu-riscv64 -L /usr/riscv64-linux-gnu/ ./test.bin`. +4. The program, runs on top of the buggy QEMU, prints `00 00 ff ff ff ff ff ff`. It should print `00 7e ff ff ff ff ff ff` after the bug is fixed. +Additional information: + diff --git a/results/classifier/semantic-bugs-usermode/test/2372 b/results/classifier/semantic-bugs-usermode/test/2372 new file mode 100644 index 000000000..577fd84ae --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/2372 @@ -0,0 +1,122 @@ +other: 0.980 +graphic: 0.975 +semantic: 0.973 +instruction: 0.950 +assembly: 0.946 +device: 0.939 +socket: 0.930 +network: 0.922 +vnc: 0.901 +boot: 0.887 +mistranslation: 0.862 +KVM: 0.808 + +A bug in AArch64 UMOPA/UMOPS (4-way) instruction +Description of problem: +umopa computes the multiplication of two matrices in the source registers and accumulates the result to the destination register. A source register’s element size is 16 bits, while a destination register’s element size is 64 bits in case of the 4-way variant of this instruction. Before performing matrix multiplication, each element should be zero-extended to a 64-bit element. + +However, the current implementation of the helper function fails to convert the element type correctly. Below is the helper function implementation: +``` +// target/arm/tcg/sme_helper.c +#define DEF_IMOP_64(NAME, NTYPE, MTYPE) \ +static uint64_t NAME(uint64_t n, uint64_t m, uint64_t a, uint8_t p, bool neg) \ +{ \ + uint64_t sum = 0; \ + /* Apply P to N as a mask, making the inactive elements 0. */ \ + n &= expand_pred_h(p); \ + sum += (NTYPE)(n >> 0) * (MTYPE)(m >> 0); \ + sum += (NTYPE)(n >> 16) * (MTYPE)(m >> 16); \ + sum += (NTYPE)(n >> 32) * (MTYPE)(m >> 32); \ + sum += (NTYPE)(n >> 48) * (MTYPE)(m >> 48); \ + return neg ? a - sum : a + sum; \ +} + +DEF_IMOP_64(umopa_d, uint16_t, uint16_t) +``` +When the multiplication is performed, each element, such as `(NTYPE)(n >> 0)`, is automatically converted to `int32_t`, so the computation result has a type `int32_t`. The result is then converted to `uint64_t`, and it is added to `sum`. It seems the elements should be casted to `uint64_t` **before** performing the multiplication. +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdio.h> + +char i_P1[4] = { 0xff, 0xff, 0xff, 0xff }; +char i_P5[4] = { 0xff, 0xff, 0xff, 0xff }; +char i_Z0[32] = { // Set only the first element as non-zero + 0xff, 0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, +}; +char i_Z20[32] = { // Set only the first element as non-zero + 0xff, 0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, +}; +char i_ZA2H[128] = { 0x0, }; +char o_ZA2H[128]; + +void __attribute__ ((noinline)) show_state() { + for (int i = 0; i < 8; i++) { + for (int j = 0; j < 16; j++) { + printf("%02x ", o_ZA2H[16*i+j]); + } + printf("\n"); + } +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + ".arch armv9.3-a+sme\n" + "smstart\n" + "adrp x29, i_P1\n" + "add x29, x29, :lo12:i_P1\n" + "ldr p1, [x29]\n" + "adrp x29, i_P5\n" + "add x29, x29, :lo12:i_P5\n" + "ldr p5, [x29]\n" + "adrp x29, i_Z0\n" + "add x29, x29, :lo12:i_Z0\n" + "ldr z0, [x29]\n" + "adrp x29, i_Z20\n" + "add x29, x29, :lo12:i_Z20\n" + "ldr z20, [x29]\n" + "adrp x29, i_ZA2H\n" + "add x29, x29, :lo12:i_ZA2H\n" + "mov x15, 0\n" + "ld1d {za2h.d[w15, 0]}, p1, [x29]\n" + "add x29, x29, 32\n" + "ld1d {za2h.d[w15, 1]}, p1, [x29]\n" + "add x29, x29, 32\n" + "mov x15, 2\n" + "ld1d {za2h.d[w15, 0]}, p1, [x29]\n" + "add x29, x29, 32\n" + "ld1d {za2h.d[w15, 1]}, p1, [x29]\n" + ".inst 0xa1f43402\n" // umopa za2.d, p5/m, p1/m, z0.h, z20.h + "adrp x29, o_ZA2H\n" + "add x29, x29, :lo12:o_ZA2H\n" + "mov x15, 0\n" + "st1d {za2h.d[w15, 0]}, p1, [x29]\n" + "add x29, x29, 32\n" + "st1d {za2h.d[w15, 1]}, p1, [x29]\n" + "add x29, x29, 32\n" + "mov x15, 2\n" + "st1d {za2h.d[w15, 0]}, p1, [x29]\n" + "add x29, x29, 32\n" + "st1d {za2h.d[w15, 1]}, p1, [x29]\n" + "smstop\n" + ".arch armv8-a\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + return 0; +} +``` +2. Compile `test.bin` using this command: `aarch64-linux-gnu-gcc-12 -O2 -no-pie ./test.c -o ./test.bin`. +3. Run `QEMU` using this command: `qemu-aarch64 -L /usr/aarch64-linux-gnu/ -cpu max,sme256=on ./test.bin`. +4. The program, runs on top of the buggy QEMU, prints the first 8 bytes of `ZA2H` as `01 00 fe ff ff ff ff ff`. It should print `01 00 fe ff 00 00 00 00` after the bug is fixed. +Additional information: + diff --git a/results/classifier/semantic-bugs-usermode/test/2374 b/results/classifier/semantic-bugs-usermode/test/2374 new file mode 100644 index 000000000..676db53f4 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/2374 @@ -0,0 +1,124 @@ +other: 0.893 +instruction: 0.885 +device: 0.878 +graphic: 0.876 +vnc: 0.873 +semantic: 0.872 +assembly: 0.865 +boot: 0.833 +network: 0.812 +KVM: 0.804 +mistranslation: 0.792 +socket: 0.782 + +A bug in AArch64 FMOPA/FMOPS (non-widening) instruction +Description of problem: +fmopa computes the multiplication of two matrices in the source registers and accumulates the result to the destination register. Depending on the instruction encoding, the element size of operands is either 32 bits or 64 bits. When the computation produces a NaN as a result, the default NaN should be generated. + +However, the current implementation of 32-bit variant of this instruction does not generate default NaNs, because invalid float_status pointer is passed: +``` +// target/arm/tcg/sme_helper.c +void HELPER(sme_fmopa_s)(void *vza, void *vzn, void *vzm, void *vpn, + void *vpm, void *vst, uint32_t desc) +{ +... + float_status fpst; + + /* + * Make a copy of float_status because this operation does not + * update the cumulative fp exception status. It also produces + * default nans. + */ + fpst = *(float_status *)vst; + set_default_nan_mode(true, &fpst); + +... + *a = float32_muladd(n, *m, *a, 0, vst); // &fpst should be used +... +} +``` +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdio.h> + +char i_P0[4] = { 0xff, 0xff, 0xff, 0xff }; +char i_P6[4] = { 0xff, 0xff, 0xff, 0xff }; +char i_Z9[32] = { // Set only the first element as NaN, but it is not default NaN. + 0xff, 0xff, 0xff, 0xff, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, +}; +char i_Z27[32] = { + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, +}; +char i_ZA1H[128] = { 0x0, }; +char o_ZA1H[128]; + +void __attribute__ ((noinline)) show_state() { + for (int i = 0; i < 8; i++) { + for (int j = 0; j < 16; j++) { + printf("%02x ", o_ZA1H[16*i+j]); + } + printf("\n"); + } +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + ".arch armv9.3-a+sme\n" + "smstart\n" + "adrp x29, i_P0\n" + "add x29, x29, :lo12:i_P0\n" + "ldr p0, [x29]\n" + "adrp x29, i_P6\n" + "add x29, x29, :lo12:i_P6\n" + "ldr p6, [x29]\n" + "adrp x29, i_Z9\n" + "add x29, x29, :lo12:i_Z9\n" + "ldr z9, [x29]\n" + "adrp x29, i_Z27\n" + "add x29, x29, :lo12:i_Z27\n" + "ldr z27, [x29]\n" + "adrp x29, i_ZA1H\n" + "add x29, x29, :lo12:i_ZA1H\n" + "mov x15, 0\n" + "ld1w {za1h.s[w15, 0]}, p0, [x29]\n" + "add x29, x29, 32\n" + "ld1w {za1h.s[w15, 1]}, p0, [x29]\n" + "add x29, x29, 32\n" + "mov x15, 2\n" + "ld1w {za1h.s[w15, 0]}, p0, [x29]\n" + "add x29, x29, 32\n" + "ld1w {za1h.s[w15, 1]}, p0, [x29]\n" + ".inst 0x809bc121\n" // fmopa za1.s, p0/m, p6/m, z9.s, z27.s + "adrp x29, o_ZA1H\n" + "add x29, x29, :lo12:o_ZA1H\n" + "mov x15, 0\n" + "st1w {za1h.s[w15, 0]}, p0, [x29]\n" + "add x29, x29, 32\n" + "st1w {za1h.s[w15, 1]}, p0, [x29]\n" + "add x29, x29, 32\n" + "mov x15, 2\n" + "st1w {za1h.s[w15, 0]}, p0, [x29]\n" + "add x29, x29, 32\n" + "st1w {za1h.s[w15, 1]}, p0, [x29]\n" + ".arch armv8-a\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + return 0; +} +``` +2. Compile `test.bin` using this command: `aarch64-linux-gnu-gcc-12 -O2 -no-pie ./test.c -o ./test.bin`. +3. Run QEMU using this command: `qemu-aarch64 -L /usr/aarch64-linux-gnu/ -cpu max,sme256=on ./test.bin`. +4. The program, runs on top of the buggy QEMU, prints 8 non-default NaNs (ff ff ff ff). It should print 8 default NaNs (00 00 c0 7f) after the bug is fixed. +Additional information: + diff --git a/results/classifier/semantic-bugs-usermode/test/2386 b/results/classifier/semantic-bugs-usermode/test/2386 new file mode 100644 index 000000000..96e88af3c --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/2386 @@ -0,0 +1,56 @@ +instruction: 0.967 +graphic: 0.899 +socket: 0.812 +device: 0.808 +vnc: 0.803 +network: 0.759 +assembly: 0.688 +mistranslation: 0.640 +semantic: 0.624 +other: 0.616 +boot: 0.615 +KVM: 0.565 + +RISCV - Incorrect behaviour of the SLL instruction +Description of problem: +`SLL` (and probably other similar instructions) produce incorrect results. To quote the [RISCV ISA manual](https://drive.google.com/file/d/1uviu1nH-tScFfgrovvFCrj7Omv8tFtkp/view): + +> SLL, SRL, and SRA perform logical left, logical right, and arithmetic right shifts on the value in register +rs1 by the shift amount held in the lower 5 bits of register rs2. + +This instruction should perform a logical shift left by the shift amount from the lower 5 bits held in the third operand, however, it doesn't seem to be the case. As can be seen from the result of the snippet below: `55c3585000000000`, it seems that it calculates the correct value, but then shifts it by another 32 bits to the left: + +```python +correct_shift_res = (0xDB4D6868655C3585 << (0x69C99AB9B9401024 & 0b11111)) & (2 ** 64 - 1) +incorrect_qemu_produced = (correct_shift_res << 32) & (2 ** 64 - 1) +``` +Steps to reproduce: +1. Compile the attached source file: `riscv64-linux-gnu-gcc -static repro.c -o ./repro.elf` + +```c +#include <stdint.h> +#include <stdio.h> + +int main() { + uint64_t a = 0x69C99AB9B9401024; + uint64_t b = 0xDB4D6868655C3585; + uint64_t c; + + asm volatile("sll %0, %1, %2" : "=r"(c) : "r"(b), "r"(a)); + + printf("s8 : %lx\n", c); + printf("expected: %lx\n", 0xb4d6868655c35850); + + return 0; +} +``` + +2. Run qemu: `./qemu-riscv64 ./repro.elf` +3. You will see the output and what the result of the computation should really be: + +``` +s8 : 55c3585000000000 +expected: b4d6868655c35850 +``` +Additional information: + diff --git a/results/classifier/semantic-bugs-usermode/test/2497 b/results/classifier/semantic-bugs-usermode/test/2497 new file mode 100644 index 000000000..ccc110c51 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/2497 @@ -0,0 +1,16 @@ +instruction: 0.895 +device: 0.848 +graphic: 0.685 +semantic: 0.655 +network: 0.531 +boot: 0.293 +socket: 0.291 +assembly: 0.286 +vnc: 0.283 +other: 0.236 +mistranslation: 0.145 +KVM: 0.015 + +m68k: fpu: FPIAR register is not implemented +Description of problem: +QEMU doesn't currently implement the `FPIAR` register in the FPU which is fine in most cases but test code (like that in 147bug) that is testing if instructions like `fmove` are working correctly by writing to the register and reading it back don't get the value written when reading it back and detect a failure. diff --git a/results/classifier/semantic-bugs-usermode/test/2500 b/results/classifier/semantic-bugs-usermode/test/2500 new file mode 100644 index 000000000..4939d31cc --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/2500 @@ -0,0 +1,17 @@ +instruction: 0.946 +graphic: 0.818 +device: 0.817 +semantic: 0.810 +assembly: 0.807 +mistranslation: 0.739 +network: 0.738 +other: 0.715 +socket: 0.510 +boot: 0.257 +vnc: 0.154 +KVM: 0.115 + +m68k: mmu: 68030 mmu instructions are missing +Description of problem: +The 68030 has some mmu instructions like `pmove` that are only valid for the 68030 (and maybe the external mmu for the 68020??). +QEMU doesn't currently implement `pmove` and the encoding of `pmove` seems to be the same as an f-line instruction that should generate an f-line exception on everything except the 68030 so currently an f-line exception happens instead of the intended load/store to the mmu. diff --git a/results/classifier/semantic-bugs-usermode/test/2595 b/results/classifier/semantic-bugs-usermode/test/2595 new file mode 100644 index 000000000..e0e1afbe0 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/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 <stdio.h> + #include <arm_sve.h> + + 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-usermode/test/266 b/results/classifier/semantic-bugs-usermode/test/266 new file mode 100644 index 000000000..4824b4c1d --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/266 @@ -0,0 +1,14 @@ +mistranslation: 0.986 +instruction: 0.937 +device: 0.742 +semantic: 0.592 +network: 0.416 +other: 0.357 +graphic: 0.350 +boot: 0.238 +socket: 0.112 +assembly: 0.101 +vnc: 0.084 +KVM: 0.032 + +'mtfsf' instruction can clear FI incorrectly diff --git a/results/classifier/semantic-bugs-usermode/test/2865 b/results/classifier/semantic-bugs-usermode/test/2865 new file mode 100644 index 000000000..993bac92e --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/2865 @@ -0,0 +1,65 @@ +instruction: 0.901 +assembly: 0.741 +mistranslation: 0.694 +device: 0.653 +graphic: 0.618 +socket: 0.439 +vnc: 0.390 +network: 0.364 +other: 0.326 +boot: 0.235 +semantic: 0.210 +KVM: 0.187 + +loongarch64: wrong implementation of `xvldi` instruction +Description of problem: +Consider this sample program. + +```c++ +#include <cstdio> +#include <cstdint> +#include <lsxintrin.h> +#include <lasxintrin.h> + +void dump_u32(__m256i x) { + uint32_t tmp[32/4]; + __lasx_xvst(x, tmp, 0); + putchar('['); + for (int i=0; i < 32/4; i++) { + if (i > 0) { + putchar(' '); + } + + printf("%08x", tmp[i]); + } + puts("]"); +} + +int main() { + __m256i const1 = __lasx_xvldi(-3832); + dump_u32(const1); +} +``` + +The magic constants here means: replicate in 32-bit words a byte (0x4) shifted left by 8. We should have a vector of words 0x800, and indeed, the program run on a real hardware prints expected: + +``` +[00000800 00000800 00000800 00000800 00000800 00000800 00000800 00000800] +``` + +The same program run under Qemu prints: + +``` +[08000800 00000000 08000800 00000000 08000800 00000000 08000800 00000000] +``` +Additional information: +I grabbed the latest sources, it seems there's bug in `target/loongarch/tcg/insn_trans/trans_vec.c.inc`, in function `vldi_get_value`. + +```c + case 1: + /* data: {2{16'0, imm[7:0], 8'0}} */ + data = (t << 24) | (t << 8); + break; +``` + +There should be `(t << (8+32)) | t << 8`. diff --git a/results/classifier/semantic-bugs-usermode/test/2971 b/results/classifier/semantic-bugs-usermode/test/2971 new file mode 100644 index 000000000..2ee49f8b8 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/2971 @@ -0,0 +1,57 @@ +instruction: 0.834 +vnc: 0.780 +device: 0.770 +assembly: 0.671 +network: 0.667 +socket: 0.623 +graphic: 0.579 +semantic: 0.515 +boot: 0.473 +other: 0.425 +KVM: 0.396 +mistranslation: 0.282 + +loongarch64 crashes caused by lenient instruction decoding of vldi and xvldi +Description of problem: +Lenient instruction decoding of `vldi` and `xvldi` leads to Qemu crashes. + +The decoding of `vldi` and `xvldi` instruction allows for instructions with illegal immediates. + +`target/loongarch/insns.decode`: + +``` +vldi 0111 00111110 00 ............. ..... @v_i13 +xvldi 0111 01111110 00 ............. ..... @v_i13 +``` + +This is considered in `target/loongarch/tcg/insn_trans/trans_vec.c.inc`: + +```C + /* + * imm bit [11:8] is mode, mode value is 0-12. + * other values are invalid. + */ +``` + +However, an assertion error is raised when this condition is violated and qemu crashes: + +``` +** +ERROR:target/loongarch/insn_trans/trans_vec.c.inc:3574:vldi_get_value: code should not be reached +Bail out! ERROR:target/loongarch/insn_trans/trans_vec.c.inc:3574:vldi_get_value: code should not be reached +``` + +On hardware (Loongson 3A5000), these instructions cause a SIGILL. +Steps to reproduce: +1. compile the `test_inv_vldi` test program for loongarch64 (see additional information) +2. run `qemu-loongarch64-static ./test_inv_vldi` +Additional information: +I will post a patch for this issue to the mailing list soon. + +`test_inv_vldi` source code: + +```C +int main(int argc, char** argv) { + asm volatile(".4byte 0x73e3a000"); +} +``` diff --git a/results/classifier/semantic-bugs-usermode/test/361 b/results/classifier/semantic-bugs-usermode/test/361 new file mode 100644 index 000000000..ee26ed4b0 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/361 @@ -0,0 +1,14 @@ +instruction: 0.829 +mistranslation: 0.634 +semantic: 0.465 +graphic: 0.432 +vnc: 0.253 +device: 0.243 +boot: 0.163 +KVM: 0.134 +other: 0.106 +assembly: 0.014 +network: 0.006 +socket: 0.006 + +-cpu host results in unsupported AVX512 instructions diff --git a/results/classifier/semantic-bugs-usermode/test/390 b/results/classifier/semantic-bugs-usermode/test/390 new file mode 100644 index 000000000..61671b821 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/390 @@ -0,0 +1,14 @@ +instruction: 0.961 +assembly: 0.706 +device: 0.526 +graphic: 0.370 +semantic: 0.361 +boot: 0.196 +KVM: 0.175 +mistranslation: 0.162 +vnc: 0.116 +network: 0.058 +socket: 0.029 +other: 0.019 + +target/ppc: atomic path of Load Quadword instruction require address with write permission diff --git a/results/classifier/semantic-bugs-usermode/test/427 b/results/classifier/semantic-bugs-usermode/test/427 new file mode 100644 index 000000000..c11b42a46 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/427 @@ -0,0 +1,14 @@ +mistranslation: 0.924 +instruction: 0.887 +device: 0.849 +network: 0.621 +boot: 0.337 +socket: 0.323 +graphic: 0.321 +semantic: 0.236 +assembly: 0.194 +vnc: 0.187 +other: 0.178 +KVM: 0.003 + +TCG: QEMU incorrectly raises exception on SSE4.2 CRC32 instruction diff --git a/results/classifier/semantic-bugs-usermode/test/508 b/results/classifier/semantic-bugs-usermode/test/508 new file mode 100644 index 000000000..b05d57a9e --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/508 @@ -0,0 +1,14 @@ +mistranslation: 0.964 +device: 0.838 +instruction: 0.772 +other: 0.598 +network: 0.591 +graphic: 0.501 +semantic: 0.261 +boot: 0.211 +assembly: 0.091 +vnc: 0.078 +socket: 0.066 +KVM: 0.009 + +x86_64 cmpxchg behavior in qemu tcg does not match the real CPU diff --git a/results/classifier/semantic-bugs-usermode/test/904308 b/results/classifier/semantic-bugs-usermode/test/904308 new file mode 100644 index 000000000..a32657642 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/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-usermode/test/984 b/results/classifier/semantic-bugs-usermode/test/984 new file mode 100644 index 000000000..0458e2758 --- /dev/null +++ b/results/classifier/semantic-bugs-usermode/test/984 @@ -0,0 +1,36 @@ +instruction: 0.978 +device: 0.870 +semantic: 0.790 +network: 0.753 +socket: 0.751 +vnc: 0.711 +graphic: 0.657 +boot: 0.586 +assembly: 0.462 +other: 0.443 +KVM: 0.336 +mistranslation: 0.140 + +QEMU i386 fldl instruction is affected by the precision control bits of the FPU control word +Description of problem: +~~The QEMU softfloat float64_to_floatx80 implementation is broken and does not produce correct results.~~ QEMU i386 fldl instruction is affected by the precision control bits of the FPU control word. + +``` +IN = 1234.567890 (0x40934a4584f4c6e7) +OUT = 1234.567871 (0x40099a522c0000000000) +``` + +This bug was introduced in the QEMU commit qemu/qemu@8ae5719 as part of the switchover to FloatParts, and is still present in the latest tag (v7.0.0-rc4 as of now). + +Prior to the offending commit: + +``` +IN = 1234.567890 (0x40934a4584f4c6e7) +OUT = 1234.567890 (0x40099a522c27a6373800) +``` + +This breaks the i386 emulation of `fldl st(0)` (`helper_fldl_ST0`). +Steps to reproduce: +Call `float64_to_floatx80` with the input value of `1234.567890 (0x40934a4584f4c6e7)` and see the returned result. +Additional information: +See https://github.com/zephyrproject-rtos/sdk-ng/issues/461 |