diff options
| author | Christian Krinitsin <mail@krinitsin.com> | 2025-07-05 20:00:38 +0200 |
|---|---|---|
| committer | Christian Krinitsin <mail@krinitsin.com> | 2025-07-05 20:00:38 +0200 |
| commit | 96049c939b1916d80532630d63c14e04d5244f1d (patch) | |
| tree | 7fb9df428f074078e714f1e038210cdff887185a /results/classifier/semantic-bugs | |
| parent | 40bbb77d4dfebff4f99c2f90b2c0db737b0ecc5a (diff) | |
| download | qemu-analysis-96049c939b1916d80532630d63c14e04d5244f1d.tar.gz qemu-analysis-96049c939b1916d80532630d63c14e04d5244f1d.zip | |
lock user-mode and semantic-bugs
Diffstat (limited to 'results/classifier/semantic-bugs')
85 files changed, 1886 insertions, 1270 deletions
diff --git a/results/classifier/semantic-bugs/1095857 b/results/classifier/semantic-bugs/1095857 index a74648b9b..3117b09da 100644 --- a/results/classifier/semantic-bugs/1095857 +++ b/results/classifier/semantic-bugs/1095857 @@ -1,15 +1,4 @@ -instruction: 0.914 -mistranslation: 0.764 -graphic: 0.736 -device: 0.679 -other: 0.555 -semantic: 0.442 -network: 0.323 -assembly: 0.286 -socket: 0.242 -boot: 0.214 -vnc: 0.198 -KVM: 0.114 + incorrect handling of [r32] address (long mode) @@ -21,9 +10,4 @@ end up executing as mov eax,[r15] -according to x86 programmer manuals the behavior of using the Address-Size override (in long mode) is supposed to ignore the high 32bits of the register. I use this fact in my operating system to reduce register usage (the high 32 bits of r15 holds other data). consequently a general protection exception occurs since the memory address isn't "canonical". this error doesn't always appear since the high 32 bits might not be zero in those conditions. - -You are correct about what the instruction is supposed to do. That said the behaviour you describe is not reproducible. Which version of QEMU are you using? Could you please send a testcase? - -[Expired for QEMU because there has been no activity for 60 days.] - +according to x86 programmer manuals the behavior of using the Address-Size override (in long mode) is supposed to ignore the high 32bits of the register. I use this fact in my operating system to reduce register usage (the high 32 bits of r15 holds other data). consequently a general protection exception occurs since the memory address isn't "canonical". this error doesn't always appear since the high 32 bits might not be zero in those conditions. \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1156 b/results/classifier/semantic-bugs/1156 index 83908c6d9..0a936d806 100644 --- a/results/classifier/semantic-bugs/1156 +++ b/results/classifier/semantic-bugs/1156 @@ -1,14 +1,3 @@ -instruction: 0.874 -mistranslation: 0.834 -device: 0.815 -assembly: 0.455 -graphic: 0.452 -semantic: 0.202 -boot: 0.139 -network: 0.079 -other: 0.068 -socket: 0.017 -KVM: 0.017 -vnc: 0.007 + Incorrect implementation of vmsumudm instruction diff --git a/results/classifier/semantic-bugs/1245543 b/results/classifier/semantic-bugs/1245543 index 99966ab81..b9f1b3bb8 100644 --- a/results/classifier/semantic-bugs/1245543 +++ b/results/classifier/semantic-bugs/1245543 @@ -1,15 +1,4 @@ -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 @@ -33,11 +22,4 @@ qemu-system-x86_64 \ -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.] - + --append "rw console=tty root=/dev/sda" \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1248168 b/results/classifier/semantic-bugs/1248168 index 22e04de30..b31cbfee2 100644 --- a/results/classifier/semantic-bugs/1248168 +++ b/results/classifier/semantic-bugs/1248168 @@ -1,15 +1,4 @@ -instruction: 0.820 -graphic: 0.800 -assembly: 0.749 -device: 0.731 -mistranslation: 0.533 -socket: 0.270 -boot: 0.257 -other: 0.250 -semantic: 0.231 -vnc: 0.131 -network: 0.118 -KVM: 0.030 + MIPS, self-modifying code and uncached memory @@ -34,9 +23,4 @@ For example, when running this code I get unexpected behavior: 3ac: 00000000 nop I expect that swr instruction in line 384 would change `addi t2,t2,1`0 to `nop` -This should work because no cache is used for this memory region. - -Can you please provide full reproduction steps rather than just an assembly snippet? - -[Expired for QEMU because there has been no activity for 60 days.] - +This should work because no cache is used for this memory region. \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1251 b/results/classifier/semantic-bugs/1251 new file mode 100644 index 000000000..d4f5a9a7d --- /dev/null +++ b/results/classifier/semantic-bugs/1251 @@ -0,0 +1,17 @@ + + +Octeon Instruction BBIT Bug +Steps to reproduce: +1. Compile 64bit binary for Octeon with Octeon instructions +`mips64-octeon-linux-gnu-gcc -o hello hello.c` +2. Run with `qemu-mips64` +`qemu-mips64 -cpu Octeon68XX hello` +3. Get the output below: +``` +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction +``` +Additional information: +I have a patch for this that I will be submitting to trivial-patches. This is not enough to emulate Octeon specific binaries alone. For small binaries mapping the `CVMSEG_LM = 0xFFFFFFFFFFFF8000 - 0xFFFFFFFFFFFF9FFF` to empty RAM and using this patch is enough. There are additional support issues for `N32` binaries that will require a separate issue. + +[hello](/uploads/d8b5e631508fd232b4a7b3a40f7e08f6/hello) diff --git a/results/classifier/semantic-bugs/1267955 b/results/classifier/semantic-bugs/1267955 index fe1635901..e9cb6da8b 100644 --- a/results/classifier/semantic-bugs/1267955 +++ b/results/classifier/semantic-bugs/1267955 @@ -1,15 +1,4 @@ -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 @@ -52,136 +41,4 @@ $ 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 - +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. \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1283519 b/results/classifier/semantic-bugs/1283519 new file mode 100644 index 000000000..34d05437c --- /dev/null +++ b/results/classifier/semantic-bugs/1283519 @@ -0,0 +1,12 @@ + + +PowerPC altivec rounding instructions vrfi(m|n|z)not correctly mapped + +When using ppc-linux-user/qemu-ppc on a ppc ELF executable, I see that QEMU wrongly recognizes the vrfim, vrfin and vrfiz instructions: + +If the binary contains vrfim QEMU sees vrfiz +If the binary contains vrfin QEMU sees vrfim +If the binary contains vrfiz QEMU sees vrfin +The vrfip instruction is correctly recognized. + +Those instructions normally round a floating-point altivec vector to zero (z), infinity (p), minus infinity (m) or nearest (n). \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1308381 b/results/classifier/semantic-bugs/1308381 new file mode 100644 index 000000000..df1cb782e --- /dev/null +++ b/results/classifier/semantic-bugs/1308381 @@ -0,0 +1,16 @@ + + +illegal instructions for AArch64 ARMv8 + +The test case is in the attachment. To reproduce as following (I tried both GCC and Clang): +$aarch64-linux-gnu-gcc qemu.c -o test +$./test +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction (core dumped) + +There are 3 intrinsics are tested in the test case: vqmovunh_s16, vqmovuns_s32, vqmovund_s64. They will be compiled into instructions: +SQXTUN Bd, Hn +SQXTUN Hd, Sn +SQXTUN Sd, Dn. + +It seems that these instructions are not supported in QEMU. Is this a bug? \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1368 b/results/classifier/semantic-bugs/1368 new file mode 100644 index 000000000..f8f9cc963 --- /dev/null +++ b/results/classifier/semantic-bugs/1368 @@ -0,0 +1,40 @@ + + +unexpect rax value +Description of problem: +- When I execute "mov -0x8(%rbp), %rax" and "movq 0xb8000, (%rax)", the value of rax should be 0x7fedf but it is 0x7fefe. It is 1 less. +Steps to reproduce: +- 1. Code currently executed +<pre> +(gdb) x/2i $pc +=> 0x2202 <vga_init+12>: mov -0x8(%rbp),%rax + 0x2206 <vga_init+16>: movq $0xb8000,(%rax) +</pre> +- 2. Value of memory address -0x8(%rbp) +<pre> +(gdb) x /xg $rbp-0x8 +0x7fec8: 0x000000000007fedf +</pre> +- 3. Value of rax before execution +<pre> +(gdb) p /x $rax +$1 = 0xfffffffd +</pre> +- 4. Value of rax after execution +<pre> +(gdb) p /x $rax +$1 = 0x7fedf +</pre> +It's all right so far. +- 5. View the current execution code again +<pre> +(gdb) x/i $pc +=> 0x2207 <vga_init+17>: movl $0xb8000,(%rax) +</pre> +the code address changed from 0x2206 to 0x2207 and the code changed from "movq xx, xx" to "movl xx, xx".<br> +Now rax is 0x7fedf. +- 6. After execution<br> +After executing "movl $0xb8000,(%rax)"<br> +The rax change to 0x7fede +Additional information: + diff --git a/results/classifier/semantic-bugs/1441 b/results/classifier/semantic-bugs/1441 new file mode 100644 index 000000000..8a63089da --- /dev/null +++ b/results/classifier/semantic-bugs/1441 @@ -0,0 +1,36 @@ + + +Assertion failure when executing RISC-V vfncvt.rtz.x.f.w instruction +Description of problem: +When emulating the `vfncvt.rtz.x.f.w` instruction, QEMU crashes with an assertion failure at `target/riscv/translate.c:211`, complaining that ```decode_save_opc: Assertion `ctx->insn_start != NULL' failed.``` + +It appears this problem first emerged with https://gitlab.com/qemu-project/qemu/-/commit/a9814e3e08d2aacbd9018c36c77c2fb652537848 +Steps to reproduce: +The following C program triggers the assertion failure when built a sufficiently recent version of the Clang cross compiler (in my case 15.0.6): +``` +/* test.c */ +#include <riscv_vector.h> + +#define LEN 4 + +int main(int argc, char *argv[]) { + double in[LEN]; + int out[LEN]; + + vfloat64m1_t vf = vle64_v_f64m1(in, LEN); + vint32mf2_t vi = vfncvt_rtz_x_f_w_i32mf2(vf, LEN); + vse32_v_i32mf2(out, vi, LEN); + + return 0; +} +``` + +The above `test.c` can be compiled and run as follows: +``` +clang -O3 -march=rv64gcv -static test.c +qemu-riscv64 -cpu "rv64,zba=true,zbb=true,zbc=true,zbs=true,v=true,vlen=512,elen=64,vext_spec=v1.0" a.out +qemu-riscv64: ../target/riscv/translate.c:211: decode_save_opc: Assertion `ctx->insn_start != NULL' failed. +Segmentation fault (core dumped) +``` +Additional information: + diff --git a/results/classifier/semantic-bugs/1536 b/results/classifier/semantic-bugs/1536 new file mode 100644 index 000000000..c6685bb02 --- /dev/null +++ b/results/classifier/semantic-bugs/1536 @@ -0,0 +1,18 @@ + + +Test programs that use the vextractbm, vextracthm, vextractwm, or vextractdm instructions fail on qemu-ppc64 (but not qemu-ppc64le) +Description of problem: +Some of the test programs that use the vextractbm, vextracthm, vextractwm, or vextractdm instructions fail on qemu-ppc64 (but not qemu-ppc64le). +Steps to reproduce: +1. Download the vsx_mask_extract_runnable_test_030723.c test program from https://gist.githubusercontent.com/johnplatts/db0e9f6683e85e9288fde5c031b3c0e5/raw/ccfb8170f3e613398750830451eebb362875493d/vsx_mask_extract_runnable_test_030723.c. +2. Install the ppc64 gcc cross-compiler and required libraries, which can be done using the ```sudo apt install build-essential gdb-multiarch g++-12-powerpc64-linux-gnu binutils-powerpc64-linux-gnu binutils-powerpc64-linux-gnu-dbg libc6-ppc64-cross libstdc++6-ppc64-cross``` command on Ubuntu 22.04. +3. Compile the vsx_mask_extract_runnable_test_030723.c test program downloaded in step 1 using the ```powerpc64-linux-gnu-gcc-12``` cross-compiler with the ```-mcpu=power10``` option. +4. Execute the program compiled in step 3 using the ```QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu qemu-ppc64 -cpu power10 ./vsx_mask_extract_runnable_test_030723``` command. + +The issue can also be reproduced by compiling Google Highway and running its unit tests as follows: +1. Clone the Google Highway git repository by running the ```git clone https://github.com/google/highway.git google_highway``` command. +2. Create a ```hwy_ppcbe10_build``` directory inside of the ```google_highway``` directory created in step #1. +3. In the ```hwy_ppc10be_build``` directory created in the previous step, execute the following commands: + - ```CC=powerpc64-linux-gnu-gcc-12 CXX=powerpc64-linux-gnu-g++-12 cmake .. -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER_TARGET="powerpc64-linux-gnu" -DCMAKE_CXX_COMPILER_TARGET="powerpc64-linux-gnu" -DCMAKE_CROSSCOMPILING=true -DCMAKE_CROSSCOMPILING_EMULATOR='/usr/local/bin/qemu-ppc64;-cpu;power10' -DCMAKE_C_FLAGS='-mcpu=power10 -DHWY_DISABLED_TARGETS=6918373452571213824' -DCMAKE_CXX_FLAGS='-mcpu=power10 -DHWY_DISABLED_TARGETS=6918373452571213824'``` + - ```QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu make``` + - ```QEMU_LD_PREFIX=/usr/powerpc64-linux-gnu ctest -j``` diff --git a/results/classifier/semantic-bugs/1574346 b/results/classifier/semantic-bugs/1574346 index 410bb5bab..488953105 100644 --- a/results/classifier/semantic-bugs/1574346 +++ b/results/classifier/semantic-bugs/1574346 @@ -1,15 +1,4 @@ -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 @@ -22,20 +11,4 @@ is to mark the GS segment unusable and set its base to zero. After doing this, 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.] - +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. \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1605123 b/results/classifier/semantic-bugs/1605123 new file mode 100644 index 000000000..aa00c2aa0 --- /dev/null +++ b/results/classifier/semantic-bugs/1605123 @@ -0,0 +1,30 @@ + + +PEXT returns wrong values, seemingly switches arguments + +Hi, + +I fiddled with BMI2 instructions and discovered that pext instructions +emulated with "qemu-x86_64 -cpu Haswell" return the wrong value. It +seemingly switches up its arguments. I suspect that the error is around the +gen_helper_pext(...) call in target-i386/translate.c. I checked helper_pext +in target-i386/int_helper.c and it works fine. + +I ran my program on a CPU with BMI2 instruction set too, and it indeed +returns different values. + +I didn't check pdep, it could have the same problem. + +$ qemu-x86_64 --version +qemu-x86_64 version 2.6.50 (v2.6.0-2095-ge66b05e-dirty), Copyright (c) 2003-2008 Fabrice Bellard + +$ uname -a +Linux lenard-hp 4.3.0-1-amd64 #1 SMP Debian 4.3.5-1 (2016-02-06) x86_64 GNU/Linux + +I compiled the attached file with the command line "gcc -o main -g -mbmi2 main.c". + +$ gcc --version +gcc (Debian 5.4.0-6) 5.4.0 20160609 + +Best regards, +Lénárd Szolnoki \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1612 b/results/classifier/semantic-bugs/1612 index aa2f4e529..6a4289038 100644 --- a/results/classifier/semantic-bugs/1612 +++ b/results/classifier/semantic-bugs/1612 @@ -1,15 +1,4 @@ -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: diff --git a/results/classifier/semantic-bugs/1642 b/results/classifier/semantic-bugs/1642 new file mode 100644 index 000000000..8a65d2e91 --- /dev/null +++ b/results/classifier/semantic-bugs/1642 @@ -0,0 +1,24 @@ + + +Qemu aarch64 tcg crashes when emulating an STXP instruction but only on a Windows host +Description of problem: +Qemu segfaults when trying to emulate an STXP instruction, but only when running natively on a windows host (msys2 build). This is not the same as https://gitlab.com/qemu-project/qemu/-/issues/1581. + +I've managed to git-bisect it to this change: https://github.com/qemu/qemu/commit/546789c7df8866c55cae8d3195e8e58328a35d51 +Sadly i cannot investigate it further and contribute a fix, but it seems like a problem with one of the I128 arguments to `helper_atomic_cmpxchgo_le ` + +UPD: Issue is also in master (as of `caa9cbd566877b34e9abcc04d936116fc5e0ab28`) +Steps to reproduce: +N/A +Additional information: +``` +Thread 9 received signal SIGSEGV, Segmentation fault. +0x00007ff67efc32dc in helper_atomic_cmpxchgo_le (env=0x24796b08c10, addr=18446684150325987376, oldv=46236672343829145701101521005152, newv=2595395441251766838621186119693696, oi=3650) at ../accel/tcg/atomic_common.c.inc:60 +60 CMPXCHG_HELPER(cmpxchgo_le, Int128) +(gdb) bt +#0 0x00007ff67efc32dc in helper_atomic_cmpxchgo_le (env=0x24796b08c10, + addr=18446684150325987376, oldv=46236672343829145701101521005152, + newv=2595395441251766838621186119693696, oi=3650) at ../accel/tcg/atomic_common.c.inc:60 +#1 0x00000247a124f73d in ?? () + +``` diff --git a/results/classifier/semantic-bugs/1713066 b/results/classifier/semantic-bugs/1713066 new file mode 100644 index 000000000..474df02a4 --- /dev/null +++ b/results/classifier/semantic-bugs/1713066 @@ -0,0 +1,21 @@ + + +Incorrect handling of aarch64 ldp in some cases + +In some cases the ldp instruction (and presumably other multi-register loads and stores) can behave incorrectly. + +Given the following instruction: +ldp x0, x1, [x0] + +This will load two 64 bit values from memory, however if each location to load is on a different page and the second page is unmapped this will raise an exception. When this happens x0 has already been updated so after the exception handler has run the operating system will try to rerun the instruction. QEMU will now try to perform an invalid load and raise a new exception. + +I believe this is incorrect as section D.1.14.5 of the ARMv8 reference manual B.a states that, on taking an exception, registers used in the generation of addresses are restored to their initial value, so x0 shouldn't be changed, where x1 can be un an unknown state. + +I found the issue running FreeBSD with the cortex-strings implementation of memcpy. This uses a similar instruction when copying between 64 and 96 bytes. + +I've observed this on: +QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.14), Copyright (c) 2003-2008 Fabrice Bellard + +And checked I still get the same behaviour on: +QEMU emulator version 2.9.94 (v2.10.0-rc4-dirty) +Git revision: 248b23735645f7cbb503d9be6f5bf825f2a603ab \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1722 b/results/classifier/semantic-bugs/1722 index 4dcbfc5fe..5f09ce5d2 100644 --- a/results/classifier/semantic-bugs/1722 +++ b/results/classifier/semantic-bugs/1722 @@ -1,15 +1,4 @@ -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: diff --git a/results/classifier/semantic-bugs/1737 b/results/classifier/semantic-bugs/1737 index 3b07da097..4b5bce8cd 100644 --- a/results/classifier/semantic-bugs/1737 +++ b/results/classifier/semantic-bugs/1737 @@ -1,15 +1,4 @@ -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: diff --git a/results/classifier/semantic-bugs/1738434 b/results/classifier/semantic-bugs/1738434 index e6167f2d3..3d486553b 100644 --- a/results/classifier/semantic-bugs/1738434 +++ b/results/classifier/semantic-bugs/1738434 @@ -1,15 +1,4 @@ -instruction: 0.851 -socket: 0.767 -graphic: 0.763 -device: 0.757 -mistranslation: 0.729 -network: 0.680 -vnc: 0.670 -assembly: 0.666 -other: 0.625 -semantic: 0.586 -KVM: 0.558 -boot: 0.530 + CALL FWORD PTR [ESP] handled incorrectly @@ -38,13 +27,4 @@ _ret: Environment: QEMU: 2.10.93, command line: qemu-system-x86_64.exe -m 2G -snapshot -cdrom full_path_to_iso fullP_path_to_img Guest OS: Windows 7 x64 SP1 build 7601 or Windows 10 version 1709 build 16299.19 -Host OS: Windows 10 x64 version 1703 build 15063.786 - - - -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 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.] - +Host OS: Windows 10 x64 version 1703 build 15063.786 \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1748296 b/results/classifier/semantic-bugs/1748296 index cab7dadc5..2b97e66f5 100644 --- a/results/classifier/semantic-bugs/1748296 +++ b/results/classifier/semantic-bugs/1748296 @@ -1,15 +1,4 @@ -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 @@ -35,61 +24,4 @@ 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 - +I believe the bug affects other BMI, BMI2, and ABM instructions, but I have only completely verified incorrect execution of SHLX. \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1751422 b/results/classifier/semantic-bugs/1751422 index df415ac99..a679fc828 100644 --- a/results/classifier/semantic-bugs/1751422 +++ b/results/classifier/semantic-bugs/1751422 @@ -1,71 +1,6 @@ -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. - - +The error translation instructions include les, lds. I has got a patch, but I have no idea how to apply it. \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1756927 b/results/classifier/semantic-bugs/1756927 index 3ec2692ab..69c48b031 100644 --- a/results/classifier/semantic-bugs/1756927 +++ b/results/classifier/semantic-bugs/1756927 @@ -1,15 +1,4 @@ -instruction: 0.816 -device: 0.753 -boot: 0.666 -mistranslation: 0.622 -semantic: 0.554 -graphic: 0.551 -network: 0.531 -vnc: 0.523 -socket: 0.491 -assembly: 0.407 -KVM: 0.400 -other: 0.370 + ARMv7 LPAE: IFSR doesn't have the LPAE bit in case of BKPT @@ -28,20 +17,4 @@ The last entry should read 'long-descriptor'. Qemu revision: 48ae1f60d8c9a770e6da64407984d84e25253c69 Ubuntu verison: 16.04 LTS -Cross Compiler: gcc linaro 6.3.1-2017.02-x86_64_arm-eabi - - - -I've just sent this patchset: -http://<email address hidden>/ -which should fix this bug and a couple of others that I noticed with our debug exception handling while I was doing that. - - -thanks Peter ! Any news on the review ? - -The patches are in master now. - - -Hi Peter, -we tested the fix and it work correctly now, thank you very much ! - +Cross Compiler: gcc linaro 6.3.1-2017.02-x86_64_arm-eabi \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1771 b/results/classifier/semantic-bugs/1771 index 3195f46f5..c0539d6c1 100644 --- a/results/classifier/semantic-bugs/1771 +++ b/results/classifier/semantic-bugs/1771 @@ -1,15 +1,4 @@ -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: diff --git a/results/classifier/semantic-bugs/1780 b/results/classifier/semantic-bugs/1780 index 354a178d0..88eabbb7d 100644 --- a/results/classifier/semantic-bugs/1780 +++ b/results/classifier/semantic-bugs/1780 @@ -1,15 +1,4 @@ -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: diff --git a/results/classifier/semantic-bugs/1790 b/results/classifier/semantic-bugs/1790 index 2a0a409bf..226dfa202 100644 --- a/results/classifier/semantic-bugs/1790 +++ b/results/classifier/semantic-bugs/1790 @@ -1,15 +1,4 @@ -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: diff --git a/results/classifier/semantic-bugs/1793608 b/results/classifier/semantic-bugs/1793608 index b6a6faa1b..046522a15 100644 --- a/results/classifier/semantic-bugs/1793608 +++ b/results/classifier/semantic-bugs/1793608 @@ -1,15 +1,4 @@ -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 @@ -26,24 +15,4 @@ https://github.com/VectorChief/UniSIMD-assembler/blob/master/core/config/rtarch_ 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. - +The instruction shows up in objdump correctly. \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1818075 b/results/classifier/semantic-bugs/1818075 index 26b345c17..e7d85554c 100644 --- a/results/classifier/semantic-bugs/1818075 +++ b/results/classifier/semantic-bugs/1818075 @@ -1,15 +1,4 @@ -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 @@ -63,71 +52,4 @@ Attaching a gdb produces this stacktrace: #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 - - + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/main.c:819 \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1820686 b/results/classifier/semantic-bugs/1820686 index f7fd19f6d..4f823b4f1 100644 --- a/results/classifier/semantic-bugs/1820686 +++ b/results/classifier/semantic-bugs/1820686 @@ -1,25 +1,7 @@ -instruction: 0.949 -device: 0.824 -network: 0.809 -other: 0.742 -socket: 0.724 -semantic: 0.691 -vnc: 0.683 -mistranslation: 0.678 -graphic: 0.598 -boot: 0.498 -KVM: 0.321 -assembly: 0.305 + risc-v: 'c.unimp' instruction decoded as 'c.addi4spn fp, 0' QEMU 3.1 incorrectly decodes the "c.unimp" instruction (opcode 0x0000) as an "addi4spn fp, 0" when either of the two following bytes are non-zero. This is because the ctx->opcode value used when decoding the instruction is actually filled with a 32-bit load (to handle normal uncompressed instructions) but when a compressed instruction is found only the low 16 bits are valid. Other reserved/illegal bit patterns with the addi4spn opcode are also incorrectly decoded. -I believe that the switch to decodetree on master happened to fix this issue, but hopefully it is helpful to have this recorded somewhere. I've included a simple one line patch if anyone wants to backport this. - - - -Thanks. If you spin a full patch (ie, "git commit -s" and then "git show") I can drop it on riscv-qemu-3.1, our backports branch. Otherwise hopefully we got the bug via the decodetree conversion. - -Since this bug isn't present in the decodetree version of the riscv decoder, we might as well just close this as fix-released; we won't be doing more point-releases of QEMU versions as old as 3.1. - +I believe that the switch to decodetree on master happened to fix this issue, but hopefully it is helpful to have this recorded somewhere. I've included a simple one line patch if anyone wants to backport this. \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1824344 b/results/classifier/semantic-bugs/1824344 index 9886d36a4..42e55d224 100644 --- a/results/classifier/semantic-bugs/1824344 +++ b/results/classifier/semantic-bugs/1824344 @@ -1,15 +1,4 @@ -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 @@ -55,17 +44,4 @@ 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 - - + Signed-off-by: Peter Maydell <email address hidden> \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1828867 b/results/classifier/semantic-bugs/1828867 index 05260e5d1..f643d8c75 100644 --- a/results/classifier/semantic-bugs/1828867 +++ b/results/classifier/semantic-bugs/1828867 @@ -1,15 +1,4 @@ -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 @@ -18,31 +7,4 @@ These two instructions only ever use the AH register. Contrary to other instruct 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 - - +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" \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1832422 b/results/classifier/semantic-bugs/1832422 index 39c39a63d..ee67cf104 100644 --- a/results/classifier/semantic-bugs/1832422 +++ b/results/classifier/semantic-bugs/1832422 @@ -1,15 +1,4 @@ -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 @@ -19,15 +8,4 @@ Test op that I found this on is here `66 0f c2 c0 d1 cmppd xmm0,xmm0,0 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 - - +I have a small patch that fixes the issue for the SSE variant. \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1833 b/results/classifier/semantic-bugs/1833 new file mode 100644 index 000000000..b0e57de53 --- /dev/null +++ b/results/classifier/semantic-bugs/1833 @@ -0,0 +1,86 @@ + + +ARM64 SME ST1Q incorrectly stores 9 bytes (rather than 16) per 128-bit element +Description of problem: +QEMU incorrectly stores 9 bytes instead of 16 per 128-bit element in the ST1Q SME instruction (https://developer.arm.com/documentation/ddi0602/2022-06/SME-Instructions/ST1Q--Contiguous-store-of-quadwords-from-128-bit-element-ZA-tile-slice-). It copies the first byte of the upper 64-bits, then lower the 64-bits. + +This seems to be a simple issue; I tracked it down to: +https://gitlab.com/qemu-project/qemu/-/blob/master/target/arm/tcg/sme_helper.c?ref_type=heads#L382 + +Updating that `+ 1` to a `+ 8` fixes the problem. +Steps to reproduce: +```c +#include <stdio.h> +#include <stdint.h> +#include <string.h> + +void st1q_sme_copy_test(uint8_t* src, uint8_t* dest) { + asm volatile( + "smstart sm\n" + "smstart za\n" + "ptrue p0.b\n" + "mov x12, xzr\n" + "ld1q {za0h.q[w12, 0]}, p0/z, %0\n" + "st1q {za0h.q[w12, 0]}, p0, %1\n" + "smstop za\n" + "smstop sm\n" : : "m"(*src), "m"(*dest) : "w12", "p0"); +} + +void print_first_128(uint8_t* data) { + putchar('['); + for (int i = 0; i < 16; i++) { + printf("%02d", data[i]); + if (i != 15) + printf(", "); + } + printf("]\n"); +} + +int main() { + _Alignas(16) uint8_t dest[512] = { }; + _Alignas(16) uint8_t src[512] = { }; + for (int i = 0; i < sizeof(src); i++) + src[i] = i; + puts("Before"); + printf(" src: "); + print_first_128(src); + printf("dest: "); + print_first_128(dest); + st1q_sme_copy_test(src, dest); + puts("\nAfter "); + printf(" src: "); + print_first_128(src); + printf("dest: "); + print_first_128(dest); +} +``` + +Compile with (requires at least clang ~14, tested with clang 16):<br/> +`clang ./qemu_repro.c -march=armv9-a+sme+sve -o ./qemu_repro` + +Run with:<br/> +`qemu-aarch64 -cpu max,sme=on ./qemu_repro` + +It's expected just to copy from `src` to `dest` and output: +``` +Before + src: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] +dest: [00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] + +After + src: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] +dest: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] +``` + +But currently outputs: +``` +Before + src: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] +dest: [00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00] + +After + src: [00, 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15] +dest: [00, 08, 09, 10, 11, 12, 13, 14, 15, 00, 00, 00, 00, 00, 00, 00] +``` +Additional information: +N/A diff --git a/results/classifier/semantic-bugs/1841990 b/results/classifier/semantic-bugs/1841990 new file mode 100644 index 000000000..e5a3eaef8 --- /dev/null +++ b/results/classifier/semantic-bugs/1841990 @@ -0,0 +1,40 @@ + + +instruction 'denbcdq' misbehaving + +Instruction 'denbcdq' appears to have no effect. Test case attached. + +On ppc64le native: +-- +gcc -g -O -mcpu=power9 bcdcfsq.c test-denbcdq.c -o test-denbcdq +$ ./test-denbcdq +0x00000000000000000000000000000000 +0x0000000000000000000000000000000c +0x22080000000000000000000000000000 +$ ./test-denbcdq 1 +0x00000000000000000000000000000001 +0x0000000000000000000000000000001c +0x22080000000000000000000000000001 +$ ./test-denbcdq $(seq 0 99) +0x00000000000000000000000000000064 +0x0000000000000000000000000000100c +0x22080000000000000000000000000080 +-- + +With "qemu-ppc64le -cpu power9" +-- +$ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq +0x00000000000000000000000000000000 +0x0000000000000000000000000000000c +0x0000000000000000000000000000000c +$ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq 1 +0x00000000000000000000000000000001 +0x0000000000000000000000000000001c +0x0000000000000000000000000000001c +$ qemu-ppc64le -cpu power9 -L [...] ./test-denbcdq $(seq 100) +0x00000000000000000000000000000064 +0x0000000000000000000000000000100c +0x0000000000000000000000000000100c +-- + +I started looking at the code, but I got confused rather quickly. Could be related to endianness? I think denbcdq arrived on the scene before little-endian was a big deal. Maybe something to do with utilizing implicit floating-point register pairs... I don't think the right data is getting to helper_denbcdq, which would point back to the gen_fprp_ptr uses in dfp-impl.inc.c (GEN_DFP_T_FPR_I32_Rc). (Maybe?) \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1861404 b/results/classifier/semantic-bugs/1861404 index f905e83ae..dc3d3f36b 100644 --- a/results/classifier/semantic-bugs/1861404 +++ b/results/classifier/semantic-bugs/1861404 @@ -1,15 +1,4 @@ -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 @@ -60,164 +49,4 @@ static inline void gen_ldo_env_A0(DisasContext *s, int offset) 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 - - +``` \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1862167 b/results/classifier/semantic-bugs/1862167 new file mode 100644 index 000000000..e5e8c5db2 --- /dev/null +++ b/results/classifier/semantic-bugs/1862167 @@ -0,0 +1,5 @@ + + +Variation of SVE register size (qemu-user-aarch64) + +Specification of ARMv8-A SVE extention allows various values for the size of the SVE register. On the other hand, it seems that the current qemu-aarch64 supports only the maximum length of 2048 bits as the SVE register size. I am writing an assembler program for a CPU that is compliant with ARMv8-A + SVE and has a 512-bit SVE register, but when this is run with qemu-user-aarch64, a 2048-bit load / store instruction is executed This causes a segmentation fault. Shouldn't qeum-user-aarch64 have an option to specify the SVE register size? \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1863247 b/results/classifier/semantic-bugs/1863247 index 072da78e3..752dcb305 100644 --- a/results/classifier/semantic-bugs/1863247 +++ b/results/classifier/semantic-bugs/1863247 @@ -1,15 +1,4 @@ -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 @@ -18,16 +7,4 @@ On AArch64 CPU with SVE register, there seems to be a bug in the operation when 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. - +After executing above instruction, (N-1) to 128 bits of z0 register must be 0, where N is SVE register width. \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1873898 b/results/classifier/semantic-bugs/1873898 new file mode 100644 index 000000000..ddc8d8d99 --- /dev/null +++ b/results/classifier/semantic-bugs/1873898 @@ -0,0 +1,40 @@ + + +arm linux-user: bkpt insn doesn't cause SIGTRAP + +QEMU's 32-bit arm linux-user mode doesn't correctly turn guest BKPT insns into SIGTRAP signals. Test case: + +===begin bkpt.c=== +/* test bkpt insn */ + +#include <stdlib.h> +#include <stdio.h> + +int main(void) +{ + printf("breakpoint\n"); +#ifdef __aarch64__ + __asm__ volatile("brk 0x42\n"); +#else + __asm__ volatile("bkpt 0x42\n"); +#endif + printf("done\n"); + return 0; +} +===endit=== + +Compile with +$ arm-linux-gnueabihf-gcc -g -Wall -o bkpt-aa32 bkpt.c +$ aarch64-linux-gnu-gcc -g -Wall -o bkpt-aa64 bkpt.c + +Contrast aarch64 which delivers the SIGTRAP and arm which doesn't: + +$ qemu-aarch64 bkpt-aa64 +breakpoint +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +Trace/breakpoint trap (core dumped) +$ qemu-arm bkpt-aa32 +breakpoint +done + +This is because in linux-user/arm/cpu-loop.c we incorrectly treat EXCP_BKPT similarly to EXCP_SWI, which means that we actually perform a syscall (which one depends on what happens to be in r7...). This code has been like this (more or less) since commit 06c949e62a098f in 2006 which added BKPT in the first place. This is probably because at the time the same code path was used to handle both Linux syscalls and semihosting calls, and (on M profile) BKPT does imply a semihosting call. But these days we've moved handling of semihosting out to an entirely different codepath, so we can fix this bug by simply removing this handling of EXCP_BKPT and instead making it deliver a SIGTRAP like EXCP_DEBUG (as we do already on aarch64). \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1889288 b/results/classifier/semantic-bugs/1889288 new file mode 100644 index 000000000..84311c557 --- /dev/null +++ b/results/classifier/semantic-bugs/1889288 @@ -0,0 +1,9 @@ + + +aarch64 BICS instruciton doesn't set flags + +When reading the source for translate-a64.c here: + +https://github.com/qemu/qemu/blob/a466dd084f51cdc9da2e99361f674f98d7218559/target/arm/translate-a64.c#L4783 + +I noticed that it does not appear to call gen_logic_CC for the BICS instruction so is not setting the flags as required. I haven't tried to produce a test case for it but it seems like it might be a bug. \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1901 b/results/classifier/semantic-bugs/1901 index 33ec55668..36dabd561 100644 --- a/results/classifier/semantic-bugs/1901 +++ b/results/classifier/semantic-bugs/1901 @@ -1,15 +1,4 @@ -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: diff --git a/results/classifier/semantic-bugs/1905356 b/results/classifier/semantic-bugs/1905356 new file mode 100644 index 000000000..7771b6131 --- /dev/null +++ b/results/classifier/semantic-bugs/1905356 @@ -0,0 +1,14 @@ + + +No check for unaligned data access in ARM32 instructions + +hi + +According to the ARM documentation, there are alignment requirements of load/store instructions. Alignment fault should be raised if the alignment check is failed. However, it seems that QEMU doesn't implement this, which is against the documentation of ARM. For example, the instruction LDRD/STRD/LDREX/STREX must check the address is word alignment no matter what value the SCTLR.A is. + +I attached a testcase, which contains a instruction at VA 0x10240: ldrd r0,[pc.#1] in the main function. QEMU can successfully load the data in the unaligned address. The test is done in QEMU 5.1.0. I can provide more testcases for the other instructions if you need. Many thanks. + +To patch this, we need a check while we translate the instruction to tcg. If the address is unaligned, a signal number (i.e., SIGBUS) should be raised. + +Regards +Muhui \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1912934 b/results/classifier/semantic-bugs/1912934 index f487e30df..1454948c4 100644 --- a/results/classifier/semantic-bugs/1912934 +++ b/results/classifier/semantic-bugs/1912934 @@ -1,15 +1,4 @@ -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 @@ -27,52 +16,4 @@ 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 - - +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 ). \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1916269 b/results/classifier/semantic-bugs/1916269 index 45a2ef615..a2f96bcbf 100644 --- a/results/classifier/semantic-bugs/1916269 +++ b/results/classifier/semantic-bugs/1916269 @@ -1,15 +1,4 @@ -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 @@ -29,42 +18,4 @@ 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 - +This should work even with the FPU disabled. \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1918026 b/results/classifier/semantic-bugs/1918026 new file mode 100644 index 000000000..702959299 --- /dev/null +++ b/results/classifier/semantic-bugs/1918026 @@ -0,0 +1,31 @@ + + +RISCV64 32-bit AMOs incorrectly simulated + +Version: qemu-riscv64 version 4.2.1 (Debian 1:4.2-3ubuntu6.14) + +test: + amomaxu.w a0, a1, (a0) + ret + +int32_t* value = -7; +EXPECT_EQ(-7, test(&value, -11)); +EXPECT_EQ(-7, value); // FAIL, saw -11 +EXPECT_EQ(-7, test(&value, -7)); +EXPECT_EQ(-7, value); // FAIL, raw -11 +EXPECT_EQ(-7, test(&value, -4)); +EXPECT_EQ(-4, value); + +test: + amomax.w a0, a1, (a0) + ret + +int32_t* value = -7; +EXPECT_EQ(-7, test(&value, -11)); +EXPECT_EQ(-7, value); +EXPECT_EQ(-7, test(&value, -7)); +EXPECT_EQ(-7, value); +EXPECT_EQ(-7, test(&value, -4)); +EXPECT_EQ(-4, value); // FAIL, saw -7 + +I suspect that trans_amo<op>_w should be using tcg_gen_atomic_fetch_<op>_i32 instead of tcg_gen_atomic_fetch_<op>_tl. \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1922887 b/results/classifier/semantic-bugs/1922887 new file mode 100644 index 000000000..c78b4e67c --- /dev/null +++ b/results/classifier/semantic-bugs/1922887 @@ -0,0 +1,32 @@ + + +STR in Thumb 32 decode problem + +Hi + +It seems that QEMU does not have a proper check on the STR instruction in Thumb32 mode. + +Specifically, the machine code is 0xf84f0ddd, which is 0b1111 1000 0100 1111 0000 1101 1101 1101. +This is an STR (immediate, Thumb) instruction with a T4 encoding scheme. + +The symbols is + +Rn = 1111 +Rt = 0000 +P = 1 +U = 0 +W = 1 + +The decode ASL is below: + +if P == ‘1’ && U == ‘1’ && W == ‘0’ then SEE STRT; +if Rn == ‘1101’ && P == ‘1’ && U == ‘0’ && W == ‘1’ && imm8 == ‘00000100’ then SEE PUSH; +if Rn == ‘1111’ || (P == ‘0’ && W == ‘0’) then UNDEFINED; +t = UInt(Rt); n = UInt(Rn); imm32 = ZeroExtend(imm8, 32); +index = (P == ‘1’); add = (U == ‘1’); wback = (W == ‘1’); +if t == 15 || (wback && n == t) then UNPREDICTABLE; + +When Rn == 1111, it should be an undefined instruction, which should raise SEGILL signal. However, it seems that QEMU does not check this constraint, which should be a bug. Many thanks + +Regards +Muhui \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1925512 b/results/classifier/semantic-bugs/1925512 new file mode 100644 index 000000000..9c03d06e5 --- /dev/null +++ b/results/classifier/semantic-bugs/1925512 @@ -0,0 +1,20 @@ + + +UNDEFINED case for instruction BLX + +Hi + +I refer to the instruction BLX imm (T2 encoding) in ARMv7 (Thumb mode). + +11110 S imm10H 11 J1 0 J2 imm10L H + + +if H == '1' then UNDEFINED; +I1 = NOT(J1 EOR S); I2 = NOT(J2 EOR S); imm32 = SignExtend(S:I1:I2:imm10H:imm10L:'00', 32); +targetInstrSet = InstrSet_A32; +if InITBlock() && !LastInITBlock() then UNPREDICTABLE; + +According to the manual, if H equals to 1, this instruction should be an UNDEFINED instruction. However, it seems QEMU does not check this constraint in function trans_BLX_i. Thanks + +Regards +Muhui \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1926759 b/results/classifier/semantic-bugs/1926759 index 753b9e4d4..0e7ca213f 100644 --- a/results/classifier/semantic-bugs/1926759 +++ b/results/classifier/semantic-bugs/1926759 @@ -1,15 +1,4 @@ -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 @@ -28,46 +17,4 @@ 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 - +Muhui \ No newline at end of file diff --git a/results/classifier/semantic-bugs/1941 b/results/classifier/semantic-bugs/1941 new file mode 100644 index 000000000..4ff15b7d6 --- /dev/null +++ b/results/classifier/semantic-bugs/1941 @@ -0,0 +1,104 @@ + + +ppc64: VSX vector float to integer conversion instructions do not always return expected results on QEMU 8.0.4 if source vector has NaN values +Description of problem: +The problem is that the VSX xvcvspsxws/xvcvdpsxws/xvcvspsxds/xvcvdpsxds/xvcvspuxws/xvcvdpuxds/xvcvspuxds/xvcvdpuxws instructions incorrectly convert the preceding non-NaN source values to the NaN to integer result instead of the expected non-NaN to integer conversion result with qemu-ppc64le 8.0.4. + +Here are the results of the VSX operations whose results differ from the expected results with QEMU 8.0.4 (generated by running the vsx_f2i_nan_test_program_101423 test program with qemu-ppc64le 8.0.4): +``` +xvcvspsxds ({1, 2, 3, nan}) = {-9223372036854775808, -9223372036854775808} +xvcvspsxds ({nan, 2, 3, nan}) = {-9223372036854775808, -9223372036854775808} +xvcvspsxds ({1, 2, nan, nan}) = {-9223372036854775808, -9223372036854775808} +xvcvspsxds ({nan, 2, nan, nan}) = {-9223372036854775808, -9223372036854775808} + +xvcvspsxws ({1, nan, 3, 4}) = {-2147483648, -2147483648, 3, 4} +xvcvspsxws ({1, 2, nan, 4}) = {-2147483648, -2147483648, -2147483648, 4} +xvcvspsxws ({nan, 2, nan, 4}) = {-2147483648, -2147483648, -2147483648, 4} +xvcvspsxws ({1, nan, nan, 4}) = {-2147483648, -2147483648, -2147483648, 4} +xvcvspsxws ({1, 2, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({nan, 2, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({1, nan, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({nan, nan, 3, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({1, 2, nan, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({nan, 2, nan, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} +xvcvspsxws ({1, nan, nan, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} + +xvcvspuxds ({1, 2, 3, nan}) = {0, 0} +xvcvspuxds ({nan, 2, 3, nan}) = {0, 0} +xvcvspuxds ({1, 2, nan, nan}) = {0, 0} +xvcvspuxds ({nan, 2, nan, nan}) = {0, 0} + +xvcvspuxws ({1, nan, 3, 4}) = {0, 0, 3, 4} +xvcvspuxws ({1, 2, nan, 4}) = {0, 0, 0, 4} +xvcvspuxws ({nan, 2, nan, 4}) = {0, 0, 0, 4} +xvcvspuxws ({1, nan, nan, 4}) = {0, 0, 0, 4} +xvcvspuxws ({1, 2, 3, nan}) = {0, 0, 0, 0} +xvcvspuxws ({nan, 2, 3, nan}) = {0, 0, 0, 0} +xvcvspuxws ({1, nan, 3, nan}) = {0, 0, 0, 0} +xvcvspuxws ({nan, nan, 3, nan}) = {0, 0, 0, 0} +xvcvspuxws ({1, 2, nan, nan}) = {0, 0, 0, 0} +xvcvspuxws ({nan, 2, nan, nan}) = {0, 0, 0, 0} +xvcvspuxws ({1, nan, nan, nan}) = {0, 0, 0, 0} + +xvcvdpsxws ({1, nan}) = {-2147483648, -2147483648, -2147483648, -2147483648} + +xvcvdpuxws ({1, nan}) = {0, 0, 0, 0} + +xvcvdpsxds ({1, nan}) = {-9223372036854775808, -9223372036854775808} + +xvcvdpuxds ({1, nan}) = {0, 0} +``` + +Here are the results of the same VSX conversion operations with QEMU 6.2.0 (generated by running the vsx_f2i_nan_test_program_101423 test program with qemu-ppc64le 6.2.0): +``` +xvcvspsxds ({1, 2, 3, nan}) = {2, -9223372036854775808} +xvcvspsxds ({nan, 2, 3, nan}) = {2, -9223372036854775808} +xvcvspsxds ({1, 2, nan, nan}) = {2, -9223372036854775808} +xvcvspsxds ({nan, 2, nan, nan}) = {2, -9223372036854775808} + +xvcvspsxws ({1, nan, 3, 4}) = {1, -2147483648, 3, 4} +xvcvspsxws ({1, 2, nan, 4}) = {1, 2, -2147483648, 4} +xvcvspsxws ({nan, 2, nan, 4}) = {-2147483648, 2, -2147483648, 4} +xvcvspsxws ({1, nan, nan, 4}) = {1, -2147483648, -2147483648, 4} +xvcvspsxws ({1, 2, 3, nan}) = {1, 2, 3, -2147483648} +xvcvspsxws ({nan, 2, 3, nan}) = {-2147483648, 2, 3, -2147483648} +xvcvspsxws ({1, nan, 3, nan}) = {1, -2147483648, 3, -2147483648} +xvcvspsxws ({nan, nan, 3, nan}) = {-2147483648, -2147483648, 3, -2147483648} +xvcvspsxws ({1, 2, nan, nan}) = {1, 2, -2147483648, -2147483648} +xvcvspsxws ({nan, 2, nan, nan}) = {-2147483648, 2, -2147483648, -2147483648} +xvcvspsxws ({1, nan, nan, nan}) = {1, -2147483648, -2147483648, -2147483648} + +xvcvspuxds ({1, 2, 3, nan}) = {2, 0} +xvcvspuxds ({nan, 2, 3, nan}) = {2, 0} +xvcvspuxds ({1, 2, nan, nan}) = {2, 0} +xvcvspuxds ({nan, 2, nan, nan}) = {2, 0} + +xvcvspuxws ({1, nan, 3, 4}) = {1, 0, 3, 4} +xvcvspuxws ({1, 2, nan, 4}) = {1, 2, 0, 4} +xvcvspuxws ({nan, 2, nan, 4}) = {0, 2, 0, 4} +xvcvspuxws ({1, nan, nan, 4}) = {1, 0, 0, 4} +xvcvspuxws ({1, 2, 3, nan}) = {1, 2, 3, 0} +xvcvspuxws ({nan, 2, 3, nan}) = {0, 2, 3, 0} +xvcvspuxws ({1, nan, 3, nan}) = {1, 0, 3, 0} +xvcvspuxws ({nan, nan, 3, nan}) = {0, 0, 3, 0} +xvcvspuxws ({1, 2, nan, nan}) = {1, 2, 0, 0} +xvcvspuxws ({nan, 2, nan, nan}) = {0, 2, 0, 0} +xvcvspuxws ({1, nan, nan, nan}) = {1, 0, 0, 0} + +xvcvdpsxws ({1, nan}) = {0, 1, 0, -2147483648} + +xvcvdpuxws ({1, nan}) = {0, 1, 0, 0} + +xvcvdpsxds ({1, nan}) = {1, -9223372036854775808} + +xvcvdpuxds ({1, nan}) = {1, 0} +``` +Steps to reproduce: +1. Compile the attached vsx_f2i_nan_test_program_101423.cpp with either `powerpc64le-linux-gnu-g++` or `clang --target=powerpc64le-linux-gnu` +2. Run the compiled vsx_f2i_nan_test_program_101423.cpp program using qemu-ppc64le +3. The vsx_f2i_nan_test_program_101423 program will return the results of the xvcvspsxws, xvcvdpsxws, xvcvspsxds, xvcvdpsxds, xvcvspuxws, xvcvdpuxds, xvcvspuxds, or xvcvdpuxws instruction. +Additional information: +Attachments: +- [vsx_f2i_nan_test_program_101423.cpp](/uploads/749395aee2da1dcc86790804106d30ea/vsx_f2i_nan_test_program_101423.cpp) +- [vsx_f2i_nan_test_program_101423_qemu_6.2.0_output.txt](/uploads/c883c4d04730a9c5a7e301e5d487ae2b/vsx_f2i_nan_test_program_101423_qemu_6.2.0_output.txt) - output of running vsx_f2i_nan_test_program_101423 with QEMU 6.2.0 +- [vsx_f2i_nan_test_program_101423_qemu_8.0.4_output.txt](/uploads/9451e3419f8a4f3ef2274b2ccc7ef22d/vsx_f2i_nan_test_program_101423_qemu_8.0.4_output.txt) - output of running vsx_f2i_nan_test_program_101423 with QEMU 8.0.4 diff --git a/results/classifier/semantic-bugs/1967248 b/results/classifier/semantic-bugs/1967248 new file mode 100644 index 000000000..d3960bb7d --- /dev/null +++ b/results/classifier/semantic-bugs/1967248 @@ -0,0 +1,40 @@ + + +qemu: uncaught target signal 5 (Trace/breakpoint trap) + +I'm getting core dumped when running the attached a.out_err binary in qemu, but when using Gdb to remote-debug the program, it exited normally. will appreciate if you can help look into this qemu issue. + +And I found that QEMU's 32-bit arm linux-user mode doesn't correctly turn guest BKPT insns into SIGTRAP signal. + +0xa602 <_start> movs r0, #22 0xa604 <_start+2> addw r1, pc, #186 ; 0xba +0xa608 <_start+6> bkpt 0x00ab + +$readelf -h hello +ELF Header: + Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 + Class: ELF32 + Data: 2's complement, little endian + Version: 1 (current) + OS/ABI: UNIX - System V + ABI Version: 0 + Type: EXEC (Executable file) + Machine: ARM + Version: 0x1 + Entry point address: 0xa603 + Start of program headers: 52 (bytes into file) + Start of section headers: 144128 (bytes into file) + Flags: 0x5000200, Version5 EABI, soft-float ABI + Size of this header: 52 (bytes) + Size of program headers: 32 (bytes) + Number of program headers: 5 + Size of section headers: 40 (bytes) + Number of section headers: 16 + Section header string table index: 14 + +$qemu-arm --version +qemu-arm version 6.2.0 +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers + + +And I have check that the bug(https://bugs.launchpad.net/qemu/+bug/1873898) is fixed. +But it's coredump. \ No newline at end of file diff --git a/results/classifier/semantic-bugs/2083 b/results/classifier/semantic-bugs/2083 new file mode 100644 index 000000000..9fe21e20f --- /dev/null +++ b/results/classifier/semantic-bugs/2083 @@ -0,0 +1,113 @@ + + +AArch64 SME SMOPA (4-way) outer product instruction gives incorrect result +Description of problem: +The SME SMOPA (4-way) instruction ([spec](https://developer.arm.com/documentation/ddi0602/2023-09/SME-Instructions/SMOPA--4-way---Signed-integer-sum-of-outer-products-and-accumulate-?lang=en)) is giving incorrect result. Example below for 8-bit variant, which is equivalent to following Python example (128-bit VL) to make it clearer: + +``` +import numpy as np +vl = 128 +esize = 32 +dim = vl // esize + +A = range(16) +B = range(16, 32) +C = np.zeros((4, 4,), dtype=np.int32) + +for row in range(dim): + for col in range(dim): + for k in range(4): + C[row, col] += A[4*row + k] * B[4*col + k] + +print(C) + +[[ 110 134 158 182] + [ 390 478 566 654] + [ 670 822 974 1126] + [ 950 1166 1382 1598]] +``` + +main.c +``` +#include <stdio.h> +#include <stdint.h> + +void foo(int *dst); + +int main() { + int32_t dst[16]; + foo(dst); + + // This should print: + // >>> 110 134 158 182 + // >>> 390 478 566 654 + // >>> 670 822 974 1126 + // >>> 950 1166 1382 1598 + for (int i=0; i<4; ++i) { + printf(">>> "); + for (int j=0; j<4; ++j) { + printf("%d ", 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.b + index z0.b, #0, #1 + mov z1.d, z0.d + add z1.b, z1.b, #16 + + zero {za} + smopa za0.s, p0/m, p0/m, z0.b, z1.b + + // Read the first 4x4 sub-matrix of elements from tile 0: + mov w12, #0 + mova z0.s, p0/m, za0h.s[w12, #0] + mova z1.s, p0/m, za0h.s[w12, #1] + mova z2.s, p0/m, za0h.s[w12, #2] + mova z3.s, p0/m, za0h.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 main.c foo.S +$ ~/qemu/build/qemu-aarch64 -cpu max,sme128=on a.out +>>> 110 478 158 654 +>>> 0 0 0 0 +>>> 670 1166 974 1598 +>>> 0 0 0 0 +``` +Additional information: + diff --git a/results/classifier/semantic-bugs/2089 b/results/classifier/semantic-bugs/2089 index 4241b84e5..fac9e1d6f 100644 --- a/results/classifier/semantic-bugs/2089 +++ b/results/classifier/semantic-bugs/2089 @@ -1,15 +1,4 @@ -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: diff --git a/results/classifier/semantic-bugs/2136 b/results/classifier/semantic-bugs/2136 new file mode 100644 index 000000000..965448aed --- /dev/null +++ b/results/classifier/semantic-bugs/2136 @@ -0,0 +1,37 @@ + + +on loongarch host, LSX vec get wrong result +Description of problem: +on loongarch host, the lsx insns get wrong result. +Steps to reproduce: +1. build linux-user on loongarch host with '--configure --target-list ='loongarch64-linux-user'' +2. build test code 'gcc --static test.c -o test' +3. run './build/qemu-loongarch64 test' +Additional information: +run 'qemu-loongarch64 test' +the result is + +`0: 2f2f2f2f +1: 0 +2: 2f2f2f2f +3: 0 +4: ffffffff +5: 0 +6: ffffffff +7: ffffffff` + +and the 6 or 7 may be ffffff or 0. + +run 'test' on loongarch host or run qemu-loongarch64 on x86_64 host. +the result is + +`0: 2f2f2f2f +1: 0 +2: 2f2f2f2f +3: 0 +4: 0 +5: 0 +6: 0 +7: 0` + +for more infomation see log.txt diff --git a/results/classifier/semantic-bugs/2175 b/results/classifier/semantic-bugs/2175 index 874c3bcde..ddceb1e54 100644 --- a/results/classifier/semantic-bugs/2175 +++ b/results/classifier/semantic-bugs/2175 @@ -1,15 +1,4 @@ -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: diff --git a/results/classifier/semantic-bugs/2203 b/results/classifier/semantic-bugs/2203 new file mode 100644 index 000000000..d1c607644 --- /dev/null +++ b/results/classifier/semantic-bugs/2203 @@ -0,0 +1,3 @@ + + +RISC-V RVV fractional LMUL check is wrong diff --git a/results/classifier/semantic-bugs/2248 b/results/classifier/semantic-bugs/2248 index ae3a6196e..204c11506 100644 --- a/results/classifier/semantic-bugs/2248 +++ b/results/classifier/semantic-bugs/2248 @@ -1,15 +1,4 @@ -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: diff --git a/results/classifier/semantic-bugs/2302 b/results/classifier/semantic-bugs/2302 index dd607123b..566272d4a 100644 --- a/results/classifier/semantic-bugs/2302 +++ b/results/classifier/semantic-bugs/2302 @@ -1,15 +1,4 @@ -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: diff --git a/results/classifier/semantic-bugs/2317 b/results/classifier/semantic-bugs/2317 index 0acfd4575..0cc743d89 100644 --- a/results/classifier/semantic-bugs/2317 +++ b/results/classifier/semantic-bugs/2317 @@ -1,15 +1,4 @@ -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: diff --git a/results/classifier/semantic-bugs/2318 b/results/classifier/semantic-bugs/2318 index 3defce0d6..640b7f549 100644 --- a/results/classifier/semantic-bugs/2318 +++ b/results/classifier/semantic-bugs/2318 @@ -1,15 +1,4 @@ -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: diff --git a/results/classifier/semantic-bugs/2319 b/results/classifier/semantic-bugs/2319 new file mode 100644 index 000000000..274bce817 --- /dev/null +++ b/results/classifier/semantic-bugs/2319 @@ -0,0 +1,19 @@ + + +SPARC32-bit SDIV of negative divisor gives wrong result +Description of problem: +SDIV of negative divisor gives wrong result because of typo in helper_sdiv(). This is true for QEMU 9.0.0 and earlier. + +Place -1 in the Y register and -128 in another reg, then -120 in another register and do SDIV into a result register, instead of the proper value of 1 for the result, the incorrect value of 0 is produced. + +There is a typo in target/sparc/helper.c that causes the divisor to be consider unsigned, this patch fixes it: + +\*\*\* helper.c.ori Tue Apr 23 16:23:45 2024 --- helper.c Mon Apr 29 20:14:07 2024 + +--- + +\*\*\* 121,127 \*\*\*\* return (uint32_t)(b32 \< 0 ? INT32_MAX : INT32_MIN) | (-1ull \<\< 32); } + +! a64 /= b; r = a64; if (unlikely(r != a64)) { return (uint32_t)(a64 \< 0 ? INT32_MIN : INT32_MAX) | (-1ull \<\< 32); --- 121,127 ---- return (uint32_t)(b32 \< 0 ? INT32_MAX : INT32_MIN) | (-1ull \<\< 32); } + +! a64 /= b32; r = a64; if (unlikely(r != a64)) { return (uint32_t)(a64 \< 0 ? INT32_MIN : INT32_MAX) | (-1ull \<\< 32); diff --git a/results/classifier/semantic-bugs/2371 b/results/classifier/semantic-bugs/2371 index 2db65ca18..c14718b57 100644 --- a/results/classifier/semantic-bugs/2371 +++ b/results/classifier/semantic-bugs/2371 @@ -1,15 +1,4 @@ -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: diff --git a/results/classifier/semantic-bugs/2373 b/results/classifier/semantic-bugs/2373 new file mode 100644 index 000000000..b633b2ca0 --- /dev/null +++ b/results/classifier/semantic-bugs/2373 @@ -0,0 +1,97 @@ + + +A bug in AArch64 FMOPA/FMOPS (widening) instruction +Description of problem: +fmopa 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 the case of widening variant of this instruction. Before the matrix multiplication is performed, each element should be converted to a 64-bit floating point. FPCR flags are considered when converting floating point values. Especially, when the FZ (or FZ16) flag is set, denormalized values are converted into zero. When the floating point size is 16 bits, FZ16 should be considered; otherwise, FZ flag should be used. + +However, the current implementation only considers FZ flag, not FZ16 flag, so it computes the wrong value. +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdio.h> + +char i_P2[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, 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_Z16[32] = { // Set only the first element as non-zero + 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, 0x0, +}; +char i_ZA3H[128] = { 0x0, }; +uint64_t i_fpcr = 0x0001000000; // FZ = 1; +char o_ZA3H[128]; + +void __attribute__ ((noinline)) show_state() { + for (int i = 0; i < 8; i++) { + for (int j = 0; j < 16; j++) { + printf("%02x ", o_ZA3H[16*i+j]); + } + printf("\n"); + } +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + ".arch armv9.3-a+sme\n" + "smstart\n" + "adrp x29, i_P2\n" + "add x29, x29, :lo12:i_P2\n" + "ldr p2, [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_Z16\n" + "add x29, x29, :lo12:i_Z16\n" + "ldr z16, [x29]\n" + "adrp x29, i_ZA3H\n" + "add x29, x29, :lo12:i_ZA3H\n" + "mov x15, 0\n" + "ld1w {za3h.s[w15, 0]}, p2, [x29]\n" + "add x29, x29, 32\n" + "ld1w {za3h.s[w15, 1]}, p2, [x29]\n" + "add x29, x29, 32\n" + "mov x15, 2\n" + "ld1w {za3h.s[w15, 0]}, p2, [x29]\n" + "add x29, x29, 32\n" + "ld1w {za3h.s[w15, 1]}, p2, [x29]\n" + "adrp x29, i_fpcr\n" + "add x29, x29, :lo12:i_fpcr\n" + "ldr x29, [x29]\n" + "msr fpcr, x29\n" + ".inst 0x81a0aa03\n" // fmopa za3.s, p2/m, p5/m, z16.h, z0.h + "adrp x29, o_ZA3H\n" + "add x29, x29, :lo12:o_ZA3H\n" + "mov x15, 0\n" + "st1w {za3h.s[w15, 0]}, p2, [x29]\n" + "add x29, x29, 32\n" + "st1w {za3h.s[w15, 1]}, p2, [x29]\n" + "add x29, x29, 32\n" + "mov x15, 2\n" + "st1w {za3h.s[w15, 0]}, p2, [x29]\n" + "add x29, x29, 32\n" + "st1w {za3h.s[w15, 1]}, p2, [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 only zero bytes. It should print `00 01 7e 2f + 00 .. (rest of bytes) .. 00` after the bug is fixed. +Additional information: + diff --git a/results/classifier/semantic-bugs/2375 b/results/classifier/semantic-bugs/2375 new file mode 100644 index 000000000..c36ae65ae --- /dev/null +++ b/results/classifier/semantic-bugs/2375 @@ -0,0 +1,87 @@ + + +A bug in AArch64 FJCVTZS instruction +Description of problem: +fjcvtzs instruction converts a double-precision floating-point value in the source register into a 32-bit signed integer, and stores the result in the destination register. The contents of the FPCR register influence the exception result. Especially, when FPCR.FZ (Flushing denormalized numbers to Zero) is set and an input is a denormalized number, the PSTATE.Z flag should be cleared even if the conversion result is zero. + +However, because the helper function for this instruction does not properly check the denormalized case, the Z flag will have an incorrect value: +``` +// target/arm/vfp_helper.c +uint64_t HELPER(fjcvtzs)(float64 value, void *vstatus) +{ + float_status *status = vstatus; + uint32_t inexact, frac; + uint32_t e_old, e_new; + + e_old = get_float_exception_flags(status); + set_float_exception_flags(0, status); + frac = float64_to_int32_modulo(value, float_round_to_zero, status); + e_new = get_float_exception_flags(status); + set_float_exception_flags(e_old | e_new, status); + + if (value == float64_chs(float64_zero)) { + /* While not inexact for IEEE FP, -0.0 is inexact for JavaScript. */ + inexact = 1; + } else { + /* Normal inexact or overflow or NaN */ + inexact = e_new & (float_flag_inexact | float_flag_invalid); // float_flag_input_denormal should also be checked. + } + + /* Pack the result and the env->ZF representation of Z together. */ + return deposit64(frac, 32, 32, inexact); +} +``` +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdint.h> +#include <stdio.h> +#include <string.h> + +char i_D27[8] = { 0x0, 0xff, 0xfc, 0x0, 0x0, 0x0, 0x0, 0x0 }; +uint64_t i_fpcr = 0x01000000; // FZ = 1; +char o_X28[8]; +uint64_t o_nzcv; + +void __attribute__ ((noinline)) show_state() { + char Z = ((o_nzcv >> 30) & 1); + + printf("PSTATE.Z: %d\n", Z); + printf("X28: "); + for (int i = 0; i < 8; i++) { + printf("%02x ", o_X28[i]); + } + printf("\n"); +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + "adrp x29, i_D27\n" + "add x29, x29, :lo12:i_D27\n" + "ldr d27, [x29]\n" + "adrp x29, i_fpcr\n" + "add x29, x29, :lo12:i_fpcr\n" + "ldr x29, [x29]\n" + "msr fpcr, x29\n" + ".inst 0x1e7e037c\n" // fjcvtzs w28, d27 + "mrs x26, nzcv\n" + "adrp x29, o_nzcv\n" + "add x29, x29, :lo12:o_nzcv\n" + "str x26, [x29]\n" + "adrp x29, o_X28\n" + "add x29, x29, :lo12:o_X28\n" + "str x28, [x29]\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/ ./test.bin`. +4. The program, runs on top of the buggy QEMU, prints the value of Z as `01`. It should print `00` after the bug is fixed. +Additional information: + diff --git a/results/classifier/semantic-bugs/2376 b/results/classifier/semantic-bugs/2376 new file mode 100644 index 000000000..11d3a9f49 --- /dev/null +++ b/results/classifier/semantic-bugs/2376 @@ -0,0 +1,116 @@ + + +A bug in ARM VCMLA.f16/VCMLA.f32 instructions +Description of problem: +The vcmla instruction performs complex-number operations on the vector registers. There is a bug in which this instruction modifies the contents of an irrelevant vector register. + +The reason is simple out-of-bound; the helper functions should correctly check the number of modified elements: +``` +// target/arm/tcg/vec_helper.c +void HELPER(gvec_fcmlah_idx)(void *vd, void *vn, void *vm, void *va, + void *vfpst, uint32_t desc) +{ + uintptr_t opr_sz = simd_oprsz(desc); + float16 *d = vd, *n = vn, *m = vm, *a = va; + float_status *fpst = vfpst; + intptr_t flip = extract32(desc, SIMD_DATA_SHIFT, 1); + uint32_t neg_imag = extract32(desc, SIMD_DATA_SHIFT + 1, 1); + intptr_t index = extract32(desc, SIMD_DATA_SHIFT + 2, 2); + uint32_t neg_real = flip ^ neg_imag; + intptr_t elements = opr_sz / sizeof(float16); + intptr_t eltspersegment = 16 / sizeof(float16); // This should be fixed; + intptr_t i, j; + + ... +} + +... + +void HELPER(gvec_fcmlas_idx)(void *vd, void *vn, void *vm, void *va, + void *vfpst, uint32_t desc) +{ + uintptr_t opr_sz = simd_oprsz(desc); + float32 *d = vd, *n = vn, *m = vm, *a = va; + float_status *fpst = vfpst; + intptr_t flip = extract32(desc, SIMD_DATA_SHIFT, 1); + uint32_t neg_imag = extract32(desc, SIMD_DATA_SHIFT + 1, 1); + intptr_t index = extract32(desc, SIMD_DATA_SHIFT + 2, 2); + uint32_t neg_real = flip ^ neg_imag; + intptr_t elements = opr_sz / sizeof(float32); + intptr_t eltspersegment = 16 / sizeof(float32); // This should be fixed; + intptr_t i, j; + + ... +} +``` +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdint.h> +#include <stdio.h> +#include <string.h> + +// zero inputs should produce zero output +char i_D4[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; +char i_D8[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; +char i_D30[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; +char i_D31[8] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; // this should never be touched +char o_D30[8]; +char o_D31[8]; + +void __attribute__ ((noinline)) show_state() { + printf("D30: "); + for (int i = 0; i < 8; i++) { + printf("%02x ", o_D30[i]); + } + printf("\n"); + printf("D31: "); + for (int i = 0; i < 8; i++) { + printf("%02x ", o_D31[i]); + } + printf("\n"); +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + "movw r7, #:lower16:i_D4\n" + "movt r7, #:upper16:i_D4\n" + "vldr d4, [r7]\n" + "movw r7, #:lower16:i_D8\n" + "movt r7, #:upper16:i_D8\n" + "vldr d8, [r7]\n" + "movw r7, #:lower16:i_D30\n" + "movt r7, #:upper16:i_D30\n" + "vldr d30, [r7]\n" + "movw r7, #:lower16:i_D31\n" + "movt r7, #:upper16:i_D31\n" + "vldr d31, [r7]\n" + "adr r7, Lbl_thumb + 1\n" + "bx r7\n" + ".thumb\n" + "Lbl_thumb:\n" + ".inst 0xfed8e804\n" // vcmla.f32 d30, d8, d4[0], #90 + "adr r7, Lbl_arm\n" + "bx r7\n" + ".arm\n" + "Lbl_arm:\n" + "movw r7, #:lower16:o_D30\n" + "movt r7, #:upper16:o_D30\n" + "vstr d30, [r7]\n" + "movw r7, #:lower16:o_D31\n" + "movt r7, #:upper16:o_D31\n" + "vstr d31, [r7]\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + return 0; +} +``` +2. Compile `test.bin` using this command: `arm-linux-gnueabihf-gcc-12 -O2 -no-pie -marm -march=armv7-a+vfpv4 ./test.c -o ./test.bin`. +3. Run QEMU using this command: `qemu-arm -L /usr/arm-linux-gnueabihf/ ./test.bin`. +4. The program, runs on top of the buggy QEMU, prints the value of D31 as `00 00 c0 7f 00 00 c0 7f`. It should print `ff ff ff ff ff ff ff ff` after the bug is fixed. +Additional information: + diff --git a/results/classifier/semantic-bugs/2419 b/results/classifier/semantic-bugs/2419 new file mode 100644 index 000000000..f5a600920 --- /dev/null +++ b/results/classifier/semantic-bugs/2419 @@ -0,0 +1,20 @@ + + +ldapr_stlr_i instructions doesn't consider signed offset +Description of problem: +The format ldapr_stlr_i models the load acquire / store release immediate instructions. \ +These instructions has a bug in the sign extension calculation of the imm field. \ +imm should be defined as s9 instead of 9. + +@ldapr_stlr_i .. ...... .. . imm:9 .. rn:5 rt:5 &ldapr_stlr_i + +Should be changed to: + +@ldapr_stlr_i .. ...... .. . imm:s9 .. rn:5 rt:5 &ldapr_stlr_i +Steps to reproduce: +1. Run ARM target +2. Generate any ldapr_stlr_i instructions (for example: LDAPUR) +3. When the imm value is negative, the immediate calculation is done wrong. In case the calculation leads to an undefined location, QEMU will fail. +Additional information: +In trans_LDAPR_i (translate-a64.c), when imm field is negative, the value of a->imm will be 512-x instead of x. \ +I already fixed the issue by adding the s9 to the imm field. This made a call to sextend32 for imm instead of extend32 in the generated file build/libqemu-aarch64-softmmu.fa.p/decode-a64.c.inc diff --git a/results/classifier/semantic-bugs/2422 b/results/classifier/semantic-bugs/2422 new file mode 100644 index 000000000..d1e9d0224 --- /dev/null +++ b/results/classifier/semantic-bugs/2422 @@ -0,0 +1,71 @@ + + +`vill` not set after reserved `vsetvli` instruction usage +Description of problem: +The ["AVL encoding" section of the RISC-V V Spec 1.0](https://github.com/riscv/riscv-isa-manual/blob/main/src/v-st-ext.adoc#avl-encoding) states that a `vsetvli x0,x0,...` that changes VLMAX is reserved and "Implementations may set `vill`" in this case. QEMU does not set `vill` in this case. Doing so would help detect code generation issues and non-portable code. + +Here is the quote from the spec: + +> When `rs1=x0` and `rd=x0`, the instruction operates as if the current +> vector length in `vl` is used as the AVL, and the resulting value is +> written to `vl`, but not to a destination register. This form can +> only be used when VLMAX and hence `vl` is not actually changed by the +> new SEW/LMUL ratio. Use of the instruction with a new SEW/LMUL ratio +> that would result in a change of VLMAX is reserved. +> Use of the instruction is also reserved if `vill` was 1 beforehand. +> Implementations may set `vill` in either case. + +Note, I have not checked QEMU's behaviour for the other case mentioned in the quote: "Use of the instruction is also reserved if `vill` was 1 beforehand". +Steps to reproduce: +1. Create `test.c` +```C +#include <assert.h> + +/* Position of vill in vtype. */ + +#define VILL_BIT (__riscv_xlen - 1) + +/* Return true if vill is 1. */ + +int vill_set_p () +{ + __UINT64_TYPE__ vtype; + asm volatile ("csrr %0, vtype" : "=r"(vtype)); + + return (vtype >> VILL_BIT) & 1; +} + +/* Return true if vill is 0. */ + +int vill_clear_p () +{ + return !vill_set_p (); +} + +int main () +{ + int vl; + + assert (vill_clear_p ()); + + /* Valid: vl = VLMAX. */ + asm volatile ("vsetvli %0,zero,e64,m8,ta,ma\n" : "=r"(vl)); + assert (vill_clear_p ()); + + /* Valid: vl and VLMAX not changed. */ + asm volatile ("vsetvli zero,zero,e64,m8,ta,ma\n"); + assert (vill_clear_p ()); + + /* Reserved: Reduce VLMAX. */ + asm volatile ("vsetvli zero,zero,e64,m1,ta,ma\n"); + assert (vill_set_p ()); + + return 0; +} +``` +2. Build `test.c` with `riscv32-unknown-elf-gcc test.c -o test -march=rv64gcv -mabi=lp64d` +3. Run qemu with `qemu-riscv64 -cpu rv64,v=true test` +4. The final assertion fails because executing the reserved `vsetvli` did not set `vill` +``` +assertion "vill_set_p ()" failed: file "test.c", line 40, function: main +``` diff --git a/results/classifier/semantic-bugs/2474 b/results/classifier/semantic-bugs/2474 new file mode 100644 index 000000000..360bd38d0 --- /dev/null +++ b/results/classifier/semantic-bugs/2474 @@ -0,0 +1,98 @@ + + +x86_64: strange translation of "vpgatherqq" +Description of problem: +The translate of instruction "vpgatherqq" is confusing. + +It happens when register xmm4 is in the middle, like "vpgatherqq %xmmi,0x0(,%xmm4,1),%xmmj". +Steps to reproduce: +1. Make a simple embedded assembly code named test.c: +``` +int main() +{ + asm("vpgatherqq %xmm6,0x123(,%xmm2,4),%xmm7"); + asm("vpgatherqq %xmm6,0x123(,%xmm3,4),%xmm7"); + asm("vpgatherqq %xmm6,0x123(,%xmm4,4),%xmm7"); + asm("vpgatherqq %xmm6,0x123(,%xmm5,4),%xmm7"); + return 0; +} +``` +and compile it: +``` +gcc -o test test.c -static +``` + +2. Run it with QEMU, print the micro ops: +``` +qemu-x86_64 -d op -D a.out test +``` +We can get output like this (only contain vpgatherqq): +``` + ---- 000000000040174d 0000000000000000 + mov_i64 loc2,$0x123 + add_i64 loc14,env,$0x3d0 #This is xmm2 + add_i64 loc16,env,$0x4d0 + add_i64 loc18,env,$0x510 + call vpgatherqq_xmm,$0x0,$0,env,loc18,loc16,loc14,loc2,$0x2 + mov_vec v128,e8,tmp20,v128$0x0 + st_vec v128,e8,tmp20,env,$0x4e0 + mov_vec v128,e8,tmp22,v128$0x0 + st_vec v128,e8,tmp22,env,$0x520 + + ---- 0000000000401757 0000000000000000 + mov_i64 loc2,$0x123 + add_i64 loc23,env,$0x410 #This is xmm3 + add_i64 loc25,env,$0x4d0 + add_i64 loc26,env,$0x510 + call vpgatherqq_xmm,$0x0,$0,env,loc26,loc25,loc23,loc2,$0x2 + mov_vec v128,e8,tmp27,v128$0x0 + st_vec v128,e8,tmp27,env,$0x4e0 + mov_vec v128,e8,tmp28,v128$0x0 + st_vec v128,e8,tmp28,env,$0x520 + + ---- 0000000000401761 0000000000000000 + mov_i64 loc2,$0x123 + add_i64 loc29,env,$0x310 #This is xmm4 ??? + add_i64 loc31,env,$0x4d0 + add_i64 loc32,env,$0x510 + call vpgatherqq_xmm,$0x0,$0,env,loc32,loc31,loc29,loc2,$0x2 + mov_vec v128,e8,tmp33,v128$0x0 + st_vec v128,e8,tmp33,env,$0x4e0 + mov_vec v128,e8,tmp34,v128$0x0 + st_vec v128,e8,tmp34,env,$0x520 + + ---- 000000000040176b 0000000000000000 + mov_i64 loc2,$0x123 + add_i64 loc35,env,$0x490 #This is xmm5 + add_i64 loc37,env,$0x4d0 + add_i64 loc38,env,$0x510 + call vpgatherqq_xmm,$0x0,$0,env,loc38,loc37,loc35,loc2,$0x2 + mov_vec v128,e8,tmp39,v128$0x0 + st_vec v128,e8,tmp39,env,$0x4e0 + mov_vec v128,e8,tmp40,v128$0x0 + st_vec v128,e8,tmp40,env,$0x520 +``` +3. + +Since the register xmms are continuous within the structure CPUArchState, the offset of xmm2, xmm3, xmm4, xmm5 should be a arithmetic sequence. + +From the output, we can infer that the common difference should be 0x40 and the offset of xmm4 should be 0x450 but not 0x310. + +I used GDB to track it, the location where the change occurred is: + +target/i386/tcg/translate.c, gen_lea_modrm_0(), line 2215: +``` + if (rm == 4) { + int code = x86_ldub_code(env, s); + scale = (code >> 6) & 3; + index = ((code >> 3) & 7) | REX_X(s); + if (index == 4) { + index = -1; /* no index */ + } + base = (code & 7) | REX_B(s); + havesib = 1; + } +``` +This code turned 4 into -1, and -1 do explain the offset 0x310 (xmm0 has offset 0x350). +Additional information: +Monitoring the function "helper_vpgatherqq_xmm" can draw similar conclusions: it used wrong value but not xmm4. diff --git a/results/classifier/semantic-bugs/2483 b/results/classifier/semantic-bugs/2483 new file mode 100644 index 000000000..9919ec444 --- /dev/null +++ b/results/classifier/semantic-bugs/2483 @@ -0,0 +1,22 @@ + + +m68k: jsr (sp) doesn't work as expected +Description of problem: +Consider the following code (disassembly from ghidra). This copies the current `SP` to `A1` then copies 0x68 bytes from the address pointed at by `A0` to the address pointed at by `A1` with increment. This should end up with a copy of some bytes and `SP` pointing at the first. + +``` + ff8241e6 22 4f movea.l SP,A1 + ff8241e8 70 68 moveq #0x68,D0 + LAB_ff8241ea XREF[1]: ff8241ee(j) + ff8241ea 12 d8 move.b (A0)+,(A1)+ + ff8241ec 53 80 subq.l #0x1,D0 + ff8241ee 66 fa bne.b LAB_ff8241ea + ff8241f0 4e 97 jsr (SP) +``` + +`SP` is `0x3bfc` at the `jsr` so we'd expect to jump to `0x3bfc` and put the address to return to at `0x3bf8` so the `jsr` can return I think? +What currently happens in QEMU is the return address is put at `0xb3f8` and `PC` also becomes `0x3bf8` and the return address starts being executed as code and things go off the rails. + +Forgive the screenshot but this is what it looks like with GDB connected. Dumping the memory where the `PC` is shows that the return address is actually there and we can see there is garbage before the instructions it should be executing. + +{width=289 height=759} diff --git a/results/classifier/semantic-bugs/2495 b/results/classifier/semantic-bugs/2495 new file mode 100644 index 000000000..afaaa9873 --- /dev/null +++ b/results/classifier/semantic-bugs/2495 @@ -0,0 +1,74 @@ + + +A bug in x86-64 MMX instructions +Description of problem: +It seems QEMU emits invalid TCG when lifting MMX instructions with redundant REX prefixes. For example, when lifting `490f7ec0 (movq r8, mm0)`, QEMU generates the following valid TCG. + +``` + ---- 00000000004011f2 0000000000000000 + call enter_mmx,$0x0,$0,env + ld_i64 loc0,env,$0x270 + mov_i64 r8,loc0 + mov_i64 rip,$0x4011f6 + exit_tb $0x0 + set_label $L0 + exit_tb $0x7f84f82ec143 +``` + +However, after changing the value of the rex prefix to `4f` , so the instruction becomes `4f0f7ec0 (rex.WRXB movq r8, mm0)`, the lifted TCG is changed to: + +``` + ---- 00000000004011f2 0000000000000000 + call enter_mmx,$0x0,$0,env + ld_i64 loc0,env,$0x2f0 // The offset to MM0 is changed + mov_i64 r8,loc0 + mov_i64 rip,$0x4011f6 + exit_tb $0x0 + set_label $L0 + exit_tb $0x7f98e82ec143 +``` + +I have observed this bug in numerous MMX instructions. For example, `410fdaff (rex.B pminub mm7, mm7)` is lifted to the wrong TCGs. + +It seems this bug looks similar to #2474. +Steps to reproduce: +1. Write `test.c` +``` +#include <stdint.h> +#include <stdio.h> +#include <string.h> + +uint8_t i_R8[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; +uint8_t i_MM0[8] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; +uint8_t o_R8[8]; + +void __attribute__ ((noinline)) show_state() { + printf("R8: "); + for (int i = 0; i < 8; i++) { + printf("%02x ", o_R8[i]); + } + printf("\n"); +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + ".intel_syntax noprefix\n" + "mov r8, qword ptr [rip + i_R8]\n" + "movq mm0, qword ptr [rip + i_MM0]\n" + ".byte 0x4f, 0x0f, 0x7e, 0xc0\n" + "mov qword ptr [rip + o_R8], r8\n" + ".att_syntax\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + return 0; +} +``` +2. Compile `test.bin` using this command: `gcc-12 -O2 -no-pie ./test.c -o ./test.bin` +3. Run QEMU using this command: `qemu-x86_64 ./test.bin` +4. The program, runs on top of the buggy QEMU, prints the value of R8 as `00 00 00 00 00 00 00 00`. It should print `ff ff ff ff ff ff ff ff` after the bug is fixed. +Additional information: + diff --git a/results/classifier/semantic-bugs/2497 b/results/classifier/semantic-bugs/2497 index ccc110c51..0bfbc3129 100644 --- a/results/classifier/semantic-bugs/2497 +++ b/results/classifier/semantic-bugs/2497 @@ -1,15 +1,4 @@ -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: diff --git a/results/classifier/semantic-bugs/2498 b/results/classifier/semantic-bugs/2498 new file mode 100644 index 000000000..867dbb39b --- /dev/null +++ b/results/classifier/semantic-bugs/2498 @@ -0,0 +1,53 @@ + + +m68k: fpu: fmovem with multiple control registers has incorrect in memory order +Description of problem: +It looks like the order of reading/writing registers is currently incorrect for `fmovem` with multiple fpu control registers. + +According to the manual: + +``` +The +registers are always moved in the same order, regardless of the addressing mode +used; the floating-point control register is moved first, followed by the floating-point +status register, and the floating-point instruction address register is moved last. +``` + +Current QEMU reads/writes them in the reverse order which is fine for most things but the test cases in 147bug compare against data that is in its binary and expects the data generated in memory by the CPU to match what is in it's binary. + +Maybe something like this is needed: + +``` diff +commit 466e8ead0115b6535e89aa2715f171112444b294 (HEAD -> m68kdt) +Author: Daniel Palmer <daniel@thingy.jp> +Date: Tue Aug 13 09:52:54 2024 +0900 + + fix fmovem ordering + +diff --git a/target/m68k/translate.c b/target/m68k/translate.c +index 92dc9d8563..64ff2df06e 100644 +--- a/target/m68k/translate.c ++++ b/target/m68k/translate.c +@@ -4924,8 +4924,8 @@ static void gen_op_fmove_fcr(CPUM68KState *env, DisasContext *s, + */ + + if (is_write && mode == 4) { +- for (i = 2; i >= 0; i--, mask >>= 1) { +- if (mask & 1) { ++ for (i = 2; i >= 0; i--, mask <<= 1) { ++ if (mask & 0b100) { + gen_qemu_store_fcr(s, addr, 1 << i); + if (mask != 1) { + tcg_gen_subi_i32(addr, addr, opsize_bytes(OS_LONG)); +@@ -4934,8 +4934,8 @@ static void gen_op_fmove_fcr(CPUM68KState *env, DisasContext *s, + } + tcg_gen_mov_i32(AREG(insn, 0), addr); + } else { +- for (i = 0; i < 3; i++, mask >>= 1) { +- if (mask & 1) { ++ for (i = 2; i >= 0; i--, mask <<= 1) { ++ if (mask & 0b100) { + if (is_write) { + gen_qemu_store_fcr(s, addr, 1 << i); + } else { +``` diff --git a/results/classifier/semantic-bugs/2499 b/results/classifier/semantic-bugs/2499 new file mode 100644 index 000000000..ea26a3e49 --- /dev/null +++ b/results/classifier/semantic-bugs/2499 @@ -0,0 +1,32 @@ + + +m68k: fpu: fsave/frestore should be enabled for 68020/68030 +Description of problem: +valid 68020/68030 code can use `fsave`/`frestore` instructions to save/restore the state of an external 68881/68882 but currently QEMU only allows these instructions on 68040 and everyone else gets an f-line exception. + +I guess something like this to allow frestore/fsave. m68k programmers reference manual says they are 68881/68882/68040 and there don's seem to be any differences. + +``` diff +diff --git a/target/m68k/translate.c b/target/m68k/translate.c +index d5d2322329..92dc9d8563 100644 +--- a/target/m68k/translate.c ++++ b/target/m68k/translate.c +@@ -5455,7 +5455,7 @@ DISAS_INSN(frestore) + gen_exception(s, s->base.pc_next, EXCP_PRIVILEGE); + return; + } +- if (m68k_feature(s->env, M68K_FEATURE_M68040)) { ++ if (m68k_feature(s->env, M68K_FEATURE_FPU)) { + SRC_EA(env, addr, OS_LONG, 0, NULL); + /* FIXME: check the state frame */ + } else { +@@ -5472,7 +5472,7 @@ DISAS_INSN(fsave) + return; + } + +- if (m68k_feature(s->env, M68K_FEATURE_M68040)) { ++ if (m68k_feature(s->env, M68K_FEATURE_FPU)) { + /* always write IDLE */ + TCGv idle = tcg_constant_i32(0x41000000); + DEST_EA(env, insn, OS_LONG, idle, NULL); +``` diff --git a/results/classifier/semantic-bugs/2500 b/results/classifier/semantic-bugs/2500 index 4939d31cc..473831720 100644 --- a/results/classifier/semantic-bugs/2500 +++ b/results/classifier/semantic-bugs/2500 @@ -1,15 +1,4 @@ -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: diff --git a/results/classifier/semantic-bugs/2536 b/results/classifier/semantic-bugs/2536 new file mode 100644 index 000000000..5c44b1abd --- /dev/null +++ b/results/classifier/semantic-bugs/2536 @@ -0,0 +1,3 @@ + + +Dynamic translation issue of arm instruction VFNMA and VFNMS diff --git a/results/classifier/semantic-bugs/266 b/results/classifier/semantic-bugs/266 index 4824b4c1d..3ed3d25d7 100644 --- a/results/classifier/semantic-bugs/266 +++ b/results/classifier/semantic-bugs/266 @@ -1,14 +1,3 @@ -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/2672 b/results/classifier/semantic-bugs/2672 index 3a1f3f9a5..453b0ab8e 100644 --- a/results/classifier/semantic-bugs/2672 +++ b/results/classifier/semantic-bugs/2672 @@ -1,15 +1,4 @@ -graphic: 0.901 -instruction: 0.868 -device: 0.714 -vnc: 0.423 -socket: 0.247 -boot: 0.240 -mistranslation: 0.222 -semantic: 0.216 -network: 0.205 -assembly: 0.203 -other: 0.148 -KVM: 0.040 + Skipping a jal instruction in riscv64 baremetal emulation Description of problem: diff --git a/results/classifier/semantic-bugs/2730 b/results/classifier/semantic-bugs/2730 new file mode 100644 index 000000000..bf2539d27 --- /dev/null +++ b/results/classifier/semantic-bugs/2730 @@ -0,0 +1,12 @@ + + +riscv Calculation error！ +Steps to reproduce: +The following command will produce an error output + +```asm + lui s0, 0x80000 + lw a1, -48(s0) +``` +The value of a1 becomes 0xffffffff + diff --git a/results/classifier/semantic-bugs/2802 b/results/classifier/semantic-bugs/2802 new file mode 100644 index 000000000..2b083ac9c --- /dev/null +++ b/results/classifier/semantic-bugs/2802 @@ -0,0 +1,28 @@ + + +Sparc: fdtox/fqtox instructions incorrectly select destination register +Description of problem: +This bug report is mostly for informational purposes as I will be posting a fix for the bug. + +The `fdtox` and `fqtox` instructions incorrectly select the destination register when the destination register is higher than `f31`. +Steps to reproduce: +1. Install Sparc cross compiler `gcc-12-sparc64-linux-gnu`(in Debian) +2. Compile the test program using `sparc64-linux-gnu-gcc-12 -m64 -o test_program -static test_program.c` +3. Run the test program using `qemu-sparc64-static ./test_program` +4. Expected output is 60. Prints 0 instead. +Additional information: +Test program to test the issue: + +```c +#include <stdio.h> + +int main(int argc, char** argv) { + long long truncated = 0; + __asm__("fdtox %0,%%f32\n\t" :: "f"(60.0)); + __asm__("fmovd %%f32,%0\n\t" : "=f"(truncated)); + printf("%lld\n", truncated); + return 0; +} +``` + +The issue is caused by the commit 0bba7572d4. Where certain changes were made in the way destination registers are selected(moving the DFPREG/QFPREG to decodetree). diff --git a/results/classifier/semantic-bugs/312 b/results/classifier/semantic-bugs/312 new file mode 100644 index 000000000..2645a76d1 --- /dev/null +++ b/results/classifier/semantic-bugs/312 @@ -0,0 +1,3 @@ + + +QEMU emulation of fmadds instruction on powerpc64le is buggy diff --git a/results/classifier/semantic-bugs/361 b/results/classifier/semantic-bugs/361 index ee26ed4b0..d4c0c3e2c 100644 --- a/results/classifier/semantic-bugs/361 +++ b/results/classifier/semantic-bugs/361 @@ -1,14 +1,3 @@ -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/364 b/results/classifier/semantic-bugs/364 new file mode 100644 index 000000000..f86cc4c89 --- /dev/null +++ b/results/classifier/semantic-bugs/364 @@ -0,0 +1,3 @@ + + +qemu-aarch64: incorrect signed comparison in ldsmax instructions diff --git a/results/classifier/semantic-bugs/422 b/results/classifier/semantic-bugs/422 new file mode 100644 index 000000000..56e14894e --- /dev/null +++ b/results/classifier/semantic-bugs/422 @@ -0,0 +1,3 @@ + + +Unable to execute MIPS MSA code due to illegal instruction diff --git a/results/classifier/semantic-bugs/508 b/results/classifier/semantic-bugs/508 index b05d57a9e..633944383 100644 --- a/results/classifier/semantic-bugs/508 +++ b/results/classifier/semantic-bugs/508 @@ -1,14 +1,3 @@ -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/754 b/results/classifier/semantic-bugs/754 new file mode 100644 index 000000000..589dec7c4 --- /dev/null +++ b/results/classifier/semantic-bugs/754 @@ -0,0 +1,209 @@ + + +qem_m68k : trapcs instruction causes the non-execution of the following 2 instructions +Description of problem: +In try to run following code : +``` +8004615a: 204f moveal %sp,%a0 +8004615c: b1c7 cmpal %d7,%a0 +8004615e: 55fc trapcs +80046160: 4e56 0000 linkw %fp,#0 +80046164: 2f14 movel %a4@,%sp@- +80046166: 288e movel %fp,%a4@ +80046168: c74d exg %a3,%a5 +8004616a: 48e7 3030 moveml %d2-%d3/%a2-%a3,%sp@- +8004616e: 7001 moveq #1,%d0 +80046170: 3b40 816c movew %d0,%a5@(-32404) +80046174: 7218 moveq #24,%d1 +80046176: 3b41 816a movew %d1,%a5@(-32406) +8004617a: 242d 8004 movel %a5@(-32764),%d2 +8004617e: 2b42 815c movel %d2,%a5@(-32420) +80046182: 206d 8008 moveal %a5@(-32760),%a0 +80046186: 2268 8010 moveal %a0@(-32752),%a1 +8004618a: 2b49 8158 movel %a1,%a5@(-32424) +8004618e: 42ad 8154 clrl %a5@(-32428) +80046192: 246d 8154 moveal %a5@(-32428),%a2 +80046196: 2b4a 8160 movel %a2,%a5@(-32416) +8004619a: 2b4a 8164 movel %a2,%a5@(-32412) +8004619e: 422d 8168 clrb %a5@(-32408) +800461a2: 7604 moveq #4,%d3 +800461a4: 2b43 8150 movel %d3,%a5@(-32432) +800461a8: 2668 8010 moveal %a0@(-32752),%a3 +800461ac: 2b4b 814c movel %a3,%a5@(-32436) +800461b0: 2268 8010 moveal %a0@(-32752),%a1 +800461b4: 266d 8008 moveal %a5@(-32760),%a3 +800461b8: 206b 8008 moveal %a3@(-32760),%a0 +800461bc: 4e90 jsr %a0@ +800461be: 2b48 8148 movel %a0,%a5@(-32440) +800461c2: 4cdf 0c0c moveml %sp@+,%d2-%d3/%a2-%a3 +800461c6: c74d exg %a3,%a5 +800461c8: 289f movel %sp@+,%a4@ +800461ca: 4e5e unlk %fp +800461cc: 4e75 rts +``` +When I run qemu-m68k -cpu m68020 -d in_asm,cpu, I have : +``` +---------------- +IN: +0x8004615a: moveal %sp,%a0 +0x8004615c: cmpal %d7,%a0 +0x8004615e: trapcs +0x80046160: linkw %fp,#0 +0x80046164: movel %a4@,%sp@- +0x80046166: movel %fp,%a4@ +0x80046168: exg %a3,%a5 +0x8004616a: moveml %d2-%d3/%a2-%a3,%sp@- +0x8004616e: moveq #1,%d0 +0x80046170: movew %d0,%a5@(-32404) +0x80046174: moveq #24,%d1 +0x80046176: movew %d1,%a5@(-32406) +0x8004617a: movel %a5@(-32764),%d2 +0x8004617e: movel %d2,%a5@(-32420) +0x80046182: moveal %a5@(-32760),%a0 +0x80046186: moveal %a0@(-32752),%a1 +0x8004618a: movel %a1,%a5@(-32424) +0x8004618e: clrl %a5@(-32428) +0x80046192: moveal %a5@(-32428),%a2 +0x80046196: movel %a2,%a5@(-32416) +0x8004619a: movel %a2,%a5@(-32412) +0x8004619e: clrb %a5@(-32408) +0x800461a2: moveq #4,%d3 +0x800461a4: movel %d3,%a5@(-32432) +0x800461a8: moveal %a0@(-32752),%a3 +0x800461ac: movel %a3,%a5@(-32436) +0x800461b0: moveal %a0@(-32752),%a1 +0x800461b4: moveal %a5@(-32760),%a3 +0x800461b8: moveal %a3@(-32760),%a0 +0x800461bc: jsr %a0@ + +Trace 0: 0x7f83a807e780 [00000000/8004615a/00000000/00000000] +D0 = 00000012 A0 = 8004615a F0 = 7fff ffffffffffffffff ( nan) +D1 = 00000001 A1 = 800466d6 F1 = 7fff ffffffffffffffff ( nan) +D2 = 00000000 A2 = 00000000 F2 = 7fff ffffffffffffffff ( nan) +D3 = 00000000 A3 = 8000c3b0 F3 = 7fff ffffffffffffffff ( nan) +D4 = 00000000 A4 = 8004604c F4 = 7fff ffffffffffffffff ( nan) +D5 = 00000000 A5 = 3ffd7000 F5 = 7fff ffffffffffffffff ( nan) +D6 = 00000004 A6 = 80046038 F6 = 7fff ffffffffffffffff ( nan) +D7 = 80042050 A7 = 80045ff4 F7 = 7fff ffffffffffffffff ( nan) +PC SR = 0004 T:0 I:0 UI --Z-- +FPSR = 00000000 ---- + FPCR = 0000 X RN + + +---------------- +IN: +0x80046358: lea %a1@(0,%d0:l),%a0 +0x8004635c: rts + +Trace 0: 0x7f83a807eac0 [00000000/80046358/00000000/00000000] +D0 = 00000001 A0 = 80046358 F0 = 7fff ffffffffffffffff ( nan) +D1 = 00000018 A1 = 00000000 F1 = 7fff ffffffffffffffff ( nan) +D2 = ffffffff A2 = 00000000 F2 = 7fff ffffffffffffffff ( nan) +D3 = 00000004 A3 = 8000c040 F3 = 7fff ffffffffffffffff ( nan) +D4 = 00000000 A4 = 8004604c F4 = 7fff ffffffffffffffff ( nan) +D5 = 00000000 A5 = 8000c3b0 F5 = 7fff ffffffffffffffff ( nan) +D6 = 00000004 A6 = 80046038 F6 = 7fff ffffffffffffffff ( nan) +D7 = 80042050 A7 = 80045fe0 F7 = 7fff ffffffffffffffff ( nan) +PC = 80046358 SR = 0004 T:0 I:0 UI --Z-- +FPSR = 00000000 ---- + FPCR = 0000 X RN +---------------- +``` +Stack pointer is 80045fe0, it should be 80045FD8. + +When I run with options -cpu m68020 -d in_asm,cpu,op -singlestep, I have : +``` +---------------- +IN: +0x8004615e: trapcs +0x80046160: linkw %fp,#0 +Disassembler disagrees with translator over instruction decoding +Please report this to qemu-devel@nongnu.org + +OP: + ld_i32 tmp0,env,$0xfffffffffffffff8 + brcond_i32 tmp0,$0x0,lt,$L0 + + ---- 8004615e 00000000 + mov_i32 tmp0,$0x0 + call flush_flags,$0x0,$0,env,CC_OP + setcond_i32 tmp2,CC_C,tmp0,ne + neg_i32 tmp2,tmp2 + mov_i32 tmp0,$0x56 + mov_i32 PC,$0x80046162 + exit_tb $0x0 + set_label $L0 + exit_tb $0x7fba001a75c3 + +D0 = 00000012 A0 = 80045ff4 F0 = 7fff ffffffffffffffff ( nan) +D1 = 00000001 A1 = 800466d6 F1 = 7fff ffffffffffffffff ( nan) +D2 = 00000000 A2 = 00000000 F2 = 7fff ffffffffffffffff ( nan) +D3 = 00000000 A3 = 8000c3b0 F3 = 7fff ffffffffffffffff ( nan) +D4 = 00000000 A4 = 8004604c F4 = 7fff ffffffffffffffff ( nan) +D5 = 00000000 A5 = 3ffd5000 F5 = 7fff ffffffffffffffff ( nan) +D6 = 00000004 A6 = 80046038 F6 = 7fff ffffffffffffffff ( nan) +D7 = 80042050 A7 = 80045ff4 F7 = 7fff ffffffffffffffff ( nan) +PC = 8004615e SR = 0000 T:0 I:0 UI ----- +FPSR = 00000000 ---- + FPCR = 0000 X RN +---------------- +IN: +0x80046162: orib #20,%d0 + +OP: + ld_i32 tmp0,env,$0xfffffffffffffff8 + brcond_i32 tmp0,$0x0,lt,$L0 + + ---- 80046162 00000000 + mov_i32 tmp0,$0x14 + ext8s_i32 tmp3,D0 + or_i32 tmp4,tmp3,tmp0 + and_i32 D0,D0,$0xffffff00 + ext8u_i32 tmp6,tmp4 + or_i32 D0,D0,tmp6 + ext8s_i32 CC_N,tmp4 + discard CC_C + discard CC_Z + discard CC_V + mov_i32 CC_OP,$0xb + mov_i32 PC,$0x80046166 + exit_tb $0x0 + set_label $L0 + exit_tb $0x7fba001a7683 + +D0 = 00000012 A0 = 80045ff4 F0 = 7fff ffffffffffffffff ( nan) +D1 = 00000001 A1 = 800466d6 F1 = 7fff ffffffffffffffff ( nan) +D2 = 00000000 A2 = 00000000 F2 = 7fff ffffffffffffffff ( nan) +D3 = 00000000 A3 = 8000c3b0 F3 = 7fff ffffffffffffffff ( nan) +D4 = 00000000 A4 = 8004604c F4 = 7fff ffffffffffffffff ( nan) +D5 = 00000000 A5 = 3ffd5000 F5 = 7fff ffffffffffffffff ( nan) +D6 = 00000004 A6 = 80046038 F6 = 7fff ffffffffffffffff ( nan) +D7 = 80042050 A7 = 80045ff4 F7 = 7fff ffffffffffffffff ( nan) +PC = 80046162 SR = 0000 T:0 I:0 UI ----- +FPSR = 00000000 ---- + FPCR = 0000 X RN +---------------- +IN: +0x80046166: movel %fp,%a4@ + +OP: + ld_i32 tmp0,env,$0xfffffffffffffff8 + brcond_i32 tmp0,$0x0,lt,$L0 + +... +``` +I can see that instructions +``` +0x80046160: linkw %fp,#0 +0x80046164: movel %a4@,%sp@- +``` +are not executed +and an extra instruction +``` +0x80046162: orib #20,%d0 +``` +is executed +Steps to reproduce: +Run chroot qemu-m68k qemu-m68k-static -cpu m68020 -d in_asm,cpu -D log1.txt ./test +Additional information: + diff --git a/results/classifier/semantic-bugs/799 b/results/classifier/semantic-bugs/799 index b6de1812e..69ac31ac5 100644 --- a/results/classifier/semantic-bugs/799 +++ b/results/classifier/semantic-bugs/799 @@ -1,15 +1,4 @@ -instruction: 0.871 -graphic: 0.858 -assembly: 0.798 -device: 0.740 -vnc: 0.609 -socket: 0.576 -network: 0.552 -other: 0.445 -boot: 0.333 -semantic: 0.288 -mistranslation: 0.231 -KVM: 0.164 + TCG Optimizer crashes on AArch64 SVE2 instruction Description of problem: diff --git a/results/classifier/semantic-bugs/890 b/results/classifier/semantic-bugs/890 new file mode 100644 index 000000000..845932703 --- /dev/null +++ b/results/classifier/semantic-bugs/890 @@ -0,0 +1,3 @@ + + +Misinterpretation of arm neon invalid insn diff --git a/results/classifier/semantic-bugs/993 b/results/classifier/semantic-bugs/993 new file mode 100644 index 000000000..eeae092cb --- /dev/null +++ b/results/classifier/semantic-bugs/993 @@ -0,0 +1,83 @@ + + +Invalid opcode vzeroupper +Description of problem: +Got many invalid opcode error with Fedora 36 +See fedora bug https://bugzilla.redhat.com/show_bug.cgi?id=2076410 + +Crash stack and disassemble. +``` +Downloading separate debug info for /lib64/liblzma.so.5... +Downloading separate debug info for /home/penghuang/Sources/system-supplied DSO at 0x7fff30f55000... +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib64/libthread_db.so.1". +Core was generated by `flatpak remote-add flathub https://flathub.org/repo/flathub.flatpakrepo'. +Program terminated with signal SIGILL, Illegal instruction. +#0 0x00007f89783cbe4a in sha512_block_data_order_avx2 () from /lib64/libgnutls.so.30 +[Current thread is 1 (Thread 0x7f8972ada640 (LWP 5083))] +(gdb) bt +#0 0x00007f89783cbe4a in sha512_block_data_order_avx2 () from /lib64/libgnutls.so.30 +#1 0x00007f89783bf042 in x86_sha512_update (ctx=0x7f8972ad9090, length=128, data=0x7f8972ad8f90 '\\' <repeats 128 times>, "@\255") + at sha-x86-ssse3.c:215 +#2 0x00007f897810879b in nettle_hmac_set_key (outer=<optimized out>, inner=0x7f8972ad9168, state=<optimized out>, + hash=0x7f897848b6c0 <x86_sha384>, key_length=0, key=0x7f89783ff943 "") at /usr/src/debug/nettle-3.7.3-3.fc36.x86_64/hmac.c:83 +#3 0x00007f89783bce3a in wrap_x86_hmac_fast (algo=<optimized out>, nonce=<optimized out>, nonce_size=<optimized out>, key=0x7f89783ff943, + key_size=0, text=0x7f8972ad9430, text_size=48, digest=0x55a79d80b948) at hmac-x86-ssse3.c:294 +#4 0x00007f89782d4b57 in _gnutls_mac_fast (algorithm=GNUTLS_MAC_SHA384, key=0x7f89783ff943, keylen=0, text=0x7f8972ad9430, textlen=48, + digest=0x55a79d80b948) at hash_int.c:167 +#5 0x00007f89782f524d in gnutls_hmac_fast (algorithm=GNUTLS_MAC_SHA384, key=key@entry=0x7f89783ff943, keylen=keylen@entry=0, + ptext=0x7f8972ad9430, ptext_len=ptext_len@entry=48, digest=digest@entry=0x55a79d80b948) at crypto-api.c:640 +#6 0x00007f897830d2ff in _tls13_init_secret2 (prf=0x7f897848f888 <hash_algorithms+168>, psk=<optimized out>, psk@entry=0x0, psk_size=48, + psk_size@entry=0, out=out@entry=0x55a79d80b948) at secrets.c:59 +#7 0x00007f897830d3d0 in _tls13_init_secret (session=session@entry=0x55a79d80a1c0, psk=psk@entry=0x0, psk_size=psk_size@entry=0) at secrets.c:35 +#8 0x00007f89782c66c0 in read_server_hello (datalen=<optimized out>, data=<optimized out>, session=0x55a79d80a1c0) at handshake.c:2097 +#9 _gnutls_recv_handshake (session=session@entry=0x55a79d80a1c0, type=type@entry=GNUTLS_HANDSHAKE_SERVER_HELLO, optional=optional@entry=0, + buf=buf@entry=0x0) at handshake.c:1656 +#10 0x00007f89782c8dbb in handshake_client (session=0x55a79d80a1c0) at handshake.c:3072 +#11 gnutls_handshake (session=0x55a79d80a1c0) at handshake.c:2871 +#12 0x00007f89784a694f in g_tls_connection_gnutls_handshake_thread_handshake (tls=0x55a79d80c250, timeout=<optimized out>, + cancellable=<optimized out>, error=0x7f8972ad9b10) at ../tls/gnutls/gtlsconnection-gnutls.c:968 +#13 0x00007f89784a8942 in handshake_thread (task=0x7f8968007ec0, object=object@entry=0x55a79d80c250, task_data=task_data@entry=0x55a79d766e60, + cancellable=cancellable@entry=0x55a79d748760) at ../tls/base/gtlsconnection-base.c:1564 +#14 0x00007f89784a8c02 in async_handshake_thread (task=<optimized out>, object=0x55a79d80c250, task_data=0x55a79d766e60, + cancellable=0x55a79d748760) at ../tls/base/gtlsconnection-base.c:1848 +#15 0x00007f89882dbaf3 in g_task_thread_pool_thread (thread_data=0x7f8968007ec0, pool_data=<optimized out>) at ../gio/gtask.c:1441 +#16 0x00007f8988111b72 in g_thread_pool_thread_proxy (data=<optimized out>) at ../glib/gthreadpool.c:354 +#17 0x00007f898810f172 in g_thread_proxy (data=0x55a79d7e1360) at ../glib/gthread.c:827 +#18 0x00007f8987efdcc7 in start_thread (arg=<optimized out>) at pthread_create.c:442 +#19 0x00007f8987f82e00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81 +(gdb) +(gdb) disassemble +Dump of assembler code for function sha512_block_data_order_avx2: + 0x00007f89783cbe00 <+0>: mov %rsp,%rax + 0x00007f89783cbe03 <+3>: push %rbx + 0x00007f89783cbe04 <+4>: push %rbp + 0x00007f89783cbe05 <+5>: push %r12 + 0x00007f89783cbe07 <+7>: push %r13 + 0x00007f89783cbe09 <+9>: push %r14 + 0x00007f89783cbe0b <+11>: push %r15 + 0x00007f89783cbe0d <+13>: sub $0x520,%rsp + 0x00007f89783cbe14 <+20>: shl $0x4,%rdx + 0x00007f89783cbe18 <+24>: and $0xfffffffffffff800,%rsp + 0x00007f89783cbe1f <+31>: lea (%rsi,%rdx,8),%rdx + 0x00007f89783cbe23 <+35>: add $0x480,%rsp + 0x00007f89783cbe2a <+42>: mov %rdi,0x80(%rsp) + 0x00007f89783cbe32 <+50>: mov %rsi,0x88(%rsp) + 0x00007f89783cbe3a <+58>: mov %rdx,0x90(%rsp) + 0x00007f89783cbe42 <+66>: mov %rax,0x98(%rsp) +=> 0x00007f89783cbe4a <+74>: vzeroupper + 0x00007f89783cbe4d <+77>: sub $0xffffffffffffff80,%rsi + 0x00007f89783cbe51 <+81>: mov (%rdi),%rax + 0x00007f89783cbe54 <+84>: mov %rsi,%r12 + 0x00007f89783cbe57 <+87>: mov 0x8(%rdi),%rbx + 0x00007f89783cbe5b <+91>: cmp %rdx,%rsi + 0x00007f89783cbe5e <+94>: mov 0x10(%rdi),%rcx + 0x00007f89783cbe62 <+98>: cmove %rsp,%r12 + 0x00007f89783cbe66 <+102>: mov 0x18(%rdi),%rdx + 0x00007f89783cbe6a <+106>: mov 0x20(%rdi),%r8 + 0x00007f89783cbe6e <+110>: mov 0x28(%rdi),%r9 + 0x00007f89783cbe72 <+114>: mov 0x30(%rdi),%r10 + 0x00007f89783cbe76 <+118>: mov 0x38(%rdi),%r11 + 0x00007f89783cbe7a <+122>: jmp 0x7f89783cbe80 <sha512_block_data_order_avx2+128> + 0x00007f89783cbe7c <+124>: nopl 0x0(%rax) +``` |