diff options
Diffstat (limited to 'results/classifier/gemma3:27b/instruction')
197 files changed, 8394 insertions, 0 deletions
diff --git a/results/classifier/gemma3:27b/instruction/1022 b/results/classifier/gemma3:27b/instruction/1022 new file mode 100644 index 000000000..d81aef62e --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1022 @@ -0,0 +1,36 @@ + + + +RISC-V: Simulation terminated with seg fault when encountering `vsra.vx` +Description of problem: +QEMU simulation terminated with segmentation fault. Here is the backtrace of the simulation + +``` +(gdb) r +Starting program: qemu/build/qemu-riscv64 -cpu rv64,vext_spec=v1.0,v=true,Zfh=true,Zve32f=true,Zve64f=true,vlen=128 -B 0x100000 a.out +Missing separate debuginfos, use: yum debuginfo-install glibc-2.28-164.el8_5.3.x86_64 +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib64/libthread_db.so.1". +[New Thread 0x7ffff4edd700 (LWP 3239772)] + +Thread 1 "qemu-riscv64" received signal SIGSEGV, Segmentation fault. +0x00007fffe8004fad in code_gen_buffer () +Missing separate debuginfos, use: yum debuginfo-install glib2-2.56.4-156.el8.x86_64 gmp-6.1.2-10.el8.x86_64 gnutls-3.6.16-4.el8.x86_64 libffi-3.1-22.el8.x86_64 libidn2-2.2.0-1.el8.x86_64 libtasn1-4.13-3.el8.x86_64 libunistring-0.9.9-3.el8.x86_64 p11-kit-0.23.22-1.el8.x86_64 pcre-8.42-6.el8.x86_64 +(gdb) bt +#0 0x00007fffe8004fad in code_gen_buffer () +#1 0x00005555556a0b9b in cpu_tb_exec (tb_exit=<synthetic pointer>, itb=<optimized out>, cpu=0x7fffe8005000 <code_gen_buffer+20435>) at ../accel/tcg/cpu-exec.c:358 +#2 cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, cpu=0x7fffe8005000 <code_gen_buffer+20435>) at ../accel/tcg/cpu-exec.c:848 +#3 cpu_exec (cpu=cpu@entry=0x555555eed3d0) at ../accel/tcg/cpu-exec.c:1007 +#4 0x00005555555e6d30 in cpu_loop (env=0x555555ef56f0) at ../linux-user/riscv/cpu_loop.c:37 +#5 0x00005555555df9f7 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../linux-user/main.c:909 +``` +Steps to reproduce: +1. Checkout to QEMU's latest master (`ec11dc41eec5142b4776db1296972c6323ba5847`) +2. `mkdir build ; cd build ; ../configure ; make -j24` +3. `qemu-riscv64 -cpu rv64,vext_spec=v1.0,v=true,Zfh=true,Zve32f=true,Zve64f=true,vlen=128 -B 0x100000 ./a.out` +Additional information: +Attaching code (output.c) and binary (a.out) + +[a.out](/uploads/0ecfb436a439619527ef645bdc781a48/a.out) + +[output.c](/uploads/cd492b4c9468f0b48412e76e7f6fcf91/output.c) diff --git a/results/classifier/gemma3:27b/instruction/1028 b/results/classifier/gemma3:27b/instruction/1028 new file mode 100644 index 000000000..cda1046c4 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1028 @@ -0,0 +1,37 @@ + + + +Assert fail for RISC-V RVV vmv.v.x for e64, vl == vl_max on RV32 guest +Description of problem: +assert message: +qemu/tcg/tcg-op-gvec.c:1714: tcg_gen_gvec_dup_i32: Assertion `vece <= MO_32' failed. + +For a e64 vmv.v.x, in the file trans_rvv.c.inc, function "trans_vmv_v_x", when s->vl_eq_vlmax is true, then "tcg_gen_gvec_dup_tl" (it's defined to tcg_gen_gvec_dup_i32 for RV32) is called. In "tcg_gen_gvec_dup_i32" the assert "tcg_debug_assert(vece <= MO_32) will be triggered, since vece == MO_64 for e64. +Steps to reproduce: +1.enable cfg.Zve64f + +2.Prepare a problem as set e64, vl == vl_max and use vmv.v.x, maybe as below +``` + li t0, -1, + vsetvli x0, t0, e64,m1,tu,mu + li t1, -1 + vmv.v.x v0, t1 +``` +Additional information: +Below is a possible solution if it's appropriate. +``` +#if TARGET_LONG_BITS == 32 + if (s->sew == 3) { + TCGv_i64 s1_i64 = tcg_temp_new_i64(); + tcg_gen_ext_tl_i64(s1_i64, s1); + tcg_gen_gvec_dup_i64(s->sew, vreg_ofs(s, a->rd), + MAXSZ(s), MAXSZ(s), s1_i64); + tcg_temp_free_i64(s1_i64); + } else { +#endif + tcg_gen_gvec_dup_tl(s->sew, vreg_ofs(s, a->rd), + MAXSZ(s), MAXSZ(s), s1); +#if TARGET_LONG_BITS == 32 + } +#endif +``` diff --git a/results/classifier/gemma3:27b/instruction/1051 b/results/classifier/gemma3:27b/instruction/1051 new file mode 100644 index 000000000..fcbf675c2 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1051 @@ -0,0 +1,4 @@ + + + +or1k tcg SIGILL diff --git a/results/classifier/gemma3:27b/instruction/1079080 b/results/classifier/gemma3:27b/instruction/1079080 new file mode 100644 index 000000000..c3723248d --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1079080 @@ -0,0 +1,43 @@ +instruction: 0.967 +graphic: 0.903 +device: 0.901 +semantic: 0.833 +network: 0.755 +socket: 0.707 +vnc: 0.648 +boot: 0.648 +other: 0.637 +mistranslation: 0.619 +assembly: 0.187 +KVM: 0.100 + +ARM instruction "srs" wrong behaviour + +Quote from ARM Architecture Reference Manual ARMv7-A and ARMv7-R : +"Store Return State stores the LR and SPSR of the current mode to the stack of a specified mode" + +Problem: +When executing this instruction, the register stored is CPSR instead of SPSR. + +Context: +Using QEMU 1.2.0 to simulate a Zynq application (processor Cortex-a9 mpcore) with the following command line: +qemu-system-arm -M xilinx-zynq-a9 -m 512 -serial null -serial mon:stdio -dtb /home/vcesson/workspace/xilinx_zynq.dtb -kernel install/tests/io/serial/current/tests/serial2 -S -s -nographic + +It looks like this is only a problem in Thumb mode; the equivalent bug in ARM mode was fixed in commit c67b6b71 back in 2009. + +Can you make the test case dtb and image available? That would help in testing... + + + + + + +Thanks -- I've submitted a patch which fixes this: http://patchwork.ozlabs.org/patch/220748/ + +If you'd like to give me a name/email [format "Full Name <email address hidden>"] I can credit you in a Reported-by: tag in the commit message... + + +You are welcome. +Credit info you need: Cesson Vincent <email address hidden> +Thank you for fixing it! + diff --git a/results/classifier/gemma3:27b/instruction/1092 b/results/classifier/gemma3:27b/instruction/1092 new file mode 100644 index 000000000..60c305b43 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1092 @@ -0,0 +1,17 @@ + + + +PPC: `sraw` instructions does not set `ca` and `ca32` flags. +Description of problem: +The translation of Power PC instruction `sraw` and `sraw.` don't set the `ca` or `ca32` flags although, according to +[PowerISA 3.1b](https://files.openpower.foundation/s/dAYSdGzTfW4j2r2) (page 140), they should. +Additional information: +This gets particular apparent if compared to `srawi` (which does set `ca`, `ca32`). + +**sraw** + +https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L2914 + +**srawi** + +https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L2924 diff --git a/results/classifier/gemma3:27b/instruction/1095531 b/results/classifier/gemma3:27b/instruction/1095531 new file mode 100644 index 000000000..0de5aed7b --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1095531 @@ -0,0 +1,60 @@ + + + +sparc32plus (and others?) has x86 code generation errors on 64bit hosts + +On 64bit hosts, the load and store functions compile improperly. The issue is the call to gen_address_mask() under the ld and st functions in target-sparc/translate.c. Below are some snips from the log file. Doing a gdb debug, this results in constant access violation errors which I do not see when debugging qemu in powerpc mode. + +-------------- +IN: +0x0000000040804aa8: st %i0, [ %fp + 0x44 ] + +OP: + ---- 0x40804aa8 + ld_i64 tmp1,regwptr,$0xb0 + mov_i64 tmp0,tmp1 + movi_i64 tmp2,$0x44 + add_i64 tmp0,tmp0,tmp2 + ld_i64 tmp2,regwptr,$0x80 + ext32u_i64 tmp0,tmp0 + qemu_st32 tmp2,tmp0,$0x0 + +OUT: [size=345] +0x6032d7f0: mov 0x40(%r14),%rbp +0x6032d7f4: mov 0xb0(%rbp),%rbx +0x6032d7fb: add $0x44,%rbx +0x6032d7ff: mov 0x80(%rbp),%rbp +0x6032d806: mov %ebx,%ebx <- bug +0x6032d808: mov %ebp,%edi +0x6032d80a: bswap %edi +0x6032d80c: mov %edi,(%rbx) + +-------------- +IN: +0x0000000040804aec: add %l7, %o7, %l7 +0x0000000040804af0: ld [ %l7 ], %g2 + +OP: + ---- 0x40804aec + ld_i64 tmp1,regwptr,$0x78 + ld_i64 tmp2,regwptr,$0x38 + add_i64 tmp0,tmp1,tmp2 + st_i64 tmp0,regwptr,$0x78 + + ---- 0x40804af0 + ld_i64 tmp1,regwptr,$0x78 + mov_i64 tmp0,tmp1 + ext32u_i64 tmp0,tmp0 + qemu_ld32u g2,tmp0,$0x0 + +OUT: [size=395] +0x6032da80: mov 0x40(%r14),%rbp +0x6032da84: mov 0x78(%rbp),%rbx +0x6032da88: mov 0x38(%rbp),%r12 +0x6032da8c: add %r12,%rbx +0x6032da8f: mov %rbx,0x78(%rbp) +0x6032da93: mov 0x78(%rbp),%rbx +0x6032da97: mov %ebx,%ebx <- bug +0x6032da99: mov (%rbx),%ebx + +In 64bit mode, doing a 32bit operation will result in the top 32bit's being zero'd. I attempted to simply disable the call to gen_address_mask() but that did not fix the issue and actually caused the sparc32plus I was testing to become unusable. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1095857 b/results/classifier/gemma3:27b/instruction/1095857 new file mode 100644 index 000000000..c82825908 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1095857 @@ -0,0 +1,14 @@ + + + +incorrect handling of [r32] address (long mode) + +while executing in Long Mode (x86-64) instructions such as + +mov eax,[r15d] + +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. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1128 b/results/classifier/gemma3:27b/instruction/1128 new file mode 100644 index 000000000..902f0bafe --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1128 @@ -0,0 +1,27 @@ + + + +PPC: `spr_write_xer` doesn't set flag bits in `cpu_xer` +Description of problem: +`spr_write_xer()` does not set the `ca`, `ov`, `so`, `ca32`, `ov32` etc. flag bits in the `cpu_xer` variable. + +In fact it copies all bits from the source `GPR` and _excludes_ each flag bit. + +This is not a problem for execution since `spr_read_xer()` gets the flag bits from `cpu_ca/ov/so...` and not from `cpu_xer`. + +Nonetheless it is problem for tools which trace the execution in QEMU (e.g. https://github.com/BinaryAnalysisPlatform/qemu). + +A fix would be to remove the `~` in https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L481 +Steps to reproduce: +Haven't found out yet how to debug QEMU so the TCGv values can be investigated. But in general one need to: + +- Execute a binary which executes something like: +``` +r4 = 0xffffffffffffffff +mtxer r4 +``` +and check the `cpu_xer` value after the `xer` write. + +Checking the debug logs (`in_asm,cpu`) doesn't work, since the `xer` value in the logs is not taken directly from `cpu_xer`. +Additional information: +Code ref: https://gitlab.com/qemu-project/qemu/-/blob/master/target/ppc/translate.c#L480-L483 diff --git a/results/classifier/gemma3:27b/instruction/1129571 b/results/classifier/gemma3:27b/instruction/1129571 new file mode 100644 index 000000000..dc66da3bb --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1129571 @@ -0,0 +1,17 @@ + + + +libreoffice armhf FTBFS + +We have been experiencing FTBFS of LibreOffice 3.5.7, 12.04, armhf in the launchpad buildds. We believe this is likely due to an error in qemu. + +While we do not have a small test case yet, we do have a build log (attaching here). + +The relevant snippet from the build log is: + +3.5.7/solver/unxlngr.pro/bin/jaxp.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/juh.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/parser.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/xt.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/unoil.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/ridl.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/jurt.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/xmlsearch.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/LuceneHelpWrapper.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/HelpIndexerTool.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/lucene-core-2.3.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/lucene-analyzers-2.3.jar" com.sun.star.help.HelpIndexerTool -lang cs -mod swriter -zipdir ../../unxlngr.pro/misc/ziptmpswriter_cs -o ../../unxlngr.pro/bin/swriter_cs.zip.unxlngr.pro +dmake: Error code 132, while making '../../unxlngr.pro/bin/swriter_cs.zip' + +We believe this is from bash error code 128 + 4, where 4 is illegal instruction, thus leading us to suspect qemu. + +Any help in tracking this down would be appreciated. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1143 b/results/classifier/gemma3:27b/instruction/1143 new file mode 100644 index 000000000..12f8fe91e --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1143 @@ -0,0 +1,81 @@ + + + +Breakpoints missed when a function is split into two memory pages. +Description of problem: +Qemu seems to ignore some breakpoints when the start of a function is +in another page than where the breakpoint is set. + +In my case, I've a function `__gnat_debug_raise_exception` which starts at `0x10bff2` and I've set with gdb a breakpoint at `0x10c00e` (in another page). +While running with `qemu -d in_asm,exec`, I can see that the whole function is executed at once and that no breakpoint is fired. + +``` +(gdb) b *0x00108fbc +(gdb) b *0x0010c00e +(gdb) target remote :1234 +(gdb) c + +Trace 0: 0x7f277c0174c0 [0000000000000000/0000000000108fb9/0040c0b0/ff000201] ada__exceptions__complete_occurrence +---------------- + +// gdb hits first breakpoint here. +Breakpoint 3, 0x0000000000108fbc .... +(gdb) ni + +IN: ada__exceptions__complete_occurrence +0x00108fbc: e8 31 30 00 00 callq 0x10bff2 + +Trace 0: 0x7f277c000100 [0000000000000000/0000000000108fbc/0040c0b0/ff000e01] ada__exceptions__complete_occurrence +---------------- +IN: __gnat_debug_raise_exception +0x0010bff2: 55 pushq %rbp +0x0010bff3: 48 89 e5 movq %rsp, %rbp +0x0010bff6: 48 89 7d f8 movq %rdi, -8(%rbp) +0x0010bffa: 48 89 d1 movq %rdx, %rcx +0x0010bffd: 48 89 f0 movq %rsi, %rax +0x0010c000: 48 89 fa movq %rdi, %rdx +0x0010c003: 48 89 ca movq %rcx, %rdx +0x0010c006: 48 89 45 e0 movq %rax, -0x20(%rbp) +0x0010c00a: 48 89 55 e8 movq %rdx, -0x18(%rbp) +0x0010c00e: 48 8b 45 e0 movq -0x20(%rbp), %rax +0x0010c012: 90 nop +0x0010c013: 5d popq %rbp +0x0010c014: c3 retq + +Trace 0: 0x7f277c000100 [0000000000000000/000000000010bff2/0040c0b0/ff000000] __gnat_debug_raise_exception +Digging a bit more, it seems that it seems related to + +// gdb ni stop here. Breakpoints at 0x10c00e have been ignored. +``` + +Note that if I'm setting another breakpoint at `0x0010bffd` (thus not at the start of the function but still in the same page), the execution +will be executed step by step and the breakpoint at 0x10c00e will be triggered normally. + + +``` +IN: ada__exceptions__complete_occurrence +0x00108fbc: e8 31 30 00 00 callq 0x10bff2 + +Trace 0: 0x7f6af4000100 [0000000000000000/0000000000108fbc/0040c0b0/ff000e01] ada__exceptions__complete_occurrence +---------------- +IN: __gnat_debug_raise_exception +0x0010bff2: 55 pushq %rbp + +Trace 0: 0x7f6af4000100 [0000000000000000/000000000010bff2/0040c0b0/ff000201] __gnat_debug_raise_exception +---------------- +IN: __gnat_debug_raise_exception +0x0010bff3: 48 89 e5 movq %rsp, %rbp + +Trace 0: 0x7f6af4000280 [0000000000000000/000000000010bff3/0040c0b0/ff000201] __gnat_debug_raise_exception +---------------- +IN: __gnat_debug_raise_exception +0x0010bff6: 48 89 7d f8 movq %rdi, -8(%rbp) +... +``` + +I've dug a bit into qemu translator code and I guess `check_for_breakpoint` should check that the whole function is in the same page before skipping step by step. But I'm not sure if it's possible because the TB is created after `check_for_breakpoint` IIUC. + +Sadly as of now, I don't have a C reproducer. I can try to provide you my "foo" program which is an Ada program. But maybe if you've a better idea how to reproduce that or an idea of to fix that, I'll be glad to help you. + +Thanks, +Clément diff --git a/results/classifier/gemma3:27b/instruction/1156 b/results/classifier/gemma3:27b/instruction/1156 new file mode 100644 index 000000000..76296a60b --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1156 @@ -0,0 +1,4 @@ + + + +Incorrect implementation of vmsumudm instruction diff --git a/results/classifier/gemma3:27b/instruction/1156313 b/results/classifier/gemma3:27b/instruction/1156313 new file mode 100644 index 000000000..54d2d0f95 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1156313 @@ -0,0 +1,128 @@ +semantic: 0.869 +mistranslation: 0.841 +assembly: 0.789 +device: 0.777 +instruction: 0.707 +other: 0.705 +vnc: 0.702 +graphic: 0.657 +socket: 0.605 +boot: 0.576 +network: 0.533 +KVM: 0.518 + +X86-64 flags handling broken + +The current qemu sources cause improper handling of flags on x86-64. +This bug seems to have shown up a few weeks ago. + +A plain install of Debian GNU/Linux makes user processes catch +spurious signals. The kernel seems to run stably, though. + +The ADX feature works very poorly. It might be related; at least it +allows for reproducibly provoking invalid behaviour. + +Here is a test case: + +================================================================ +qemumain.c +#include <stdio.h> +long adx(); +int +main () +{ + printf ("%lx\n", adx (0xffbeef, 17)); + return 0; +} +================================================================ +qemuadx.s: + .globl adx +adx: xor %rax, %rax +1: dec %rdi + jnz 1b + .byte 0xf3, 0x48, 0x0f, 0x38, 0xf6, 0xc0 # adox %rax, %rax + .byte 0x66, 0x48, 0x0f, 0x38, 0xf6, 0xc0 # adcx %rax, %rax + ret +================================================================ + +Compile and execute: +$ gcc -m64 qemumain.c qemuadx.s +$ a.out +ffffff8000378cd8 + +Expected output is simply "0". The garbage value varies between qemu +compiles and guest systems. + +Note that one needs a recent GNU assembler in order to handle adox and +adcx. For convenience I have supplied them as byte sequences. + +Exaplanation and feeble analysis: + +The 0xffbeef argument is a loop count. It is necessary to loop for a +while in order to trigger this bug. If the loop count is decreased, +the bug will seen intermittently; the lower the count, the less +frequent the invalid behaviour. + +It seems like a reasonable assumption that this bug is related to +flags handling at context switch. Presumably, qemu keeps flags state +in some internal format, then recomputes then when needing to form the +eflags register, as needed for example for context switching. + +I haven't tried to reproduce this bug using qemu-x86_64 and SYSROOT, +but I strongly suspect that to be impossible. I use +qemu-system-x86_64 and the guest Debian GNU/Linux x86_64 (version +6.0.6) . + +The bug happens also with the guest FreeBSD x86_64 version 9.1. (The +iteration count for triggering the problem 50% of the runs is not the +same when using the kernel Linux and FreeBSD's kernel, presumably due +to different ticks.) + +The bug happens much more frequently for a loaded system; in fact, the +loop count can be radically decreased if two instances of the trigger +program are run in parallel. + +Richard Henderson <email address hidden> writes: + + Patch at http://patchwork.ozlabs.org/patch/229139/ + +Thanks. I can confirm that this fixes the bug triggered by my test case +(and yours). However, the instability of Debian GNU/Linux x86_64 has +not improved. + +The exact same Debian version (debian "testing") updated at the same +time runs well on hardware. + +My qemu Debian system now got messed up, since I attempted an upgrade in +the buggy qemu, which segfaulted several times during the upgrade. I +need to reinstall, and then rely on -snapshot. + +There is a problem with denorms which is reproducible, but whether that +is a qemu bug, and whether it can actually cause the observed +instability, is questionable. Here is a testcase for that problem: + + + + +It should terminate. The observed buggy behaviour is that it hangs. + +The instability problem can be observed at gmplib.org/devel/tm-date.html. +hwl-deb.gmplib.org is Debian under qemu with -cpu Haswell,+adx. + +Not that the exact same qemu runs FreeBSD flawlessly (hwl.gmplib.org). +It is neither instable nor does it run the denorms testcase poorly. + +I fully realise this is a hopeless bug report, but I am sure you can +reproduce it, since it is far from GMP specific. After all apt-get +update; apt-get upgrade triggered it. Debugging it will be a nightmare. + +Qemu version: main git repo from less than a week ago + Richard ADX +patch. + +-- +Torbjörn + + +It looks from this bug that we fixed the initial ADOX bug in commit c53de1a2896cc (2013), and I've just tried the 'qemu-denorm-problem.s' test case from comment #1 and it works OK, so I think we've fixed that denormals bug too. Given that, and that this bug report is 4 years old, I'm going to close it. If you're still having problems with recent versions of QEMU, please open a new bug. + + diff --git a/results/classifier/gemma3:27b/instruction/1178 b/results/classifier/gemma3:27b/instruction/1178 new file mode 100644 index 000000000..ffe5b226f --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1178 @@ -0,0 +1,4 @@ + + + +is that riscv64 `feq.s` only should consider the lowest 32-bits. diff --git a/results/classifier/gemma3:27b/instruction/1245543 b/results/classifier/gemma3:27b/instruction/1245543 new file mode 100644 index 000000000..6ca865d95 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1245543 @@ -0,0 +1,26 @@ + + + +Wrong implementation of SSE4.1 pmovzxbw and similar instructions + +QEMU 1.5.0 (and git version, as far as I can tell from the source code) has incorrect implementation of pmovzxbw and similar SSE4.1 instructions. The instruction zero-extends the first 8 8-bit elements of a vector to 16bit vector and puts them to another vector. The current implementation applies this operation only to the first element and zeros out the rest. + +To verify, compile the attached program for SSE4.1 (g++ -msse4.1 cvtint.cc). On real hardware, it produces the following output: + +$ ./a.out +1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 + +On QEMU, the output is as follows: + +$ ./a.out +1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 + +QEMU is invoked as: + +qemu-system-x86_64 \ + -M pc -cpu Haswell,+sse4.1,+avx,+avx2,+fma,enforce -m 512 \ + -serial stdio -no-reboot \ + -kernel vmlinuz -initrd initrd.img \ + -netdev user,id=user.0 -device rtl8139,netdev=user.0 -redir tcp:2222::22 \ + -hda ubuntu-amd64.ext3 \ + --append "rw console=tty root=/dev/sda" \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1248 b/results/classifier/gemma3:27b/instruction/1248 new file mode 100644 index 000000000..49134e68b --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1248 @@ -0,0 +1,14 @@ + + + +s390x: glibc widestring algorithms broken +Description of problem: +Several wide-string functions from glibc are broken und qemu user emulation. +Affected are at least: `wcsbrk()`, `wcsspn()` and `wcscspn()`. All of these are implemented in optimized assembler in glibc. + +Unfortunately I don't have access to the real hardware to check the behavior there. But it would probably been detected by now. +Also I don't know which instructions exactly don't work, as I don't have any knowledge about s390x assembler. +Steps to reproduce: +1. Compile the test program above +2. Run the program +3. Output is `0`, should be `1`. diff --git a/results/classifier/gemma3:27b/instruction/1248168 b/results/classifier/gemma3:27b/instruction/1248168 new file mode 100644 index 000000000..06b56a323 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1248168 @@ -0,0 +1,27 @@ + + + +MIPS, self-modifying code and uncached memory + +Self-modifying code does not work properly in MIPS in uncached and unmapped kseg1 memory region. + +For example, when running this code I get unexpected behavior: + + 0: e3000010 b 0x390 + 4: 00000000 nop + ... + 380: 00701f40 mfc0 ra,c0_epc + 384: 0400e0bb swr zero,4(ra) + 388: 18000042 eret + 38c: 00000000 nop + 390: 25500000 move t2,zero + 394: 02000b34 li t3,0x2 + 398: 23504b01 subu t2,t2,t3 + 39c: e9003c0b j 0xcf003a4 + 3a0: 0a004a21 addi t2,t2,10 + 3a4: ffff0010 b 0x3a4 + 3a8: 00000000 nop + 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. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1251 b/results/classifier/gemma3:27b/instruction/1251 new file mode 100644 index 000000000..a9c329191 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1251 @@ -0,0 +1,18 @@ + + + +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/gemma3:27b/instruction/1254786 b/results/classifier/gemma3:27b/instruction/1254786 new file mode 100644 index 000000000..315e2004c --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1254786 @@ -0,0 +1,45 @@ + + + +qemu-m68k-static: illegal instruction ebc0 during debootstrap second stage + +Host: Ubuntu Precise amd64 +Guest: Debian (ports) sid m68k + +$ sudo qemu-debootstrap --no-check-gpg --arch=m68k sid m68k http://ftp.debian-ports.org/debian +I: Running command: debootstrap --arch m68k --foreign --no-check-gpg sid m68k http://ftp.debian-ports.org/debian +[...] +I: Running command: chroot m68k /debootstrap/debootstrap --second-stage +qemu: fatal: Illegal instruction: ebc0 @ f67e5662 +D0 = 6ffffef5 A0 = f67fbf58 F0 = 0000000000000000 ( 0) +D1 = 0000010a A1 = 00000000 F1 = 0000000000000000 ( 0) +D2 = 0000000f A2 = 00000000 F2 = 0000000000000000 ( 0) +D3 = 00000000 A3 = f67e0000 F3 = 0000000000000000 ( 0) +D4 = 00000000 A4 = 00000000 F4 = 0000000000000000 ( 0) +D5 = 00000000 A5 = f67fc000 F5 = 0000000000000000 ( 0) +D6 = 00000000 A6 = f6fff7cc F6 = 0000000000000000 ( 0) +D7 = 00000000 A7 = f6fff580 F7 = 0000000000000000 ( 0) +PC = f67e5662 SR = 0000 ----- FPRESULT = 0 +Aborted (core dumped) + +ProblemType: Bug +DistroRelease: Ubuntu 12.04 +Package: qemu-user-static 1.0.50-2012.03-0ubuntu2.1 +ProcVersionSignature: Ubuntu 3.8.0-33.48~precise1-generic 3.8.13.11 +Uname: Linux 3.8.0-33-generic x86_64 +NonfreeKernelModules: wl +ApportVersion: 2.0.1-0ubuntu17.6 +Architecture: amd64 +Date: Mon Nov 25 16:08:26 2013 +Dependencies: + +InstallationMedia: Ubuntu 12.04.3 LTS "Precise Pangolin" - Release amd64 (20130820.1) +MarkForUpload: True +ProcEnviron: + LANGUAGE=en_GB:en + TERM=xterm + PATH=(custom, no user) + LANG=en_GB.UTF-8 + SHELL=/bin/bash +SourcePackage: qemu-linaro +UpgradeStatus: No upgrade log present (probably fresh install) \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1267 b/results/classifier/gemma3:27b/instruction/1267 new file mode 100644 index 000000000..c27f29476 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1267 @@ -0,0 +1,96 @@ + + + +qemu-i386 missing VDSO +Description of problem: +Qemu crashes with a segmentation fault when running any binary using qemu-i386. Steps to reproduce are trivial, simply run `qemu-user ./test`. The file is here: [test](/uploads/fe0d498713e79d7e39f417e69ad64c2f/test). Basically any binary compiled with `GOARCH=386` using [TinyGo](https://tinygo.org/) should reproduce this issue. +I also tried some trivial Go compiled binary and they also crash, but this time with an internal Go error that suggests something is terribly broken over there too: `fatal error: mallocgc called without a P or outside bootstrapping` + +Interestingly, qemu-x86_64 and qemu-arm appear to work just fine. + +Unfortunately I couldn't get a good backtrace on newer versions. It looks like this in the git version, which I doubt is correct: + +``` +~/src/qemu/build$ /bin/lldb ./qemu-i386 +(lldb) target create "./qemu-i386" +Current executable set to '/home/ayke/src/qemu/build/qemu-i386' (aarch64). +(lldb) run /home/ayke/src/tinygo/tinygo/test +Process 97986 launched: '/home/ayke/src/qemu/build/qemu-i386' (aarch64) +Process 97986 stopped +* thread #1, name = 'qemu-i386', stop reason = unknown crash reason + frame #0: 0x0000fffff78fb9fc libc.so.6`__sigsuspend + 92 +libc.so.6`__sigsuspend: +-> 0xfffff78fb9fc <+92>: svc #0 + 0xfffff78fba00 <+96>: cmn x0, #0x1, lsl #12 ; =0x1000 + 0xfffff78fba04 <+100>: b.hi 0xfffff78fba3c ; <+156> + 0xfffff78fba08 <+104>: mov w19, w0 +(lldb) bt +* thread #1, name = 'qemu-i386', stop reason = unknown crash reason + * frame #0: 0x0000fffff78fb9fc libc.so.6`__sigsuspend + 92 + frame #1: 0x0000aaaaaabfcedc qemu-i386`dump_core_and_abort(target_sig=11) at signal.c:745:5 + frame #2: 0x0000aaaaaabfc128 qemu-i386`handle_pending_signal(cpu_env=0x0000aaaaaae5d2e0, sig=11, k=0x0000aaaaaae68af8) at signal.c:1061:13 + frame #3: 0x0000aaaaaabfbe48 qemu-i386`process_pending_signals(cpu_env=0x0000aaaaaae5d2e0) at signal.c:1141:13 + frame #4: 0x0000aaaaaaae5a04 qemu-i386`cpu_loop(env=0x0000aaaaaae5d2e0) at cpu_loop.c:315:9 + frame #5: 0x0000aaaaaabf5e7c qemu-i386`main(argc=2, argv=0x0000ffffffffecd8, envp=0x0000ffffffffecf0) at main.c:925:5 + frame #6: 0x0000fffff78e7b80 libc.so.6`___lldb_unnamed_symbol2945 + 112 + frame #7: 0x0000fffff78e7c60 libc.so.6`__libc_start_main + 160 + frame #8: 0x0000aaaaaaae0430 qemu-i386`_start at start.S:81 +(lldb) ^D +``` + +I got a better (but still not great) backtrace in Qemu 7.0.0: + +``` +~/src/tinygo/tinygo$ /bin/lldb qemu-i386 +(lldb) target create "qemu-i386" +Current executable set to 'qemu-i386' (aarch64). +(lldb) run test +Process 98106 launched: '/usr/bin/qemu-i386' (aarch64) +Process 98106 stopped +* thread #1, name = 'qemu-i386', stop reason = signal SIGSEGV: address access protected (fault address: 0x8000) + frame #0: 0x0000aaaaaac4b564 qemu-i386`cpu_ldub_code + 32 +qemu-i386`cpu_ldub_code: +-> 0xaaaaaac4b564 <+32>: ldrb w0, [x0, w1, uxtw] + 0xaaaaaac4b568 <+36>: str xzr, [x2] + 0xaaaaaac4b56c <+40>: ret + +qemu-i386`cpu_lduw_code: + 0xaaaaaac4b570 <+0>: mrs x2, TPIDR_EL0 +(lldb) bt +* thread #1, name = 'qemu-i386', stop reason = signal SIGSEGV: address access protected (fault address: 0x8000) + * frame #0: 0x0000aaaaaac4b564 qemu-i386`cpu_ldub_code + 32 + frame #1: 0x0000aaaaaac4a4a8 qemu-i386`translator_ldub_swap + 72 + frame #2: 0x0000aaaaaabe6714 qemu-i386`___lldb_unnamed_symbol6310 + 144 + frame #3: 0x0000aaaaaabed2e8 qemu-i386`___lldb_unnamed_symbol6311 + 24 + frame #4: 0x0000aaaaaac4a040 qemu-i386`translator_loop + 400 + frame #5: 0x0000aaaaaabed5a8 qemu-i386`gen_intermediate_code + 72 + frame #6: 0x0000aaaaaac486ec qemu-i386`tb_gen_code + 364 + frame #7: 0x0000aaaaaac43068 qemu-i386`cpu_exec + 1480 + frame #8: 0x0000aaaaaabaa4b0 qemu-i386`cpu_loop + 208 + frame #9: 0x0000aaaaaab8cb54 qemu-i386`main + 2020 + frame #10: 0x0000fffff7687b80 libc.so.6`___lldb_unnamed_symbol2945 + 112 + frame #11: 0x0000fffff7687c60 libc.so.6`__libc_start_main + 160 + frame #12: 0x0000aaaaaab8d3b0 qemu-i386`_start + 48 +(lldb) ^D +``` + +And an even better backtrace for an even older version (5.2.0). Though I should note that this GDB also had an assertion failue, but the backtrace looks reasonable: + +``` +#0 0x0000aaaaaaba7804 in cpu_ldub_code (env=env@entry=0x0, ptr=0) at ../../accel/tcg/user-exec.c:1170 +#1 0x0000aaaaaab40d04 in translator_ldub_swap (do_swap=false, pc=<optimized out>, env=<optimized out>) at ./include/exec/translator.h:176 +#2 translator_ldub (pc=<optimized out>, env=<optimized out>) at ./include/exec/translator.h:176 +#3 x86_ldub_code (env=env@entry=0xaaaaaad809f0, s=s@entry=0xffffffffe990) at ../../target/i386/translate.c:1916 +#4 0x0000aaaaaab51670 in disas_insn (s=s@entry=0xffffffffe990, cpu=<optimized out>, cpu=<optimized out>) at ../../target/i386/translate.c:4506 +#5 0x0000aaaaaab5e1c8 in i386_tr_translate_insn (dcbase=0xffffffffe990, cpu=<optimized out>) at ../../target/i386/translate.c:8569 +#6 0x0000aaaaaabbc9f4 in translator_loop (ops=0xaaaaaacd62b0 <i386_tr_ops>, db=0xffffffffe990, cpu=0xaaaaaad786a0, tb=<optimized out>, max_insns=<optimized out>) + at ../../accel/tcg/translator.c:103 +#7 0x0000aaaaaab5e470 in gen_intermediate_code (cpu=cpu@entry=0xaaaaaad786a0, tb=tb@entry=0xffffe8007f00, max_insns=max_insns@entry=512) + at ../../target/i386/translate.c:8631 +#8 0x0000aaaaaabcd54c in tb_gen_code (cpu=cpu@entry=0xaaaaaad786a0, pc=pc@entry=0, cs_base=cs_base@entry=0, flags=flags@entry=4194483, cflags=-16777216, + cflags@entry=0) at ../../accel/tcg/translate-all.c:1744 +#9 0x0000aaaaaabbe2a8 in tb_find (cf_mask=0, tb_exit=0, last_tb=0x0, cpu=0xaaaaaad786a0) at ../../accel/tcg/cpu-exec.c:414 +#10 cpu_exec (cpu=cpu@entry=0xaaaaaad786a0) at ../../accel/tcg/cpu-exec.c:770 +#11 0x0000aaaaaab3a438 in cpu_loop (env=env@entry=0xaaaaaad809f0) at ../../linux-user/i386/cpu_loop.c:207 +#12 0x0000aaaaaab1df00 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../../linux-user/main.c:882 +``` diff --git a/results/classifier/gemma3:27b/instruction/1267955 b/results/classifier/gemma3:27b/instruction/1267955 new file mode 100644 index 000000000..f18f0c665 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1267955 @@ -0,0 +1,45 @@ + + + +[i386] Parity Flag Not Set On xor %eax,%eax + +Tested against qemu-1.7.0 as well as qemu-1.7.50 on Debian Sid + +Steps To Reproduce + +$ cat > prog.hex << EOF + +7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 +02 00 03 00 01 00 00 00 54 80 04 08 34 00 00 00 +00 00 00 00 00 00 00 00 34 00 20 00 01 00 28 00 +00 00 00 00 01 00 00 00 00 00 00 00 00 80 04 08 +00 80 04 08 76 00 00 00 76 00 00 00 05 00 00 00 +00 10 00 00 + +31 c0 +9c + +b8 04 00 00 00 +bb 01 00 00 00 +89 e1 +ba 04 00 00 00 +cd 80 + +b8 01 00 00 00 +bb 00 00 00 00 +cd 80 + +EOF + +$ xxd -p -r prog.hex > prog +$ chmod 700 prog + +$ ./prog | hexdump -vC +00000000 46 02 00 00 |F...| +00000004 + +$ qemu-i386 ./prog | hexdump -vC +00000000 42 02 00 00 |B...| +00000004 + +On the other hand if [xor %eax, %eax] (31 c0) is replaced with sub %eax,%eax (29 c0), then the parity flag is set correctly. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1283519 b/results/classifier/gemma3:27b/instruction/1283519 new file mode 100644 index 000000000..c65570d39 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1283519 @@ -0,0 +1,13 @@ + + + +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/gemma3:27b/instruction/1308381 b/results/classifier/gemma3:27b/instruction/1308381 new file mode 100644 index 000000000..0560b9306 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1308381 @@ -0,0 +1,17 @@ + + + +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/gemma3:27b/instruction/1328996 b/results/classifier/gemma3:27b/instruction/1328996 new file mode 100644 index 000000000..418a4353a --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1328996 @@ -0,0 +1,6 @@ + + + +[AArch64] - blr x30 is handled incorrectly + +Whenever x30 is used as the operand for blr, the result will be incorrect. There is no restriction on using x30 (LR) with the blr instruction in the ARMv8 manual. There are two statically linked 64-bit executables in files.tar.gz: good and bad. The executable "good" uses "blr x9", and the output is what is expected: "func". The executable "bad" uses "blr x30" and nothing is printed out. It prints "func" on the actual device. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1339 b/results/classifier/gemma3:27b/instruction/1339 new file mode 100644 index 000000000..dd0af5e85 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1339 @@ -0,0 +1,19 @@ + + + +RVV vfncvt.rtz.x.f.w Assertion failed +Description of problem: +when execute +``` +vsetvli t0, x0, e16, m1 +vfncvt.rtz.x.f.w v0, v4 +``` +report error: + +qemu-riscv64: ../target/riscv/translate.c:212: decode_save_opc: Assertion \`ctx->insn_start != NULL' failed. Segmentation fault (core dumped) +Steps to reproduce: +1. write the code +2. compile +3. excute +Additional information: + diff --git a/results/classifier/gemma3:27b/instruction/1368 b/results/classifier/gemma3:27b/instruction/1368 new file mode 100644 index 000000000..a0d2c738c --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1368 @@ -0,0 +1,41 @@ + + + +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/gemma3:27b/instruction/1370 b/results/classifier/gemma3:27b/instruction/1370 new file mode 100644 index 000000000..da284a401 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1370 @@ -0,0 +1,16 @@ + + + +x86 BLSI and BLSR semantic bug +Description of problem: +The result of instruction BLSI and BLSR is different from the CPU. The value of CF is different. +Steps to reproduce: +1. Compile this code +``` +void main() { + asm("blsi rax, rbx"); +} +``` +2. Execute and compare the result with the CPU. The value of `CF` is exactly the opposite. This problem happens with BLSR, too. +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/gemma3:27b/instruction/1371 b/results/classifier/gemma3:27b/instruction/1371 new file mode 100644 index 000000000..a77c0b1fe --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1371 @@ -0,0 +1,22 @@ + + + +x86 BLSMSK semantic bug +Description of problem: +The result of instruction BLSMSK is different with from the CPU. The value of CF is different. +Steps to reproduce: +1. Compile this code +``` +void main() { + asm("mov rax, 0x65b2e276ad27c67"); + asm("mov rbx, 0x62f34955226b2b5d"); + asm("blsmsk eax, ebx"); +} +``` +2. Execute and compare the result with the CPU. + - CPU + - CF = 0 + - QEMU + - CF = 1 +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/gemma3:27b/instruction/1372 b/results/classifier/gemma3:27b/instruction/1372 new file mode 100644 index 000000000..ded24a388 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1372 @@ -0,0 +1,23 @@ + + + +x86 BEXTR semantic bug +Description of problem: +The result of instruction BEXTR is different with from the CPU. The value of destination register is different. I think QEMU does not consider the operand size limit. +Steps to reproduce: +1. Compile this code +``` +void main() { + asm("mov rax, 0x17b3693f77fb6e9"); + asm("mov rbx, 0x8f635a775ad3b9b4"); + asm("mov rcx, 0xb717b75da9983018"); + asm("bextr eax, ebx, ecx"); +} +``` +2. Execute and compare the result with the CPU. + - CPU + - RAX = 0x5a + - QEMU + - RAX = 0x635a775a +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/gemma3:27b/instruction/1373 b/results/classifier/gemma3:27b/instruction/1373 new file mode 100644 index 000000000..d31e7a28e --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1373 @@ -0,0 +1,23 @@ + + + +x86 ADOX and ADCX semantic bug +Description of problem: +The result of instruction ADOX and ADCX are different from the CPU. The value of one of EFLAGS is different. +Steps to reproduce: +1. Compile this code +``` +void main() { + asm("push 512; popfq;"); + asm("mov rax, 0xffffffff84fdbf24"); + asm("mov rbx, 0xb197d26043bec15d"); + asm("adox eax, ebx"); +} +``` +2. Execute and compare the result with the CPU. This problem happens with ADCX, too (with CF). + - CPU + - OF = 0 + - QEMU + - OF = 1 +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/gemma3:27b/instruction/1374 b/results/classifier/gemma3:27b/instruction/1374 new file mode 100644 index 000000000..f23fdda34 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1374 @@ -0,0 +1,25 @@ + + + +x86 BZHI semantic bug +Description of problem: +The result of instruction BZHI is different from the CPU. The value of destination register and SF of EFLAGS are different. +Steps to reproduce: +1. Compile this code +``` +void main() { + asm("mov rax, 0xb1aa9da2fe33fe3"); + asm("mov rbx, 0x80000000ffffffff"); + asm("mov rcx, 0xf3fce8829b99a5c6"); + asm("bzhi rax, rbx, rcx"); +} +``` +2. Execute and compare the result with the CPU. + - CPU + - RAX = 0x0x80000000ffffffff + - SF = 1 + - QEMU + - RAX = 0xffffffff + - SF = 0 +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/gemma3:27b/instruction/1375 b/results/classifier/gemma3:27b/instruction/1375 new file mode 100644 index 000000000..62948b02a --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1375 @@ -0,0 +1,22 @@ + + + +x86 SSE/SSE2/SSE3 instruction semantic bugs with NaN +Description of problem: +The result of SSE/SSE2/SSE3 instructions with NaN is different from the CPU. From Intel manual Volume 1 Appendix D.4.2.2, they defined the behavior of such instructions with NaN. But I think QEMU did not implement this semantic exactly because the byte result is different. +Steps to reproduce: +1. Compile this code +``` +void main() { + asm("mov rax, 0x000000007fffffff; push rax; mov rax, 0x00000000ffffffff; push rax; movdqu XMM1, [rsp];"); + asm("mov rax, 0x2e711de7aa46af1a; push rax; mov rax, 0x7fffffff7fffffff; push rax; movdqu XMM2, [rsp];"); + asm("addsubps xmm1, xmm2"); +} +``` +2. Execute and compare the result with the CPU. This problem happens with other SSE/SSE2/SSE3 instructions specified in the manual, Volume 1 Appendix D.4.2.2. + - CPU + - xmm1[3] = 0xffffffff + - QEMU + - xmm1[3] = 0x7fffffff +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/gemma3:27b/instruction/1376 b/results/classifier/gemma3:27b/instruction/1376 new file mode 100644 index 000000000..f6ab4a57f --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1376 @@ -0,0 +1,18 @@ + + + +x86 LSL and LAR fault +Description of problem: +From the description of LSL and LAR instructions in manual, `If the segment descriptor cannot be accessed or is an invalid type for the instruction, the ZF flag is cleared and no value is loaded in the destination operand.`. When it happens at the CPU, it seems they do nothing (nop). However, in QEMU, it crashes. +Steps to reproduce: +1. Compile this code +``` +void main() { + asm("mov rax, 0xa02e698e741f5a6a"); + asm("mov rbx, 0x20959ddd7a0aef"); + asm("lsl ax, bx"); +} +``` +2. Execute. QEMU crashes but CPU does not. This problem happens with LAR, too. +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/gemma3:27b/instruction/1377 b/results/classifier/gemma3:27b/instruction/1377 new file mode 100644 index 000000000..f3d87d4fe --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1377 @@ -0,0 +1,27 @@ +instruction: 0.973 +assembly: 0.847 +device: 0.773 +vnc: 0.768 +graphic: 0.742 +boot: 0.462 +socket: 0.412 +KVM: 0.326 +semantic: 0.321 +network: 0.279 +other: 0.095 +mistranslation: 0.073 + +x86 CVT* series instructions fault +Description of problem: +For example, CVTSD2SS instruction converts SRC[63:0] double precision floating point to DEST[31:0] single precision floating point. Although the CVTSD2SS instruction uses only 8 bytes, if it overlaps page boundary, I think QEMU tries to access over the valid memory and crashes. +Steps to reproduce: +1. Compile this code +``` +void main() { + mmap(0x555555559000, 0x1000, flag, ~~, 0); + asm("cvtsd2ss xmm1, qword ptr [0x555555559ff8]"); +} +``` +2. Execute. QEMU crashes but CPU does not. +Additional information: +This bug is discovered by research conducted by KAIST SoftSec. diff --git a/results/classifier/gemma3:27b/instruction/1397 b/results/classifier/gemma3:27b/instruction/1397 new file mode 100644 index 000000000..5267b8404 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1397 @@ -0,0 +1,4 @@ + + + +riscv: break, hbreak does not set a breakpoint on the correct address when providing symbols diff --git a/results/classifier/gemma3:27b/instruction/1404690 b/results/classifier/gemma3:27b/instruction/1404690 new file mode 100644 index 000000000..7ef62aa3c --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1404690 @@ -0,0 +1,41 @@ + + + +Qemu crashes with chrooted m68k + +I'm using qemu-m68k 2.2.0 to chroot into a m68k coldfire linux, which works fine on the coldfire machine. + +I've been able to use binfmt_msc and used the above code to use qemu with strace: + +#include <unistd.h> +#include <string.h> + +int main(int argc, char **argv, char **envp) { + char *newargv[argc + 4]; + + newargv[0] = argv[0]; + newargv[1] = "-cpu"; + newargv[2] = "cfv4e"; + newargv[3] = "-strace"; + + memcpy(&newargv[4], &argv[1], sizeof(*argv) * (argc - 1)); + newargv[argc + 3] = NULL; + return execve("/usr/bin/qemu-m68k", newargv, envp); +} + +Everything works fine. I can run bash, busybox, ash, but when I try to run a ls or just type an invalid command, I got the attached sequence of messages, which end like so: + +11351 waitpid(-1,0xf6fffa00,0x3) = -1 errno=10 (No child processes) +qemu: fatal: Illegal instruction: 0000 @ f6fffa30 +D0 = ffffffff A0 = f67dcf50 F0 = 0000000000000000 ( 0) +D1 = 0000000a A1 = f66e0898 F1 = 0000000000000000 ( 0) +D2 = f6fffaa8 A2 = f67df268 F2 = 0000000000000000 ( 0) +D3 = 00000000 A3 = 00000000 F3 = 0000000000000000 ( 0) +D4 = 00000008 A4 = 800026c4 F4 = 0000000000000000 ( 0) +D5 = 00000000 A5 = f67d98e0 F5 = 0000000000000000 ( 0) +D6 = f6fffaa8 A6 = f6fffa7c F6 = 0000000000000000 ( 0) +D7 = 00000002 A7 = f6fffa24 F7 = 0000000000000000 ( 0) +PC = f6fffa30 SR = 0000 ----- FPRESULT = 0 +Aborted + +How can I debug it further to try to figure out if this is a qemu issue or not? Thanks \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1412 b/results/classifier/gemma3:27b/instruction/1412 new file mode 100644 index 000000000..9c9539b49 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1412 @@ -0,0 +1,8 @@ + + + +QEMU segfault (null pointer dereference) in sve_probe_page from ldff1* instructions +Description of problem: +After upgrading to QEMU v7.2.0 from v7.1.0, when executing any SVE ldff1* instructions with a faulting address, QEMU crashes due to a null pointer dereference at target/arm/sve_helper.c:5364 + +I believe this was introduced in b8967ddf393aaf35fdbc07b4cb538a40f8b6fe37 (@rth7680), since in that commit `full` is dereferenced before the `flags & TLB_INVALID_MASK` check at line 5369, and full is set to null by `probe_access_full` when `TLB_INVALID_MASK` is given. diff --git a/results/classifier/gemma3:27b/instruction/1428352 b/results/classifier/gemma3:27b/instruction/1428352 new file mode 100644 index 000000000..860650387 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1428352 @@ -0,0 +1,47 @@ + + + +SYSRET instruction incorrectly implemented + +The Intel architecture manual states that when returning to user mode, the SYSRET instruction will re-load the stack selector (%ss) from the IA32_STAR model specific register using the following logic: + +SS.Selector <-- (IA32_STAR[63:48]+8) OR 3; (* RPL forced to 3 *) + +Another description of the instruction behavior which shows the same logic in a slightly different form can also be found here: + +http://tptp.cc/mirrors/siyobik.info/instruction/SYSRET.html + +[...] + SS(SEL) = IA32_STAR[63:48] + 8; + SS(PL) = 0x3; +[...] + +In other words, the value of the %ss register is supposed to be loaded from bits 63:48 of the IA32_STAR model-specific register, incremented by 8, and then ORed with 3. ORing in the 3 sets the privilege level to 3 (user). This is done since SYSRET returns to user mode after a system call. + +However, helper_sysret() in target-i386/seg_helper.c does not do the "OR 3" step. The code looks like this: + + cpu_x86_load_seg_cache(env, R_SS, selector + 8, + 0, 0xffffffff, + DESC_G_MASK | DESC_B_MASK | DESC_P_MASK | + DESC_S_MASK | (3 << DESC_DPL_SHIFT) | + DESC_W_MASK | DESC_A_MASK); + +It should look like this: + + cpu_x86_load_seg_cache(env, R_SS, (selector + 8) | 3, + 0, 0xffffffff, + DESC_G_MASK | DESC_B_MASK | DESC_P_MASK | + DESC_S_MASK | (3 << DESC_DPL_SHIFT) | + DESC_W_MASK | DESC_A_MASK); + +The code does correctly set the privilege level bits for the code selector register (%cs) but not for the stack selector (%ss). + +The effect of this is that when SYSRET returns control to the user-mode caller, %ss will be have the privilege level bits cleared. In my case, it went from 0x2b to 0x28. This caused a crash later: when the user-mode code was preempted by an interrupt, and the interrupt handler would do an IRET, a general protection fault would occur because the %ss value being loaded from the exception frame was not valid for user mode. (At least, I think that's what happened.) + +This behavior seems inconsistent with real hardware, and also appears to be wrong with respect to the Intel documentation, so I'm pretty confident in calling this a bug. :) + +Note that this issue seems to have been around for a long time. I discovered it while using QEMU 2.2.0, but I happened to have the sources for QEMU 0.10.5, and the problem is there too (in os_helper.c). I am using FreeBSD/amd64 9.1-RELEASE as my host system, without KVM. + +The fix is fairly simple. I'm attaching a patch which worked for me. Using this fix, the code that I'm testing now behaves the same on the QEMU virtual machine as on real hardware. + +- Bill (<email address hidden>) \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1435 b/results/classifier/gemma3:27b/instruction/1435 new file mode 100644 index 000000000..b7aa2928e --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1435 @@ -0,0 +1,19 @@ + + + +Infinite recursion in tcg_gen_mulu2_i32 for certain 32-bit hosts. +Description of problem: +`tcg_gen_mulu2_i32` infinitely recurses on a 32-bit host (TCG target) that has neither `TCG_TARGET_HAS_mulu2_i32` nor `TCG_TARGET_HAS_muluh_i32`. + +I don't actually think there is any host that is 32-bits and has neither mulu2 nor muluh. The only reference I found is [this](https://gitlab.com/qemu-project/qemu/-/commit/df9ebea53ebc1c98217743f56c30ae3a46031bb9) commit, which adds an `#error` if that situation is hit. But the check, which [still exists](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/include/tcg/tcg.h#L174), checks if those flags are *defined*, not for their value. I guess, over the years as the code was refactored, the check wasn't updated because, frankly, there aren't any hosts that match that situation (except mine). + +One easy fix is to change the check mentioned above to check the actual macro value so that compilation fails. I can create a PR for that. +Steps to reproduce: +(Note: I'm linking to the v7.2.0 tag so that these links stay relevant). + +1. `tcg_gen_mulu2_i32` [calls](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/tcg/tcg-op.c#L890) `tcg_gen_mul_i64`. +2. `tcg_gen_mul_i64` on 32-bit hosts, due to [this](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/tcg/tcg-op.c#L1097) check for `TCG_TARGET_REG_BITS == 32`, is defined [here](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/tcg/tcg-op.c#L1218), and [calls](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/tcg/tcg-op.c#L1226) `tcg_gen_mulu2_i32`. +3. Rinse and repeat. +4. Eventually, as gen_mulu2/mul functions spill while trying to allocate temps, they will overflow the TB buffer. This will restart code generation with smaller and smaller block sizes, until the block size reaches 1 instruction. TCG will then give up and [assert](https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/accel/tcg/translate-all.c#L869). +Additional information: + diff --git a/results/classifier/gemma3:27b/instruction/1441 b/results/classifier/gemma3:27b/instruction/1441 new file mode 100644 index 000000000..9aaffc7f3 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1441 @@ -0,0 +1,37 @@ + + + +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/gemma3:27b/instruction/1452 b/results/classifier/gemma3:27b/instruction/1452 new file mode 100644 index 000000000..d0390a57f --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1452 @@ -0,0 +1,4 @@ + + + +Tricore: support for shuffle and syscall instruction diff --git a/results/classifier/gemma3:27b/instruction/1469342 b/results/classifier/gemma3:27b/instruction/1469342 new file mode 100644 index 000000000..31e8630a1 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1469342 @@ -0,0 +1,6 @@ + + + +qemu-i386 pentium3/athlon incorrect instruction set + +Running a binary containing a movsd instruction (SSE2) in 32-bit qemu-i386 -cpu pentium3 from 20150609 results in flawless execution whereas it should crash with SIGILL as P3 only had SSE. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1531 b/results/classifier/gemma3:27b/instruction/1531 new file mode 100644 index 000000000..e6a3bf1f6 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1531 @@ -0,0 +1,18 @@ + + + +MIPSr6+MSA emulation is broken in QEMU 6.2.0 (Ubuntu 22.04 LTS) and 7.0.0 +Description of problem: +Many tests (8,11,12,13,15,19,23,30,31,36) are failing due to QEMU emulation problem. +Steps to reproduce: +1. Download the source code from https://github.com/VectorChief/UniSIMD-assembler (master or v1.1.0c) +2. Change to project's test directory and build the binary for MIPS using cross-compiler (see simd_make_m64.mk) +3. Run the binary with QEMU linux-user mode: qemu-mips64el -cpu I6400 simd_test.m64f32Lr6 -c 1 | tee qemu64 +4. Check the output text file qemu64 (with pluma or any other text editor) to see the error printouts +Additional information: +The pre-built binary and its output file are attached as test.tar.gz +[test.tar.gz](/uploads/7a54ba10919a1b221dd8ea0e8c02c064/test.tar.gz) + +Please note, that standalone cross-compiler for MIPS downloaded from the site +(Codescape.GNU.Tools.Package.2020.06-01.for.MIPS.MTI.Linux.CentOS-6.x86_64.tar.gz) +comes with its own version of QEMU 4.1.0 which masks the system's QEMU when added to the PATH. diff --git a/results/classifier/gemma3:27b/instruction/1536 b/results/classifier/gemma3:27b/instruction/1536 new file mode 100644 index 000000000..252246abf --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1536 @@ -0,0 +1,19 @@ + + + +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/gemma3:27b/instruction/1574346 b/results/classifier/gemma3:27b/instruction/1574346 new file mode 100644 index 000000000..59fce0e2b --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1574346 @@ -0,0 +1,15 @@ + + + +TCG: mov to segment register is incorrectly emulated for AMD CPUs + +In TCG mode, the effect of: + +xorl %eax, %eax +movl %eax, %gs + +is to mark the GS segment unusable and set its base to zero. After doing this, reading MSR_GS_BASE will return zero and using a GS prefix in long mode will treat the GS base as zero. + +This is correct for Intel CPUs but is incorrect for AMD CPUs. On an AMD CPU, writing 0 to %gs using mov, pop, or (I think) lgs will leave the base unchanged. + +To make it easier to use TCG to validate behavior on different CPUs, please consider changing the TCG behavior to match actual CPU behavior when emulating an AMD CPU. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1590336 b/results/classifier/gemma3:27b/instruction/1590336 new file mode 100644 index 000000000..5f78ff54e --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1590336 @@ -0,0 +1,18 @@ + + + +qemu-arm does not reject vrintz on non-v8 cpu + +Hello, + +It seems that qemu-arm does not reject some v8-only instructions as it should, but executes them "correctly". + +For instance, while compiling/running some of the GCC ARM instrinsics tests, we noticed that +vrintz should be rejected on cortex-a9 for instance, while it is executed as if the instruction was supported. + +objdump says: + 1074c: f3fa05a0 vrintz.f32 d16, d16 +and qemu -d in_asm says: +0x0001074c: f3fa05a0 vabal.u<illegal width 64> q8, d26, d16 + +The problem is still present in qemu-2.6.0 \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1594069 b/results/classifier/gemma3:27b/instruction/1594069 new file mode 100644 index 000000000..2d47150c2 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1594069 @@ -0,0 +1,11 @@ + + + +SIMD instructions translated to scalar host instructions + +SIMD instructions inside the guest (NEON, MMX, SSE, SSE2, AVX) are translated to scalar instructions on the host instead of SIMD instructions. It appears that there have been a few efforts to rectify this [1], and even a submitted patch series, but all discussion has effectively died out [2]. + +I would like to see better SIMD performance on qemu, especially as non-x86 architectures are becoming widely used (e.g. ARM). + +[1] http://dl.acm.org/citation.cfm?id=2757098&dl=ACM&coll=DL&CFID=633095244&CFTOKEN=12352103 +[2] https://lists.nongnu.org/archive/html/qemu-devel/2014-10/msg01720.html \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1605123 b/results/classifier/gemma3:27b/instruction/1605123 new file mode 100644 index 000000000..f79f6cadd --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1605123 @@ -0,0 +1,31 @@ + + + +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/gemma3:27b/instruction/1606 b/results/classifier/gemma3:27b/instruction/1606 new file mode 100644 index 000000000..6f678ad0f --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1606 @@ -0,0 +1,32 @@ + + + +riscv: fence.i is not functional +Description of problem: +The attached user-level test is designed to do the following (in iteration): + + - Thread P0 on CPU0 changes some text/code, while + + - Thread P1 on CPU1 checks/reads the code, fence.i, then executes the same code. + +Results (in stdout) indicates that CPU1 has read the new code (1:x5=a009) but executed the old one (1:x7=1) (against the specification). +Steps to reproduce: +1. echo 2 > /proc/sys/vm/nr_hugepages +2. ./CoRF+fence.i +Additional information: +Example output: +```[CoRF+fence.i.c](/uploads/c150ca0910783cc4bfc3886789b64c28/CoRF+fence.i.c) +Test CoRF+fence.i Allowed +Histogram (4 states) +25784 :>1:x5=0xa009; 1:x7=2; +24207 *>1:x5=0xa009; 1:x7=1; <-- THIS LINE +8 :>1:x5=0xa019; 1:x7=1; +1 :>1:x5=0xa019; 1:x7=2; +Ok +Witnesses +Positive: 24207 Negative 25793 +Condition exists (1:x5=0xa009 /\ 1:x7=1) is validated +Observation CoRF+fence.i Sometimes 24207 25793 +Time CoRF+fence.i 0.85 +Hash= +``` diff --git a/results/classifier/gemma3:27b/instruction/1611394 b/results/classifier/gemma3:27b/instruction/1611394 new file mode 100644 index 000000000..0e397a201 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1611394 @@ -0,0 +1,32 @@ + + + +qemu-ppc: Scalar Single-Precision Floating-Point instructions should not test MSR[SPV] + +According to "Signal Processing Engine (SPE) Programming Environments Manual" at +http://cache.nxp.com/files/32bit/doc/ref_manual/SPEPEM.pdf?fsrch=1&sr=1&pageNum=1 + +c.f section 4.2.3 and also Figure 2-2. + +When MSR[SPV] is _NOT_ set, then the embedded scalar single-precision floating-point instructions +should _NOT_ generate an Embedded Floating-Point Unavailable Interrupt. + + +Hence, some tests for MSR[SPV] in file target-ppc/translate.c need to be removed. +Namely, in the definitions of +1. GEN_SPEFPUOP_ARITH2_32_32 +2. gen_efsabs +3. gen_efsnabs +4. gen_efsneg +5. GEN_SPEFPUOP_COMP_32 + +Note, the macro GEN_SPEFPUOP_CONV_32_32 is already correct. + +One more thing, afaict the macro GEN_SPEFPUOP_CONV_32_64 is used by both +efs- and efd- instructions, and will need to be split in two versions. +The efs-use (i.e for efscfd) should be as it is today, but the use by efd-instructions +(e.g efdctui) will need to add a test for MSR[SPV]. + + + +(I've looked at today's HEAD-revision of target-ppc/translate.c). \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1612 b/results/classifier/gemma3:27b/instruction/1612 new file mode 100644 index 000000000..076536677 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1612 @@ -0,0 +1,54 @@ + + + +SVE first-faulting gather loads return incorrect data +Description of problem: +The results of `ldff1(b|h|w|d)` seem to be incorrect when `<Zt> == <Zm>`. The first element is duplicated throughout the vector while the FFR indicates that all elements were successfully loaded. This happens since https://gitlab.com/qemu-project/qemu/-/commit/50de9b78cec06e6d16e92a114a505779359ca532, and still happens on the latest master. +Steps to reproduce: +1. This assembly sequence loads data with an `ldff1d` instruction (and also loads the ffr). Note that with `ldff1d`, `<Zt> == <Zm>`. + +asmtest.s +``` + .type asmtest, @function + .balign 16 + .global asmtest +asmtest: + setffr + ptrue p0.d + index z1.d, #0, #1 + ldff1d z1.d, p0/z, [x0, z1.d, LSL #3] + rdffr p1.b + st1d {z1.d}, p0, [x1] + str p1, [x2] + ret +``` + +This harness for convenience intialises some data and checks the element at index 1, which should be 1. + +test.c +``` +#include <arm_sve.h> +#include <stdio.h> + +void asmtest(int64_t const * data, svint64_t * loaded, svbool_t * ffr); + +int main() { + const int64_t data[] = {42, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, + 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, + 22, 23, 24, 25, 26, 27, 28, 29, 30, 31}; + svint64_t loaded; + svbool_t ffr; + + asmtest(data, &loaded, &ffr); + + // Check value of element at index 1 + svuint64_t lanes = svindex_u64(0, 1); + svbool_t lane = svcmpeq_n_u64(svptrue_b64(), lanes, 1); + printf("%ld\n", svaddv_s64(lane, loaded)); +} +``` + +2. ```clang-15 -fuse-ld=lld -march=armv8-a+sve2 -target aarch64-unknown-linux-gnu -static *.c *.s -o svldffgathertest``` +3. ```qemu-aarch64 svldffgathertest``` - the value printed should be 1, but it can be seen that all values in the loaded vector are 42. +Additional information: +The above code was successfully tested on real SVE hardware. Normal gathers work fine in QEMU, as does a non-gather first-fault load. diff --git a/results/classifier/gemma3:27b/instruction/1613817 b/results/classifier/gemma3:27b/instruction/1613817 new file mode 100644 index 000000000..f631772b2 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1613817 @@ -0,0 +1,59 @@ + + + +x86: ret, lret and iret with noncanonical IP saves wrong IP on the exception stack + +This test program: + +# compile with: gcc -nostartfiles -nostdlib +_start: .globl _start + mov %ss,%eax + push %rax + push %rsp + pushf + mov %cs,%eax + push %rax + mov $0x1234567812345678,%rax + push %rax +//qemu bug: ip=1234567812345678, should be ip=0000000000400abc: + iretq +1: + jmp 1b + +should segfault on IRET instruction because return address on stack is invalid +(it is not canonical). And it does, both on native CPU and in qemu. +But there is a difference: on native CPU, it fails before instruction is executed, +IOW: saved IP points to the failed IRET: + +# strace -i ./bad_ip_in_iret +[00007fa609805d57] execve("./bad_ip_in_iret", ["./bad_ip_in_iret"], [/* 54 vars */]) = 0 +[00000000004000e7] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- + ^^^^^^^^^^^^^^^^-NOTE THIS +[????????????????] +++ killed by SIGSEGV (core dumped) +++ + + +In qemu, evidently instruction succeeds, and then emulated CPU throws an exception because fetching instructions from non-canonical addresses is not allowed: + +/ # strace -i ./bad_ip_in_iret +[000000000041a790] execve("./bad_ip_in_iret", ["./bad_ip_in_iret"], [/* 5 vars */]) = 0 +[1234567812345678] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- + ^^^^^^^^^^^^^^^^-NOTE THIS +[????????????????] +++ killed by SIGSEGV +++ +Segmentation fault + +Thus, the emulation is not the same as real CPU. + +This is not specific to IRET, the same happens with "far return" LRET, +and with ordinary RET instructions as well. +In qemu: + +/ # strace -i ./bad_ip_in_lret +[000000000041a790] execve("./bad_ip_in_lret", ["./bad_ip_in_lret"], [/* 5 vars */]) = 0 +[1234567812345678] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- +[????????????????] +++ killed by SIGSEGV +++ +Segmentation fault +/ # strace -i ./bad_ip_in_ret +[000000000041a790] execve("./bad_ip_in_ret", ["./bad_ip_in_ret"], [/* 5 vars */]) = 0 +[1234567812345678] --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} --- +[????????????????] +++ killed by SIGSEGV +++ +Segmentation fault \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1614348 b/results/classifier/gemma3:27b/instruction/1614348 new file mode 100644 index 000000000..c9442ce00 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1614348 @@ -0,0 +1,42 @@ + + + +qemu-arm core dumped for no entry symbol programe + +Hi qemu developers, + +Environment: +* Fedora 24 x86_64 +* qemu-arm version 2.6.92, Copyright (c) 2003-2008 Fabrice Bellard +* arm-linux-gnu-gcc 6.1.1 20160621 (Red Hat Cross 6.1.1-2) (GCC) target: arm-linux-gnueabi +* glibc-arm-linux-gnu-devel-2.23 + +very simple hello.c: + +#include <stdio.h> + +int main(int argc, char *argv[]) +{ + printf("Hello World\n"); + + return 0; +} + +arm-linux-gnu-gcc hello.c -I/usr/arm-linux-gnu/include -L/usr/arm-linux-gnu/lib -nostdlib -lc + +/usr/bin/arm-linux-gnu-ld: Warning: Cannot find entry symbol _start; defaulting to 00000000000101fc + +qemu-arm -L /usr/arm-linux-gnu ./a.out + +Hello World +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction + +But provided entry symbol: + +arm-linux-gnu-gcc hello.c -I/usr/arm-linux-gnu/include -L/usr/arm-linux-gnu/lib -nostdlib /usr/arm-linux-gnu/lib/crt1.o /usr/arm-linux-gnu/lib/crti.o /usr/arm-linux-gnu/lib/crtn.o -lc + +qemu-arm -L /usr/arm-linux-gnu ./a.out is able to work happily! + +Regards, +Leslie Zhai \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1620 b/results/classifier/gemma3:27b/instruction/1620 new file mode 100644 index 000000000..e286fd225 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1620 @@ -0,0 +1,97 @@ + + + +SME FMOPA outer product instruction gives incorrect result +Description of problem: +The SME outer product instructions operate on tiles of elements. In the +below example we are performing an outer product of a vector of 1.0 +by itself. This naturally should produce a matrix filled with 1.0 +values, however if we read the values of the tile and printf them we +instead observe 0.0 values. + +Without digging into the underlying QEMU code this appears to be a bug +in how elements are set based on the tile number, since the same code +using za0.s rather than za1.s correctly reports all 1.0 values as output +as expected. + +main.c +``` +#include <stdio.h> + +void foo(float *dst); + +int main() { + float dst[16]; + foo(dst); + + // This should print: + // >>> 1.000000 1.000000 1.000000 1.000000 + // >>> 1.000000 1.000000 1.000000 1.000000 + // >>> 1.000000 1.000000 1.000000 1.000000 + // >>> 1.000000 1.000000 1.000000 1.000000 + for (int i=0; i<4; ++i) { + printf(">>> "); + for (int j=0; j<4; ++j) { + printf("%lf ", (double)dst[i * 4 + j]); + } + printf("\n"); + } +} +``` + +foo.S +``` +.global foo +foo: + stp x29, x30, [sp, -80]! + mov x29, sp + stp d8, d9, [sp, 16] + stp d10, d11, [sp, 32] + stp d12, d13, [sp, 48] + stp d14, d15, [sp, 64] + + smstart + + ptrue p0.s, vl4 + fmov z0.s, #1.0 + + // An outer product of a vector of 1.0 by itself should be a matrix of 1.0. + // Note that we are using tile 1 here (za1.s) rather than tile 0. + zero {za} + fmopa za1.s, p0/m, p0/m, z0.s, z0.s + + // Read the first 4x4 sub-matrix of elements from tile 1: + // Note that za1h should be interchangable here. + mov w12, #0 + mova z0.s, p0/m, za1v.s[w12, #0] + mova z1.s, p0/m, za1v.s[w12, #1] + mova z2.s, p0/m, za1v.s[w12, #2] + mova z3.s, p0/m, za1v.s[w12, #3] + + // And store them to the input pointer (dst in the C code): + st1w {z0.s}, p0, [x0] + add x0, x0, #16 + st1w {z1.s}, p0, [x0] + add x0, x0, #16 + st1w {z2.s}, p0, [x0] + add x0, x0, #16 + st1w {z3.s}, p0, [x0] + + smstop + + ldp d8, d9, [sp, 16] + ldp d10, d11, [sp, 32] + ldp d12, d13, [sp, 48] + ldp d14, d15, [sp, 64] + ldp x29, x30, [sp], 80 + ret +``` +Steps to reproduce: +``` +$ clang -target aarch64-linux-gnu -march=armv9-a+sme test.c -O1 -static +$ ~/qemu/build/qemu-aarch64 ./a.out +>>> 0.000000 0.000000 0.000000 0.000000 +>>> 0.000000 0.000000 0.000000 0.000000 +>>> 0.000000 0.000000 0.000000 0.000000 +>>> 0.000000 0.000000 0.000000 0.000000 +``` diff --git a/results/classifier/gemma3:27b/instruction/1637 b/results/classifier/gemma3:27b/instruction/1637 new file mode 100644 index 000000000..75c917c47 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1637 @@ -0,0 +1,4 @@ + + + +Crash when executing `ucomiss` instructions emulating an x86-64 CPU on an AArch64 host diff --git a/results/classifier/gemma3:27b/instruction/1641637 b/results/classifier/gemma3:27b/instruction/1641637 new file mode 100644 index 000000000..82d651dca --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1641637 @@ -0,0 +1,716 @@ + + + +incorrect illegal SSE3 instructions reporting on x86_64 + +Hi all, we found 28 differently encoded illegal SSE3 instructions reporting on the most recent x86_64 user mode linux qemu (version 2.7.0). We believe these reporting should be incorrect because the same code can be executed on a real machine. The instructions are the following: + +pabsb %mm0, %mm1 +pabsb %xmm0, %xmm1 +pabsd %mm0, %mm1 +pabsd %xmm0, %xmm1 +pabsw %mm0, %mm1 +pabsw %xmm0, %xmm1 +phaddd %mm0, %mm1 +phaddd %xmm0, %xmm1 +phaddsw %mm0, %mm1 +phaddsw %xmm0, %xmm1 +phaddw %mm0, %mm1 +phaddw %xmm0, %xmm1 +phsubd %mm0, %mm1 +phsubd %xmm0, %xmm1 +phsubsw %mm0, %mm1 +phsubsw %xmm0, %xmm1 +phsubw %mm0, %mm1 +phsubw %xmm0, %xmm1 +pmaddubsw %mm0, %mm1 +pmaddubsw %xmm0, %xmm1 +pmulhrsw %mm0, %mm1 +pmulhrsw %xmm0, %xmm1 +psignb %mm0, %mm1 +psignb %xmm0, %xmm1 +psignd %mm0, %mm1 +psignd %xmm0, %xmm1 +psignw %mm0, %mm1 +psignw %xmm0, %xmm1 + +The following is the proof of code + +/********** Beginning of bug 1.c: pabsb %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("pabsb %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 1.c **********/ + + +/********** Beginning of bug 2.c: pabsb %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("pabsb %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 2.c **********/ + + +/********** Beginning of bug 3.c: pabsd %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("pabsd %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 3.c **********/ + + +/********** Beginning of bug 4.c: pabsd %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("pabsd %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 4.c **********/ + + +/********** Beginning of bug 5.c: pabsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("pabsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 5.c **********/ + + +/********** Beginning of bug 6.c: pabsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("pabsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 6.c **********/ + + +/********** Beginning of bug 7.c: phaddd %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phaddd %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 7.c **********/ + + +/********** Beginning of bug 8.c: phaddd %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phaddd %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 8.c **********/ + + +/********** Beginning of bug 9.c: phaddsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phaddsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 9.c **********/ + + +/********** Beginning of bug 10.c: phaddsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phaddsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 10.c **********/ + + +/********** Beginning of bug 11.c: phaddw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phaddw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 11.c **********/ + + +/********** Beginning of bug 12.c: phaddw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phaddw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 12.c **********/ + + +/********** Beginning of bug 13.c: phsubd %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phsubd %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 13.c **********/ + + +/********** Beginning of bug 14.c: phsubd %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phsubd %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 14.c **********/ + + +/********** Beginning of bug 15.c: phsubsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phsubsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 15.c **********/ + + +/********** Beginning of bug 16.c: phsubsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phsubsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 16.c **********/ + + +/********** Beginning of bug 17.c: phsubw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("phsubw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 17.c **********/ + + +/********** Beginning of bug 18.c: phsubw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("phsubw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 18.c **********/ + + +/********** Beginning of bug 19.c: pmaddubsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char i2[0x10]; +unsigned char i3[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i2)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i3)));; + asm("pmaddubsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 19.c **********/ + + +/********** Beginning of bug 20.c: pmaddubsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char i2[0x10]; +unsigned char i3[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i2)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i3)));; + asm("pmaddubsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 20.c **********/ + + +/********** Beginning of bug 21.c: pmulhrsw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("pmulhrsw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 21.c **********/ + + +/********** Beginning of bug 22.c: pmulhrsw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("pmulhrsw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 22.c **********/ + + +/********** Beginning of bug 23.c: psignb %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("psignb %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 23.c **********/ + + +/********** Beginning of bug 24.c: psignb %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("psignb %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 24.c **********/ + + +/********** Beginning of bug 25.c: psignd %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("psignd %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 25.c **********/ + + +/********** Beginning of bug 26.c: psignd %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("psignd %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 26.c **********/ + + +/********** Beginning of bug 27.c: psignw %mm0, %mm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movq (%%rdx), %%mm1\n"::"r"((char *)(i1)));; + asm("psignw %mm0, %mm1"); + asm("mov %0, %%rdx\n" + "movq %%mm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 27.c **********/ + + +/********** Beginning of bug 28.c: psignw %xmm0, %xmm1 **********/ + +int printf(const char *format, ...); +unsigned char i0[0x10]; +unsigned char i1[0x10]; +unsigned char o[0x10]; +int main() { + int k = 0; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm0\n"::"r"((char *)(i0)));; + asm("mov %0, %%rdx\n" + "movdqu (%%rdx), %%xmm1\n"::"r"((char *)(i1)));; + asm("psignw %xmm0, %xmm1"); + asm("mov %0, %%rdx\n" + "movdqu %%xmm1, (%%rdx)\n"::"r"((char *)(o)));; + for (k = 0; k < 0x10; k++) + printf("%02x", o[0x10 - 1 - k]); + printf("\n"); +} + +/********** End of bug 28.c **********/ + +For any of the above code, when compiled into x86-64 binary code with gcc, qemu reports the illegal instructions bug. However, these can be correctly executed on a real machine. For example, + +$ gcc 28.c -o 28 +$ qemu-x86_64 ./28 +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction +$ ./28 +00000000000000000000000000000000 + +Some information about the system: + +$ qemu-x86_64 --version +qemu-x86_64 version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers +$ uname -a +Linux cgos-System-Product-Name 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux +$ gcc --version +gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4 +Copyright (C) 2013 Free Software Foundation, Inc. +This is free software; see the source for copying conditions. There is NO +warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + + +Thanks! \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1642 b/results/classifier/gemma3:27b/instruction/1642 new file mode 100644 index 000000000..acf88a9a1 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1642 @@ -0,0 +1,25 @@ + + + +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/gemma3:27b/instruction/1701821 b/results/classifier/gemma3:27b/instruction/1701821 new file mode 100644 index 000000000..b144d8c9b --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1701821 @@ -0,0 +1,217 @@ + + + +floating-point operation bugs in qemu-sh4 + +When running the gnulib testsuite, I'm seeing test failures in the tests for libm functions + asinf + cbrtf + copysignf + coshf + expm1f + fabsf + floor + fmaf + ldexpf + logbf + round + roundf + sinhf + tanhf + +How to reproduce: +- Using gnulib, run ./gnulib-tool --create-testdir --dir=../testdir-math --single-configure asinf cbrtf copysignf coshf expm1f fabsf floor fma fmaf fmal ldexpf logbf round roundf sinhf tanhf +- Set environment variables for using qemu-sh4. +- cd testdir-math; mkdir build-sh4; cd build-sh4; ./configure --host=sh4-linux; make; make check + +Here are the failures (from the file testdir-math/build-sh4/gltests/test-suite.log): + + +FAIL: test-asinf +================ + +pc=0xf6751cdc sr=0x00000101 pr=0xf6758e86 fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf6751cd6 fpul=0x3f19999a +r0=0xf6751d88 r1=0x00000000 r2=0x00080000 r3=0x00000000 +r4=0xf6ffe21c r5=0xf6ffe230 r6=0xf6ffe2fc r7=0x00000000 +r8=0x3f19999a r9=0x3f19999a r10=0x00000000 r11=0x00000000 +r12=0xf67ab008 r13=0x00000000 r14=0x00000000 r15=0xf6ffe230 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-asinf (exit status: 1) + +FAIL: test-cbrtf +================ + +pc=0x00400980 sr=0x00000001 pr=0x00400684 fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0x00400960 fpul=0x00000000 +r0=0x00400ae8 r1=0x00412070 r2=0x3f19999a r3=0xf6ffe2c0 +r4=0x00000001 r5=0xf6ffe2f4 r6=0xf6ffe2fc r7=0x00000000 +r8=0x00412064 r9=0x00400960 r10=0x00000000 r11=0x00000000 +r12=0xf671dc58 r13=0x00000000 r14=0x00000000 r15=0xf6ffe21c +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-cbrtf (exit status: 1) + +FAIL: test-copysignf +==================== + +pc=0x004004ce sr=0x00000001 pr=0xf668d28c fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf6674678 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0x004004d2 fpul=0x00000000 +r0=0x80000000 r1=0x3f4ccccd r2=0xf6674284 r3=0xf6ffe2b0 +r4=0x00000001 r5=0xf6ffe2e4 r6=0xf6ffe2ec r7=0x00000000 +r8=0x00411088 r9=0x00411084 r10=0x00000000 r11=0x00000000 +r12=0xf67a8c58 r13=0x00000000 r14=0x00000000 r15=0xf6ffe240 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +in conditional delay slot (delayed_pc=0x004004d2) +Unhandled trap: 0x1a0 +FAIL test-copysignf (exit status: 1) + +FAIL: test-coshf +================ + +pc=0xf675223a sr=0x00000101 pr=0xf675223c fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf675231c fpul=0x3f19999a +r0=0x3f19999a r1=0x3f19999a r2=0x000000e0 r3=0xf6ffe2c0 +r4=0x00000001 r5=0xf6ffe2f4 r6=0xf6ffe2fc r7=0x00000000 +r8=0x00400734 r9=0x00000000 r10=0x00000000 r11=0x00000000 +r12=0xf67ab008 r13=0x00000000 r14=0x00000000 r15=0xf6ffe240 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +in delay slot (delayed_pc=0xf675231c) +Unhandled trap: 0x1a0 +FAIL test-coshf (exit status: 1) + +FAIL: test-expm1f +================= + +pc=0xf6757e08 sr=0x00000000 pr=0x004005ce fpscr=0x00081000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf6757dfe fpul=0x00000000 +r0=0xf6757fb0 r1=0x00001000 r2=0x00080000 r3=0x3eb17218 +r4=0x00000001 r5=0xf6ffe2f4 r6=0xf6ffe2fc r7=0x00000000 +r8=0x00400514 r9=0x00000064 r10=0x00400514 r11=0x00000000 +r12=0xf67ab008 r13=0x00000000 r14=0x00000000 r15=0xf6ffe234 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-expm1f (exit status: 1) + +FAIL: test-fabsf +================ + +pc=0x00400504 sr=0x00000001 pr=0xf660228c fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0x004004ec fpul=0x00000000 +r0=0x00400640 r1=0x00412074 r2=0x00000000 r3=0x00412078 +r4=0x00000001 r5=0xf6ffe2f4 r6=0xf6ffe2fc r7=0x00080000 +r8=0x004007ac r9=0x00000000 r10=0x00000000 r11=0x00000000 +r12=0xf671dc58 r13=0x00000000 r14=0x00000000 r15=0xf6ffe260 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-fabsf (exit status: 1) + +FAIL: test-floor2 +================= + +../../gltests/test-floor2.c:130: assertion 'correct_result_p (x, reference)' failed +qemu: uncaught target signal 6 (Aborted) - core dumped +FAIL test-floor2 (exit status: 134) + +FAIL: test-fmaf2 +================ + +pc=0xf675f5ac sr=0x00000101 pr=0xf675f5a6 fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf675f5a6 fpul=0x01800000 +r0=0xf675f4a4 r1=0x000065b0 r2=0x00080000 r3=0x3f800000 +r4=0x01800000 r5=0x00000000 r6=0xffffffe9 r7=0x7f800000 +r8=0xffffff6b r9=0xf6ffe1e4 r10=0xf6ffe1e8 r11=0xffffff6b +r12=0xf67ab008 r13=0xf6ffe1d8 r14=0x004004dc r15=0xf6ffe18c +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-fmaf2 (exit status: 1) + +FAIL: test-ldexpf +================= + +pc=0xf669efa0 sr=0x00000001 pr=0xf669ef9a fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf6674678 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf669ef9a fpul=0x3f99999a +r0=0xfffffdc6 r1=0x000c9d70 r2=0x00080000 r3=0x3f19999a +r4=0x0019999a r5=0x3f19999a r6=0xffffffe9 r7=0x7f800000 +r8=0x00000001 r9=0x0040041c r10=0xf6ffe23c r11=0x00000000 +r12=0xf67a8c58 r13=0x00000000 r14=0x00000000 r15=0xf6ffe218 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-ldexpf (exit status: 1) + +FAIL: test-logbf +================ + +pc=0xf675842c sr=0x00000001 pr=0x00400664 fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf6758422 fpul=0x00000000 +r0=0xf6758480 r1=0x00000000 r2=0x00080000 r3=0x00080000 +r4=0x00000000 r5=0xf6ffe2f4 r6=0xf6ffe2fc r7=0x00000000 +r8=0xf6ffe24c r9=0x0040054c r10=0x00000000 r11=0x00000000 +r12=0xf671dc58 r13=0x00000000 r14=0x00000000 r15=0xf6ffe244 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-logbf (exit status: 1) + +FAIL: test-round2 +================= + +FAIL test-round2 (exit status: 1) + +FAIL: test-roundf2 +================== + +FAIL test-roundf2 (exit status: 1) + +FAIL: test-sinhf +================ + +pc=0xf675581c sr=0x00000101 pr=0xf675a784 fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf6755858 fpul=0x3f19999a +r0=0xf6755930 r1=0x317fffff r2=0x3f19999a r3=0xf6ffe2c0 +r4=0x00000001 r5=0xf6ffe2f4 r6=0xf6ffe2fc r7=0x00000000 +r8=0x3f19999a r9=0x00000000 r10=0x00000000 r11=0x00000000 +r12=0xf67ab008 r13=0x00000000 r14=0x00000000 r15=0xf6ffe238 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +in conditional delay slot (delayed_pc=0xf6755858) +Unhandled trap: 0x1a0 +FAIL test-sinhf (exit status: 1) + +FAIL: test-tanhf +================ + +pc=0xf6758ca4 sr=0x00000100 pr=0x0040057c fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf65e98e8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf6758c9a fpul=0x3f19999a +r0=0xf6758d00 r1=0x00000000 r2=0x00080000 r3=0xf6ffe2c0 +r4=0x00000001 r5=0xf6ffe2f4 r6=0xf6ffe2fc r7=0x00000000 +r8=0x3f19999a r9=0x00000000 r10=0x00000000 r11=0x00000000 +r12=0xf67ab008 r13=0x00000000 r14=0x00000000 r15=0xf6ffe254 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +Unhandled trap: 0x180 +FAIL test-tanhf (exit status: 1) + + +I don't have access to sh4 hardware, so I cannot provide this as a comparison point. +But most of the test failures don't look like "merely" a wrong computation by glibc. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1713066 b/results/classifier/gemma3:27b/instruction/1713066 new file mode 100644 index 000000000..dc59a9d52 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1713066 @@ -0,0 +1,22 @@ + + + +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/gemma3:27b/instruction/1722 b/results/classifier/gemma3:27b/instruction/1722 new file mode 100644 index 000000000..c35957aa5 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1722 @@ -0,0 +1,90 @@ + + + +qemu-mipsn32: Illegal Instruction at `exts` instruction +Description of problem: +Run with the command above, I got this error: + +``` +qemu-mipsn32 run +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction (core dumped) +``` + +I then tried to debug the program with qemu option `-g 1234` and know that + +``` +$ gdb-multiarch run +... + +pwndbg> target remote 0:1234 +... + +pwndbg> c +Continuing. + +Program received signal SIGILL, Illegal instruction. +0x3f7d2434 in ?? () from /lib32/ld.so.1 +warning: GDB can't find the start of the function at 0x3f7d2434. +x/10i + +pwndbg> x/10i $pc +=> 0x3f7d2434: 0x7047f03a + 0x3f7d2438: lui a3,0x7000 + 0x3f7d243c: ori a3,a3,0x5e + 0x3f7d2440: b 0x3f7d241c + 0x3f7d2444: subu v0,a3,v0 + 0x3f7d2448: sltiu a7,a3,-3 + 0x3f7d244c: bnezl a7,0x3f7d246c + 0x3f7d2450: subu a3,a4,v0 + 0x3f7d2454: addiu a3,a3,1 + 0x3f7d2458: li v0,-4 +``` + +So I know the problem is in libc32/ld.so.1. When I dissasemble that file and look at offset 0x4434, it's an `exts` instruction as below: + +``` +$ file /lib32/ld.so.1 +/lib32/ld-2.15.so: ELF 32-bit MSB shared object, MIPS, N32 MIPS64 rel2 version 1 (SYSV), dynamically linked, stripped + +$ ./mips64-n32--glibc--stable-2022.08-1/bin/mips64-buildroot-linux-gnu-objdump -d /lib32/ld.so.1 | less + ... + 4434: 7047f03a exts a3,v0,0x0,0x1e + 4438: 3c077000 lui a3,0x7000 + 443c: 34e7005e ori a3,a3,0x5e + 4440: 1000fff6 b 441c <GLIBC_2.0@@GLIBC_2.0+0x441c> + 4444: 00e21023 subu v0,a3,v0 + 4448: 2cebfffd sltiu a7,a3,-3 + 444c: 55600007 bnezl a7,446c <GLIBC_2.0@@GLIBC_2.0+0x446c> + 4450: 01023823 subu a3,a4,v0 + 4454: 24e70001 addiu a3,a3,1 + 4458: 2402fffc li v0,-4 +``` +Steps to reproduce: +1. Download toolchain of mips64-n32 on toolchains.bootlin.com [here](https://toolchains.bootlin.com/releases_mips64-n32.html) +2. Write this c code to file `run.c`: + +```c +#include <stdio.h> + +int main(){ + puts("hello world"); + while (1); +} +``` + +3. Compile file run.c with downloaded toolchain: + +``` +mips64-n32--glibc--stable-2022.08-1/bin/mips64-buildroot-linux-gnu-gcc run.c -o run +``` + +> Step 1, 2 and 3 can be skip if you download the attached `run` file. + +4. Download the attached ld +5. Make new dir at `/lib32` and move the file ld to `/lib32` +6. Run command `qemu-mipsn32 run` +Additional information: +[ld-2.15.so](/uploads/95f4da26e42d43d39aa2350670134bb5/ld-2.15.so) + +[run](/uploads/01be57442009a75cf2f59cbcf53474f4/run) diff --git a/results/classifier/gemma3:27b/instruction/1724485 b/results/classifier/gemma3:27b/instruction/1724485 new file mode 100644 index 000000000..6c668c40d --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1724485 @@ -0,0 +1,21 @@ + + + +Invalid assertion in arm_read_memory_func + +Hi, + +I think there is an invalid assertion in arm_read_memory_func: +assert(info->endian == BFD_ENDIAN_LITTLE) + +I face it in the following use case: target armeb-linux (I use qemu user mode), -d in_asm -cpu any. + +At some point during program startup, glibc's _dl_new_object calls strlen, which is written in thumb2 mode (armv6t2). So print_insn_arm() calls arm_read_memory_func() with length==2, and info->flags == INSN_ARM_BE32, and the assert is false. + +If I remove the assert, execution continues OK. + +With the assert, I get the error message from the assert, and qemu then stalls. + +Can you confirm the assert can be removed? Or if not, explain me how to avoid/fix the subsequent qemu stall? + +Thanks \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1727737 b/results/classifier/gemma3:27b/instruction/1727737 new file mode 100644 index 000000000..9b47ff8e2 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1727737 @@ -0,0 +1,28 @@ + + + +qemu-arm stalls on a GCC sanitizer test since qemu-2.7 + +Hi, + +I have noticed that several GCC/sanitizer tests fail with timeout when executed under QEMU. + +After a bit of investigation, I have noticed that this worked with qemu-2.7, and started failing with qemu-2.8, and still fails with qemu-2.10.1 + +I'm attaching a tarball containing: +alloca_instruments_all_paddings.exe : the testcase, and the needed libs: +lib/librt.so.1 +lib/libdl.so.2 +lib/ld-linux-armhf.so.3 +lib/libasan.so.5 +lib/libc.so.6 +lib/libgcc_s.so.1 +lib/libpthread.so.0 +lib/libm.so.6 + +To reproduce the problem: +$ qemu-arm -cpu any -R 0 -L $PWD $PWD/alloca_instruments_all_paddings.exe +returns in less than a second with qemu-2.7, and never with qemu-2.8 + +Using -d in_asm suggests that the program "almost" completes and qemu seems to stall on: +0x40b6eb44: e08f4004 add r4, pc, r4 \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1736 b/results/classifier/gemma3:27b/instruction/1736 new file mode 100644 index 000000000..4b20e2446 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1736 @@ -0,0 +1,70 @@ + + + +Invalid guest addr in debug output +Description of problem: +When using QEMU 7.1.0 the log file for the first translation block (not starting at 0) looks like this: +(Note the `guest addr 0x00010000`) +``` +IN: +0x00010000: e1a00000 mov r0, r0 +0x00010004: e1a00000 mov r0, r0 +0x00010008: e1a00000 mov r0, r0 +0x0001000c: e1a00000 mov r0, r0 +0x00010010: e1a00000 mov r0, r0 +0x00010014: e1a00000 mov r0, r0 +0x00010018: e1a00000 mov r0, r0 +0x0001001c: e1a00000 mov r0, r0 +0x00010020: ea000005 b #0x1003c + +OUT: [size=47] + -- guest addr 0x00010000 + tb prologue +0x7f95a8000300: 8b 5d f0 movl -0x10(%rbp), %ebx +0x7f95a8000303: 85 db testl %ebx, %ebx +0x7f95a8000305: 0f 8c 18 00 00 00 jl 0x7f95a8000323 + -- guest addr 0x00010020 +0x7f95a800030b: e9 00 00 00 00 jmp 0x7f95a8000310 +0x7f95a8000310: c7 45 3c 3c 00 01 00 movl $0x1003c, 0x3c(%rbp) +0x7f95a8000317: 48 8d 05 22 ff ff ff leaq -0xde(%rip), %rax +0x7f95a800031e: e9 f5 fc ff ff jmp 0x7f95a8000018 +0x7f95a8000323: 48 8d 05 19 ff ff ff leaq -0xe7(%rip), %rax +0x7f95a800032a: e9 e9 fc ff ff jmp 0x7f95a8000018 +``` + +For QEMU 7.2.0 and higher: +(Note the `guest addr` is only the page offset.) +``` +Trace 0: 0x7fe434000100 [00000400/00000000/00000020/ff200000] +---------------- +IN: +0x00010000: e1a00000 mov r0, r0 +0x00010004: e1a00000 mov r0, r0 +0x00010008: e1a00000 mov r0, r0 +0x0001000c: e1a00000 mov r0, r0 +0x00010010: e1a00000 mov r0, r0 +0x00010014: e1a00000 mov r0, r0 +0x00010018: e1a00000 mov r0, r0 +0x0001001c: e1a00000 mov r0, r0 +0x00010020: ea000005 b #0x1003c + +OUT: [size=52] + -- guest addr 0x00000000 + tb prologue +0x7fe434000340: 8b 5d f0 movl -0x10(%rbp), %ebx +0x7fe434000343: 85 db testl %ebx, %ebx +0x7fe434000345: 0f 8c 1d 00 00 00 jl 0x7fe434000368 + -- guest addr 0x00000020 +0x7fe43400034b: 8b 5d 3c movl 0x3c(%rbp), %ebx +0x7fe43400034e: 83 c3 3c addl $0x3c, %ebx +0x7fe434000351: 89 5d 3c movl %ebx, 0x3c(%rbp) +0x7fe434000354: 66 66 90 nop +0x7fe434000357: e9 00 00 00 00 jmp 0x7fe43400035c +0x7fe43400035c: 48 8d 05 1d ff ff ff leaq -0xe3(%rip), %rax +0x7fe434000363: e9 b0 fc ff ff jmp 0x7fe434000018 +0x7fe434000368: 48 8d 05 14 ff ff ff leaq -0xec(%rip), %rax +0x7fe43400036f: e9 a4 fc ff ff jmp 0x7fe434000018 +``` +Steps to reproduce: +1. Run the provided command line for any kernel / system image. (likely other architectures are affected as well) +2. Look into the debug log. +Additional information: +While looking if this was already reported I found #1528 and #1697 which could potentially caused by this. It might as well be just an oversight in the debug output. diff --git a/results/classifier/gemma3:27b/instruction/1737 b/results/classifier/gemma3:27b/instruction/1737 new file mode 100644 index 000000000..9ee7e33cc --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1737 @@ -0,0 +1,52 @@ + + + +qemu-aarch64: Incorrect result for ssra instruction when using vector lengths of 1024-bit or higher. +Description of problem: +``` +#include <arm_sve.h> +#include <stdio.h> + +#define SZ 32 + +int main(int argc, char* argv[]) { + svbool_t pg = svptrue_b64(); + uint64_t VL = svcntd(); + + fprintf(stderr, "One SVE vector can hold %li uint64_ts\n", VL); + + int64_t sr[SZ], sx[SZ], sy[SZ]; + uint64_t ur[SZ], ux[SZ], uy[SZ]; + + for (uint64_t i = 0; i < SZ; ++i) { + sx[i] = ux[i] = 0; + sy[i] = uy[i] = 1024; + } + + for (uint64_t i = 0; i < SZ; i+=VL) { + fprintf(stderr, "Processing elements %li - %li\n", i, i + VL - 1); + + svint64_t SX = svld1(pg, sx + i); + svint64_t SY = svld1(pg, sy + i); + svint64_t SR = svsra(SX, SY, 4); + svst1(pg, sr + i, SR); + + svuint64_t UX = svld1(pg, ux + i); + svuint64_t UY = svld1(pg, uy + i); + svuint64_t UR = svsra(UX, UY, 4); + svst1(pg, ur + i, UR); + } + + for (uint64_t i = 0; i < SZ; ++i) { + fprintf(stderr, "sr[%li]=%li, ur[%li]\n", i, sr[i], ur[i]); + } + + return 0; +} +``` +Steps to reproduce: +1. Build the above C source using "gcc -march=armv9-a -O1 ssra.c", can also use clang. +2. Run with "qemu-aarch64 -cpu max,sve-default-vector-length=64 ./a.out" and you'll see the expected result of 64 (signed and unsigned) +3. Run with "qemu-aarch64 -cpu max,sve-default-vector-length=128 ./a.out" and you'll see the expected result of 64 for unsigned but the signed result is 0. This suggests the emulation of SVE2 ssra instruction is incorrect for this and bigger vector lengths. +Additional information: + diff --git a/results/classifier/gemma3:27b/instruction/1738434 b/results/classifier/gemma3:27b/instruction/1738434 new file mode 100644 index 000000000..3a255ebc4 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1738434 @@ -0,0 +1,31 @@ + + + +CALL FWORD PTR [ESP] handled incorrectly + +To keep the story short, this 32-bit code crashes on 64-bit Windows whereas it works fine on real system and VMware: + + push 33h + push offset _far_call + call fword ptr[esp] + jmp _ret +_far_call: + retf +_ret: + +32-bit code running under WoW64 on 64-bit Windows has the ability to switch to the 64-bit mode via so called "Heaven's gate". In order to do that you have to make a far call/jmp by 0x33 selector how the code snippet above shows. QEMU throws an access violation exception whereas the code snippet runs with no problems on real CPU and VMware. By the way, this code works fine under QEMU, I hope it gives you a hint where to look: + + push 23h + push offset _far_call + call fword ptr[esp] + jmp _ret +_far_call: + retf +_ret: + +0x23 is a default 32-bit selector for 32-bit processes running under WoW64. + +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 \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1748296 b/results/classifier/gemma3:27b/instruction/1748296 new file mode 100644 index 000000000..73411abc8 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1748296 @@ -0,0 +1,28 @@ + + + +TCG throws Invalid Opcode when executing x86 BMI shlx instruction + +I am unable to use BMI in my project when running under TCG. I narrowed the problem down to incorrect instruction decoding for BMI instructions (which have a 2 byte VEX prefix). The gen_sse function in translate.c reaches the goto label do_0f_38_fx, but b does not equal 0x1f7, 0x2f7, or 0x3f7, so the switch takes the default path and raises an invalid opcode exception. + +The code executes correctly and passes the test under KVM. + +I have created a complete repro here: https://github.com/doug65536/qemu-bmibug + +The makefile has the following utility targets: + +debug-kvm: Build and run the VM using KVM and wait for gdbstub attach + +run: Run the test case with TCG, make fails if the test fails. (It will fail) + +run-kvm: Run the test case with KVM, make fails if the test fails. (It will succeed) + +debug: Build and run the VM with TCG and wait for GDB attach + +attach-gdb: Run GDB and attach to KVM gdbstub + +The VM runs with -cpu max. CPUID reports support for BMI, BMI2, and ABM. + +You can quickly verify the issue by executing `make run-kvm` to confirm that KVM passes, then `make run` to confirm that TCG fails. + +I believe the bug affects other BMI, BMI2, and ABM instructions, but I have only completely verified incorrect execution of SHLX. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1751422 b/results/classifier/gemma3:27b/instruction/1751422 new file mode 100644 index 000000000..81442661b --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1751422 @@ -0,0 +1,7 @@ + + + +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. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1751494 b/results/classifier/gemma3:27b/instruction/1751494 new file mode 100644 index 000000000..2e2e48a44 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1751494 @@ -0,0 +1,38 @@ +instruction: 0.878 +graphic: 0.676 +assembly: 0.586 +device: 0.585 +semantic: 0.580 +mistranslation: 0.510 +other: 0.502 +socket: 0.335 +network: 0.320 +vnc: 0.279 +boot: 0.154 +KVM: 0.051 + +tcg-target.inc.c:3495:no such instruction: `xgetbv' + +While building QEMU on Mac OS 10.6.8 I saw this error message: +tag-target.inc.c:3495:no such instruction: `xgetbv' +In the file tcg/i386/tcg-target.inc.c at line 3495 is where the issue is located. This is the problem code: +asm ("xgetbv" : "=a" (xcrl), "=d" (xcrh) : "c" (0)); + +https://github.com/asmjit/asmjit/issues/78 +According to the above link, another project also experienced this problem on Mac OS X. The fix was to replace the name of the instruction with the encoded form '.byte 0x0F, 0x01, 0xd0'. + +Host info: +Mac OS 10.6.8 +GCC 5.2.0 + +Additional information: +This may be a gcc issue. I have compiled QEMU on Mac OS 10.12 and didn't experience any issues. The compiler used was Apple's clang. + +The exact commit that causes this problem is this: + +commit 770c2fc7bb70804ae9869995fd02dadd6d7656ac +tcg/i386: Add vector operations + +This has been fixed here: +https://git.qemu.org/?p=qemu.git;a=commitdiff;h=1019242af11400252 + diff --git a/results/classifier/gemma3:27b/instruction/1756927 b/results/classifier/gemma3:27b/instruction/1756927 new file mode 100644 index 000000000..7ad0a2c7f --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1756927 @@ -0,0 +1,21 @@ + + + +ARMv7 LPAE: IFSR doesn't have the LPAE bit in case of BKPT + +When a user application triggers a 'bkpt' instruction while LPAE is used, the bit [9] of IFSR is not correctly set during the prefetch abort exception. + +You'll find attached a minimal example to reproduce the issue (just run 'make all'). +The output I get is: + +supervisor +user +prefetch +short-descriptor + +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 \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1761401 b/results/classifier/gemma3:27b/instruction/1761401 new file mode 100644 index 000000000..fc9257bd5 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1761401 @@ -0,0 +1,13 @@ + + + +ARM/Neon: vcvt rounding error + +Hello, + +While using QEMU commit 47d3b60858d90ac8a0cc3a72af7f95c96781125a (March 28, 2018), I've noticed failures in one of the GCC ARM/Neon tests. The test passes on hardware, and with QEMU-2.11.0, so it looks like a recent regression. + +The test builds a vector of 4 float32 with "125.9" as value, then converts them to 4 uint32_t. +The expected result is 125, but we get 126 instead. + +Maybe it's just a matter of default rounding mode? \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1771 b/results/classifier/gemma3:27b/instruction/1771 new file mode 100644 index 000000000..818e547e8 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1771 @@ -0,0 +1,36 @@ + + + +Missing CASA instruction handling for SPARC qemu-user +Description of problem: +Qemu-sparc does not handle the CASA instruction, even if the selected CPU (in this case, LEON3) support it. +Steps to reproduce: +1. Launch a program that use CASA instruction (any program, also "ls" on a recent glibc [>=2.31]) +2. qemu-sparc will raise "Illegal instruction" +Additional information: +The following patch remove the missing handling, but it needs asi load/store that is not implemented for sparc32 user-space. + +``` +diff -urp qemu-20230327.orig/target/sparc/translate.c qemu-20230327/target/sparc/translate.c +--- qemu-20230327.orig/target/sparc/translate.c 2023-03-27 15:41:42.000000000 +0200 ++++ qemu-20230327/target/sparc/translate.c 2023-04-01 15:24:18.293176711 +0200 +@@ -5521,7 +5522,7 @@ static void disas_sparc_insn(DisasContex + case 0x37: /* stdc */ + goto ncp_insn; + #endif +-#if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64) ++//#if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64) + case 0x3c: /* V9 or LEON3 casa */ + #ifndef TARGET_SPARC64 + CHECK_IU_FEATURE(dc, CASA); +@@ -5529,8 +5530,8 @@ static void disas_sparc_insn(DisasContex + rs2 = GET_FIELD(insn, 27, 31); + cpu_src2 = gen_load_gpr(dc, rs2); + gen_cas_asi(dc, cpu_addr, cpu_src2, insn, rd); ++//#endif + break; +-#endif + default: + goto illegal_insn; + } +``` diff --git a/results/classifier/gemma3:27b/instruction/1779 b/results/classifier/gemma3:27b/instruction/1779 new file mode 100644 index 000000000..3264198e0 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1779 @@ -0,0 +1,33 @@ + + + +PowerPC AltiVec source vector subnormal values are not flushed to zero +Description of problem: +AltiVec specifies that source and result vectors are flushed to zero (in NJ mode). Only result vectors are flushed to zero. +Steps to reproduce: +1. Compile the attached Rust program (e.g. `cargo +nightly build --target powerpc-unknown-linux-gnu`) +2. Run the program and expect assertions to pass. +3. See assertions fail. +Additional information: +See the offending Rust program: + +``` +#![feature(stdsimd, powerpc_target_feature)] + +use std::arch::powerpc::*; + +#[target_feature(enable = "altivec")] +unsafe fn add(x: f32, y: f32) -> f32 { + let array: [f32; 4] = unsafe { std::mem::transmute(vec_add(vec_splats(x), vec_splats(y))) }; + array[0] +} + +pub fn main() { + let result = unsafe { add(-1.0857398e-38, 0.) }; + assert_eq!(result, 0.); + + // if the input is flushed, the result will be +0 + // if only the output is flushed, the result is -0 + assert!(result.is_sign_positive()); +} +``` diff --git a/results/classifier/gemma3:27b/instruction/1780 b/results/classifier/gemma3:27b/instruction/1780 new file mode 100644 index 000000000..dd71873ae --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1780 @@ -0,0 +1,20 @@ + + + +PowerPC mishandles xscmpudp instruction +Description of problem: +xscmpudp instruction is mishandled +Steps to reproduce: +1. Compile the attached program with VSX (e.g. `RUSTFLAGS=-Ctarget-feature=+vsx cargo build --target=powerpc64-unknown-linux-gnu`) +2. Run the program and expect assertions to pass. +3. See assertions fail. +Additional information: +When VSX is disabled, the `fcmpu` instruction is emitted instead (and handled properly). See the offending program: +``` +pub fn main() { + use std::hint::black_box; + assert!(black_box(f64::NAN) + .clamp(black_box(0f64), black_box(0f64)) + .is_nan()); +} +``` diff --git a/results/classifier/gemma3:27b/instruction/1781281 b/results/classifier/gemma3:27b/instruction/1781281 new file mode 100644 index 000000000..d358dc7b7 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1781281 @@ -0,0 +1,31 @@ + + + +qemu-ppc64le uncaught target signal 4 (Illegal instruction) + +qemu-ppc64le version 2.12.0 +host machine: x86_64 Arch Linux + +I'm currently working on VSX support in libVPX, I'm using qemu to test, on line 723 of vpx_dsp/ppc/loopfilter_vsx.c, when I change the vec_sub to vec_subs I get: + +qemu: uncaught target signal 4 (Illegal instruction) - core dumped + +Thread 1 "qemu-ppc64le" received signal SIGILL, Illegal instruction. +0x00007ffff66d1bf6 in sigsuspend () from /usr/lib/libc.so.6 +(gdb) bt +#0 0x00007ffff66d1bf6 in sigsuspend () from /usr/lib/libc.so.6 +#1 0x000055555567ee68 in ?? () +#2 0x000055555567fd18 in ?? () +#3 0x00005555556805ef in process_pending_signals () +#4 0x0000555555661e69 in cpu_loop () +#5 0x000055555561fd72 in main () + +This can be reproduced by downloading this patch (patchset 1): + +https://chromium-review.googlesource.com/c/webm/libvpx/+/1134034 + +and running + +qemu-ppc64le -L /home/ltrudeau/x-tools/powerpc64le-unknown-linux-gnu/powerpc64le-unknown-linux-gnu/sysroot/ ./test_libvpx --gtest_also_run_disabled_tests "--gtest_filter=VSX/*Loop*/*" + +I don't observe any issues when running the code on a POWER9 machine. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1785734 b/results/classifier/gemma3:27b/instruction/1785734 new file mode 100644 index 000000000..1346c5a11 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1785734 @@ -0,0 +1,78 @@ + + + +movdqu partial write at page boundary + +In TCG mode, when a 16-byte write instruction (such as movdqu) is executed at a page boundary and causes a page fault, a partial write is executed in the first page. See the attached code for an example. + +Tested on the qemu-3.0.0-rc1 release. + + +% gcc -m32 qemu-bug2.c && ./a.out && echo && qemu-i386 ./a.out +*(0x70000ff8+ 0) = aa +*(0x70000ff8+ 1) = aa +*(0x70000ff8+ 2) = aa +*(0x70000ff8+ 3) = aa +*(0x70000ff8+ 4) = aa +*(0x70000ff8+ 5) = aa +*(0x70000ff8+ 6) = aa +*(0x70000ff8+ 7) = aa +*(0x70000ff8+ 8) = 55 +*(0x70000ff8+ 9) = 55 +*(0x70000ff8+10) = 55 +*(0x70000ff8+11) = 55 +*(0x70000ff8+12) = 55 +*(0x70000ff8+13) = 55 +*(0x70000ff8+14) = 55 +*(0x70000ff8+15) = 55 +page fault: addr=0x70001000 err=0x7 +*(0x70000ff8+ 0) = aa +*(0x70000ff8+ 1) = aa +*(0x70000ff8+ 2) = aa +*(0x70000ff8+ 3) = aa +*(0x70000ff8+ 4) = aa +*(0x70000ff8+ 5) = aa +*(0x70000ff8+ 6) = aa +*(0x70000ff8+ 7) = aa +*(0x70000ff8+ 8) = 55 +*(0x70000ff8+ 9) = 55 +*(0x70000ff8+10) = 55 +*(0x70000ff8+11) = 55 +*(0x70000ff8+12) = 55 +*(0x70000ff8+13) = 55 +*(0x70000ff8+14) = 55 +*(0x70000ff8+15) = 55 + +*(0x70000ff8+ 0) = aa +*(0x70000ff8+ 1) = aa +*(0x70000ff8+ 2) = aa +*(0x70000ff8+ 3) = aa +*(0x70000ff8+ 4) = aa +*(0x70000ff8+ 5) = aa +*(0x70000ff8+ 6) = aa +*(0x70000ff8+ 7) = aa +*(0x70000ff8+ 8) = 55 +*(0x70000ff8+ 9) = 55 +*(0x70000ff8+10) = 55 +*(0x70000ff8+11) = 55 +*(0x70000ff8+12) = 55 +*(0x70000ff8+13) = 55 +*(0x70000ff8+14) = 55 +*(0x70000ff8+15) = 55 +page fault: addr=0x70001000 err=0x6 +*(0x70000ff8+ 0) = 77 +*(0x70000ff8+ 1) = 66 +*(0x70000ff8+ 2) = 55 +*(0x70000ff8+ 3) = 44 +*(0x70000ff8+ 4) = 33 +*(0x70000ff8+ 5) = 22 +*(0x70000ff8+ 6) = 11 +*(0x70000ff8+ 7) = 0 +*(0x70000ff8+ 8) = 55 +*(0x70000ff8+ 9) = 55 +*(0x70000ff8+10) = 55 +*(0x70000ff8+11) = 55 +*(0x70000ff8+12) = 55 +*(0x70000ff8+13) = 55 +*(0x70000ff8+14) = 55 +*(0x70000ff8+15) = 55 \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1790 b/results/classifier/gemma3:27b/instruction/1790 new file mode 100644 index 000000000..5d081e59e --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1790 @@ -0,0 +1,32 @@ + + + +[AARCH64] STGP instruction is not writing the value of the second register to memory +Description of problem: +My application is built with Clang 16 and the option -fsanitize=memtag-stack. +It means the the MTE protection is activated for the stack. +The local variables are tagged and the compiler is often using the STGP instruction "Store Allocation Tag and Pair of registers" in order to transfer the value of two 64-bit registers to memory. +The following instruction was not working as expected: + 18004: 69000895 stgp x21, x2, [x4] +The value of the second register x2 is not transferred to the memory. +Only x21 is written. + +I think that the issue is in trans_STGP(). +We don't call finalize_memop_pair() like we do for in the general trans_STP(). + +``` +diff --git a/target/arm/tcg/translate-a64.c b/target/arm/tcg/translate-a64.c +index 7d0c8f79a7..f599f3e136 100644 +--- a/target/arm/tcg/translate-a64.c ++++ b/target/arm/tcg/translate-a64.c +@@ -3034,6 +3034,8 @@ static bool trans_STGP(DisasContext *s, arg_ldstpair *a) + + tcg_rt = cpu_reg(s, a->rt); + tcg_rt2 = cpu_reg(s, a->rt2); ++ mop = a->sz + 1; ++ mop = finalize_memop_pair(s, mop); + + assert(a->sz == 3); +``` + +With this fix, my OS (Kinibi) is now able to boot. diff --git a/results/classifier/gemma3:27b/instruction/1793119 b/results/classifier/gemma3:27b/instruction/1793119 new file mode 100644 index 000000000..9990b2c6d --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1793119 @@ -0,0 +1,32 @@ + + + +Wrong floating-point emulation on AArch64 with FPCR set to zero + +On AArch64, with FPCR set to Zero (i.e., FPU set to IEEE-754 compliant mode), floating-point emulation does not produce the same results as real hardware (e.g., Raspberry Pi 3 with AArch64 Linux). + +I attached a sample that reproduces the issue. It divides `x` by `y` and puts the result in `r`. The expected result of the operation is `q`. + +Output on real hardware: +========================================================= +fpcr = 0x07000000. +x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x7ff0000000000000. q = 0x43300fde9cbcf023. +fpcr = 0x00000000. +x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x43300fde9cbcf023. q = 0x43300fde9cbcf023. +========================================================= + +Notice that after setting FPCR to zero, `r` equals `q`. + +Output on qemu 3.0.0 (Linux user-mode emulation): +========================================================= +fpcr = 0x07000000. +x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x7ff0000000000000. q = 0x43300fde9cbcf023. +fpcr = 0x00000000. +x = 0x03250f416dcdc6d0. y = 0x00029f4e5837c977. r = 0x43300fde9cbcf024. q = 0x43300fde9cbcf023. +========================================================= + +Notice that after setting FPCR to zero, `r` is not equal to `q`. + +Also notice that, using another proprietary operating system, the same issue arises between a real board and QEMU. This might be an issue in emulation of the AArch64 instruction "fdiv". + +Build command line: aarch64-linux-gnu-gcc -static -O0 -o sample1 sample1.c \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1793608 b/results/classifier/gemma3:27b/instruction/1793608 new file mode 100644 index 000000000..e865e400c --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1793608 @@ -0,0 +1,19 @@ + + + +qemu doesn't seem to support lxvwsx for POWER9 target + +When running a simple program built for POWER9 on QEMU 3.0.0 in linux-user mode, it crashes with a message: "illegal instruction". It turns out that lxvwsx instruction "Load Word and Splat Indexed" is not supported. If workaround is implemented by issuing two separate instructions (first load then splat) then all tests pass correctly. + +Operating system: Ubuntu Mate 16.04.2 64-bit (or Linux Mint 18 64-bit). +Cross-compiler for gcc-powerpc64le-linux-gnu is installed (gcc-5 series). +QEMU 3.0.0 is built from source and installed with: sudo make install + +The program in question: https://github.com/VectorChief/UniSIMD-assembler +Turn off the workaround: RT_ELEM_COMPAT_PW9 should be set to 1 in the following file: +https://github.com/VectorChief/UniSIMD-assembler/blob/master/core/config/rtarch_p32_128x1v2.h + +Change to the "test" directory and type "make -f simd_make_p64.mk". +powerpc64le-linux-gnu-objdump -d simd_test.p64_32Lp9 > simd_test_p64_32Lp9.txt +Open newly created text file simd_test_p64_32Lp9.txt and search for lxvwsx (in s_test01, ...) +The instruction shows up in objdump correctly. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1796520 b/results/classifier/gemma3:27b/instruction/1796520 new file mode 100644 index 000000000..73bbb8c49 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1796520 @@ -0,0 +1,39 @@ + + + +autogen crashes on qemu-sh4-user after 61dedf2af7 + +Running "autogen --help" crashes on qemu-sh4-user with: + +(sid-sh4-sbuild)root@nofan:/# autogen --help +Unhandled trap: 0x180 +pc=0xf64dd2de sr=0x00000000 pr=0xf63b9c74 fpscr=0x00080000 +spc=0x00000000 ssr=0x00000000 gbr=0xf61102a8 vbr=0x00000000 +sgr=0x00000000 dbr=0x00000000 delayed_pc=0xf64dd2a0 fpul=0x00000003 +r0=0xf6fc1320 r1=0x00000000 r2=0xffff5dc4 r3=0xf67bfb50 +r4=0xf6fc1230 r5=0xf6fc141c r6=0x000003ff r7=0x00000000 +r8=0x00000004 r9=0xf63e20bc r10=0xf6fc141c r11=0xf63e28f0 +r12=0xf63e2258 r13=0xf63eae1c r14=0x00000804 r15=0xf6fc1220 +r16=0x00000000 r17=0x00000000 r18=0x00000000 r19=0x00000000 +r20=0x00000000 r21=0x00000000 r22=0x00000000 r23=0x00000000 +(sid-sh4-sbuild)root@nofan:/# + +Bi-secting found this commit to be the culprit: + +61dedf2af79fb5866dc7a0f972093682f2185e17 is the first bad commit +commit 61dedf2af79fb5866dc7a0f972093682f2185e17 +Author: Richard Henderson <email address hidden> +Date: Tue Jul 18 10:02:50 2017 -1000 + + target/sh4: Add missing FPSCR.PR == 0 checks + + Both frchg and fschg require PR == 0, otherwise undefined_operation. + + Reviewed-by: Aurelien Jarno <email address hidden> + Signed-off-by: Richard Henderson <email address hidden> + Message-Id: <email address hidden> + Signed-off-by: Aurelien Jarno <email address hidden> + +:040000 040000 980d79b69ae712f23a1e4c56983e97a843153b4a 1024c109f506c7ad57367c63bc8bbbc8a7a36cd7 M target + +Reverting 61dedf2af79fb5866dc7a0f972093682f2185e17 fixes the problem for me. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1806243 b/results/classifier/gemma3:27b/instruction/1806243 new file mode 100644 index 000000000..d3250c600 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1806243 @@ -0,0 +1,87 @@ + + + +ARM conditional branch after if-then instruction not working + +Hello + +There seems to be an issue with QEMU when debugging if-then condition blocks from the thumb2 instruction set. The following snippet runs fine during normal execution, but keeps hanging at the conditional branch when debugging. The jump at the branch should only be executed as long as $r0 is lower than $r1. Problem is that once both are equal, the execution is not continued past the branch and the program counter never gets popped. + +2000407a: push {lr} +2000407c: movs r0, r6 +2000407e: ldmia r7!, {r1, r6} +20004080: push {r0, r1} +20004082: str.w r6, [r7, #-4]! +20004086: ldr r6, [sp, #0] +20004088: pop {r0, r1} +2000408a: adds r0, #1 +2000408c: cmp r0, r1 +2000408e: itt lt +20004090: pushlt {r0, r1} +20004092: blt.w 0x20004082 ; unpredictable <IT:lt> // <-- GDB hangs here +20004096: pop {pc} + +I have tried to reproduce the problem with inline assembly but for some reason the following example just worked: + +void f() { + static uint8_t stack[256]{}; + stack[255] = 4; + + asm volatile("\n\t" + "push {lr}" + "\n\t" + + // pre-conditions + "movs r7, %[stack]" + "\n\t" + "movs r6, #1" + "\n\t" + + "movs r0, r6" + "\n\t" + "ldmia r7!, {r1, r6}" + "\n\t" + "push {r0, r1}" + "\n\t" + "1:" + "\n\t" + "str.w r6, [r7, #-4]!" + "\n\t" + "ldr r6, [sp, #0]" + "\n\t" + "pop {r0, r1}" + "\n\t" + "adds r0, #1" + "\n\t" + "cmp r0, r1" + "\n\t" + "itt lt" + "\n\t" + "pushlt {r0, r1}" + "\n\t" + + // Original instruction + //"blt.w 0x20004082" // ; unpredictable <IT:lt> + + // Trying to fake it + "blt.w 1b" + "\n\t" + + "pop {pc}" + "\n\t" + : + : [stack] "r"(&stack[255])); +} + +The only real major difference I see to the other code snipped is that the inline assembly is running from flash memory where as the original code runs in ram? Maybe that's a clue somehow? + +Quickly reading through already reported ARM bugs I think this might be related: +https://bugs.launchpad.net/qemu/+bug/1364501 +At least the symptoms sound identical. + + +The versions I'm running are: +QEMU 3.0.0 +arm-none-eabi-gdb 8.2 + +I've also captured some trace output for single stepping from the pushlt to the blt.w instruction with the trace arguments unimp, guest_errors, op, int, exec. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1809546 b/results/classifier/gemma3:27b/instruction/1809546 new file mode 100644 index 000000000..dfeb2f575 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1809546 @@ -0,0 +1,90 @@ +semantic: 0.913 +instruction: 0.876 +device: 0.860 +other: 0.855 +boot: 0.852 +assembly: 0.850 +graphic: 0.848 +network: 0.811 +mistranslation: 0.754 +vnc: 0.735 +socket: 0.612 +KVM: 0.608 + +Writing a byte to a pl011 SFR overwrites the whole SFR + +The bug is present in QEMU 2.8.1 and, if my analysis is correct, also on master. + +I first noticed that a PL011 UART driver, which is fine on real hardware, fails to enable the RX interrupt in the IMSC register when running in QEMU. However, the problem only comes up if the code is compiled without optimizations. I think I've narrowed it down to a minimal example that will exhibit the problem if run as a bare-metal application. + +Given: + +pl011_addr: .word 0x10009000 + +The following snippet will be problematic: + + ldr r3, pl011_addr + ldrb r2, [r3, #0x38] // IMSC + mov r2, #0 + orr r2, r2, #0x10 // R2 == 0x10 + strb r2, [r3, #0x38] // Whole word reads correctly after this + ldrb r2, [r3, #0x39] + mov r2, #0 + strb r2, [r3, #0x39] // Problem here! Overwrites offset 0x38 as well + +After the first strb instruction, which writes to 0x10009038, everything is fine. It can be seen in the QEMU monitor: + +(qemu) xp 0x10009038 +0000000010009038: 0x00000010 + +After the second strb instruction, the write to 0x10009039 clears the entire word: + +(qemu) xp 0x10009038 +0000000010009038: 0x00000000 + +QEMU command-line, using the vexpress-a9 which has the PL011 at 0x10009000: + +qemu-system-arm -S -M vexpress-a9 -m 32M -no-reboot -nographic -monitor telnet:127.0.0.1:1234,server,nowait -kernel pl011-sfr.bin -gdb tcp::2159 -serial mon:stdio + +Compiling the original C code with optimizations makes the driver work. It compiles down to assembly that only does a single write: + + ldr r3, pl011_addr + mov r2, #0x10 + str r2, [r3, #0x38] + +Attached is the an assembly file, and linkscript, that shows the problem, and also includes the working code. + +I haven't debugged inside of QEMU itself but it seems to me that the problem is in pl011_write in pl011.c - the functions looks at which offset is being written, and then writes the entire SFR that offset falls under, which means that changing a single byte will change the whole SFR. + + + +Adding the link script. + +Yes, our PL011 implementation assumes that you only ever access the 32-bit registers with full width 32-bit word reads and writes. Don't try to do byte accesses to them. The PL011 data sheet doesn't specifically say that partial-width accesses to registers are permitted, so I think that trying to access offset 0x39 falls under the general note in section 3.1 that attempting to access reserved or unused address locations can result in unpredictable behaviour. + +You need to make sure you write your C code in a manner which enforces that accesses to device registers are done as single 32-bit accesses, and the compiler does not silently break them down into multiple reads and writes, or you will be in for a lot of pain trying to figure out what is going on if the compiler ever does it with registers that are write-to-clear or similar behaviour. Linux, for instance, does this by having readl() and writel() functions that end up doing inline asm of ldr/str instructions. + + +Thanks for the response. + +I don't think section 3.1 applies to 8-bit accesses. That is specifically about reserved locations, and neither offset 0x38 nor 0x39 are reserved, so I think it's a matter of whether 32-bit access is required or not. + +From what I usually see in ARM documentation, 32-bit access is explicitly mentioned when required. For the PL011, it's mentioned for the UARTPeriphID_n registers, for instance. In many other cases access size depends on the implementation and the corresponding memory mapping of that implementation. + +I understand that *in practice* you should ensure single-access writes unless doing otherwise is explicitly allowed. However, in cases like the PL011 it seems ambiguous whether that is actually required, so it seems like the best choice would be to explicitly document it for the QEMU implementation. That would save some guesswork. + +The QEMU project is currently considering to move its bug tracking to +another system. For this we need to know which bugs are still valid +and which could be closed already. Thus we are setting older bugs to +"Incomplete" now. + +If you still think this bug report here is valid, then please switch +the state back to "New" within the next 60 days, otherwise this report +will be marked as "Expired". Or please mark it as "Fix Released" if +the problem has been solved with a newer version of QEMU already. + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/gemma3:27b/instruction/1815024 b/results/classifier/gemma3:27b/instruction/1815024 new file mode 100644 index 000000000..7376befa4 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1815024 @@ -0,0 +1,18 @@ + + + +SIGILL on instruction "stck" under qemu-s390x in user mode + +qemu-s390x in user mode crashes with SIGILL (under host architecture x86_64, running Debian unstable) when executing target instruction "stck" ("STORE CLOCK", see https://www-01.ibm.com/support/docview.wss?uid=isg26480faec85f44e2385256d5200627dee&aid=1), which is basically a kind of equivalent of Intel "rdtsc". The same instruction works fine under qemu-s390x in system mode. The bug is reproducible with both the qemu version distributed in Debian unstable and with the latest upstream master (commit 47994e16b1d66411953623e7c0bf0cdcd50bd507). + +This bug manifested itself as a crash of ssh-keygen program, which uses "stck" to obtain some bits of randomness during key creation. Bisection of the code led to the attached minimal example. Compile with (inside an s390x system): + + $ gcc -c -o test.o test.c + $ gcc -c -o rdtsc.o rdtsc.S + $ gcc -o test test.o rdtsc.o + +Then run test. It will crash with SIGILL in user mode and run fine in system mode. Also, compare with the original file at https://github.com/openssl/openssl/blob/master/crypto/s390xcpuid.pl#L139 (there the instruction "stckf" is also used; it is probable that it has the same problem if it is supported altogether, but it did not test for this). + +Running qemu-s390x with options -d in_asm,out_asm,op,op_opt,exec,nochain,cpu gives the trace attached in log.txt. + +Thanks, Giovanni. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1818075 b/results/classifier/gemma3:27b/instruction/1818075 new file mode 100644 index 000000000..7eb43be42 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1818075 @@ -0,0 +1,56 @@ + + + +qemu x86 TCG doesn't support AVX insns + +I'm trying to execute code that has been built with -march=skylake -mtune=generic -mavx2 under qemu-user x86-64 with -cpu Skylake-Client. However this code just hangs at 100% CPU. + +Adding input tracing shows that it is likely hanging when dealing with an AVX instruction: + +warning: TCG doesn't support requested feature: CPUID.01H:ECX.fma [bit 12] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.avx [bit 28] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.f16c [bit 29] +warning: TCG doesn't support requested feature: CPUID.01H:ECX.rdrand [bit 30] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.hle [bit 4] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.avx2 [bit 5] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 10] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.rtm [bit 11] +warning: TCG doesn't support requested feature: CPUID.07H:EBX.rdseed [bit 18] +warning: TCG doesn't support requested feature: CPUID.80000001H:ECX.3dnowprefetch [bit 8] +warning: TCG doesn't support requested feature: CPUID.0DH:EAX.xsavec [bit 1] + +IN: +0x4000b4ef3b: c5 fb 5c ca vsubsd %xmm2, %xmm0, %xmm1 +0x4000b4ef3f: c4 e1 fb 2c d1 vcvttsd2si %xmm1, %rdx +0x4000b4ef44: 4c 31 e2 xorq %r12, %rdx +0x4000b4ef47: 48 85 d2 testq %rdx, %rdx +0x4000b4ef4a: 79 9e jns 0x4000b4eeea + +[ hangs ] + +Attaching a gdb produces this stacktrace: + +(gdb) bt +#0 canonicalize (status=0x55a20ff67a88, parm=0x55a20bb807e0 <float64_params>, part=...) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:350 +#1 float64_unpack_canonical (s=0x55a20ff67a88, f=0) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:547 +#2 float64_sub (a=0, b=4890909195324358656, status=0x55a20ff67a88) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/fpu/softfloat.c:776 +#3 0x000055a20baa1949 in helper_subsd (env=<optimized out>, d=0x55a20ff67ad8, s=<optimized out>) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/target/i386/ops_sse.h:623 +#4 0x000055a20cfcfea8 in static_code_gen_buffer () +#5 0x000055a20ba3f764 in cpu_tb_exec (itb=<optimized out>, cpu=0x55a20cea2180 <static_code_gen_buffer+15684720>) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:171 +#6 cpu_loop_exec_tb (tb_exit=<synthetic pointer>, last_tb=<synthetic pointer>, tb=<optimized out>, + cpu=0x55a20cea2180 <static_code_gen_buffer+15684720>) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:615 +#7 cpu_exec (cpu=cpu@entry=0x55a20ff5f4d0) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/accel/tcg/cpu-exec.c:725 +#8 0x000055a20ba6d728 in cpu_loop (env=0x55a20ff67780) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/x86_64/../i386/cpu_loop.c:93 +#9 0x000055a20ba049ff in main (argc=<optimized out>, argv=0x7ffc58572868, envp=<optimized out>) + at /data/poky-tmp/master/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/main.c:819 \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1820686 b/results/classifier/gemma3:27b/instruction/1820686 new file mode 100644 index 000000000..a141dce7d --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1820686 @@ -0,0 +1,8 @@ + + + +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. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1821430 b/results/classifier/gemma3:27b/instruction/1821430 new file mode 100644 index 000000000..da8071c4c --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1821430 @@ -0,0 +1,35 @@ + + + +qemu-user-arm (4.0.0-rc0) crashes + +I'm using qemu-user-arm for crosscompilation needs, usually via a wrapper. +qemu-user-arm (4.0.0-rc0) crashes with SIGILL on at least 2 instructions: + +first case (sadly I don't have more data handy, can reproduce at a later time if needed): +(gdb) x/i $pc +=> 0xfffce314: vseleq.f64 d0, d17, d0 + +second case (llvm-config): +qemu cmdline: +qemu-arm -strace -cpu max -r 5.0.0 -L /home/asavah/kross/build/rpi3/rootfs -E LD_LIBRARY_PATH=/home/asavah/kross/build/rpi3/rootfs/usr/bin:/home/asavah/kross/build/rpi3/rootfs/usr/lib /home/asavah/kross/build/rpi3/rootfs/usr/bin/llvm-config --shared-mode + +--- SIGILL {si_signo=SIGILL, si_code=2, si_addr=0xf9f89f80} --- +qemu: uncaught target signal 4 (Illegal instruction) - core dumped + +output from gdb(arm) attached to qemu-user-arm +Program received signal SIGILL, Illegal instruction. +0xf9f77f80 in ?? () +(gdb) bt +#0 0xf9f77f80 in ?? () +#1 0xfffd796c in ?? () +Backtrace stopped: previous frame identical to this frame (corrupt stack?) +(gdb) x/i $pc +=> 0xf9f77f80: vrintm.f64 d18, d18 + + +The very same binaries when run with qemu-user-arm 3.1.0 (both from ubuntu 19.04 package and self built) +work flawlessly. + +This is clearly a regression. +Please fix before releasing 4.0.0. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1821444 b/results/classifier/gemma3:27b/instruction/1821444 new file mode 100644 index 000000000..572d8a990 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1821444 @@ -0,0 +1,32 @@ + + + +qemu-ppc (user) incorrectly translates float32 arithmetics + +I'm using qemu-3.1.0 (Gentoo). + +When I was running regression test suite via qemu-ppc for GHC I noticed a few uint32_t<->float32 failures I did not expect to encounter. + +Here is an example + +$ cat a.c +#include <stdio.h> +#include <stdint.h> + +int main() { + volatile uint32_t i = 1; + printf("0x1 = %e\n", *(volatile float*)&i); +} + +$ powerpc-unknown-linux-gnu-gcc -O2 a.c -Wall -o a -fno-strict-aliasing -fno-stack-protector -static && ./a +0x1 = 2.802597e-45 + +$ scp a timberdoodle.ppc64.dev.gentoo.org:~/ +a 100% 826KB 102.0KB/s 00:08 + +$ ssh timberdoodle.ppc64.dev.gentoo.org ./a +0x1 = 1.401298e-45 +$ qemu-ppc ./a +0x1 = 2.802597e-45 + +Looks like off-by-one bit somewhere. I'm not sure if it's FPU instruction or some internals of printf() that are emulated incorrectly. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1824344 b/results/classifier/gemma3:27b/instruction/1824344 new file mode 100644 index 000000000..de20fccdf --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1824344 @@ -0,0 +1,48 @@ + + + +x86: retf or iret pagefault sets wrong error code + +With a x86_64 or i386 guest, non-KVM, when trying to execute a +"iret/iretq/retf" instruction in userspace with invalid stack pointer +(under a protected mode OS, like Linux), wrong bits are set in the +pushed error code; bit 2 is not set, indicating the error comes from +kernel space. + +If the guest OS is using this flag to decide whether this was a kernel +or user page fault, it will mistakenly decide a kernel has irrecoverably +faulted, possibly causing guest OS panic. + + +How to reproduce the problem a guest (non-KVM) Linux: +Note, on recent Linux kernel version, this needs a CPU with SMAP support +(eg. -cpu max) + +$ cat tst.c +int main() +{ +__asm__ volatile ( +"mov $0,%esp\n" +"retf" +); +return 0; +} + +$ gcc tst.c +$ ./a.out +Killed + + +"dmesg" shows the kernel has in fact triggered a "BUG: unable to handle +kernel NULL pointer dereference...", but it has "recovered" by killing +the faulting process (see attached screenshot). + + +Using self-compiled qemu from git: +commit 532cc6da74ec25b5ba6893b5757c977d54582949 (HEAD -> master, tag: v4.0.0-rc3, origin/master, origin/HEAD) +Author: Peter Maydell <email address hidden> +Date: Wed Apr 10 15:38:59 2019 +0100 + + Update version for v4.0.0-rc3 release + + Signed-off-by: Peter Maydell <email address hidden> \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1824778 b/results/classifier/gemma3:27b/instruction/1824778 new file mode 100644 index 000000000..d9e3e95db --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1824778 @@ -0,0 +1,30 @@ +instruction: 0.756 +device: 0.493 +semantic: 0.280 +graphic: 0.275 +network: 0.264 +other: 0.245 +boot: 0.202 +vnc: 0.194 +socket: 0.151 +mistranslation: 0.124 +KVM: 0.054 +assembly: 0.052 + +PowerPC64: tlbivax does not work for addresses above 4G + +The tlbivax instruction in QEMU does not work for address above 4G. The reason behind this is a simple 32bit trunction of an address. +Changing the argument ea from uint32_t to target_ulong for the function booke206_invalidate_ea_tlb() in target/ppc/mmu_helper.c solves the issue. + +I did not reproduce this using Linux so I have no public example for reproducing it. However it's a pretty straight forward change. + +Issue can be seen in all version of QEMU. + + +This is an automated cleanup. This bug report has been moved +to QEMU's new bug tracker on gitlab.com and thus gets marked +as 'expired' now. Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/52 + + diff --git a/results/classifier/gemma3:27b/instruction/1826568 b/results/classifier/gemma3:27b/instruction/1826568 new file mode 100644 index 000000000..cebbffe97 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1826568 @@ -0,0 +1,16 @@ + + + +RISC-V Disassembler/translator instruction decoding disagreement + + +When running QEMU V3.1.0 for platform RISC-V, 64bit, Spike V1.10 with "-d in_asm -singlestep -D qemu_log.txt", my (faulty) test code brought up this message in the logs: + + 0x000000008002cade: 051300009517e2bf illegal + Disassembler disagrees with translator over instruction decoding + Please report this to <email address hidden> + + +You may want to resolve the disagreement. + +Axel \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1828867 b/results/classifier/gemma3:27b/instruction/1828867 new file mode 100644 index 000000000..a17fd5b58 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1828867 @@ -0,0 +1,11 @@ + + + +QEmu translation is incorrect when using REX in combination with LAHF/SAHF + +When translating code that is using LAHF and SAHF in combination with the REX prefix then qemu translates incorrectly. +These two instructions only ever use the AH register. Contrary to other instructions where if you use REX + high bit offsets then it'll pull in rsp and a few other registers. +On hardware the REX prefix doesn't effect behaviour of these instructions at all. +QEMU incorrectly selects RSP as the register of choice here due to this combination of REX + AH register usage. + +I've attached a patch that is super terrible just so I can work around the issue locally and to sort of show off how it is to be "fixed" \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1832422 b/results/classifier/gemma3:27b/instruction/1832422 new file mode 100644 index 000000000..eeb2facc5 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1832422 @@ -0,0 +1,12 @@ + + + +SSE CMP ops with 8bit immediate throw sigill with oversized byte + +The SSE comparison ops that use an 8bit immediate as a comparison type selector throws a sigill when the immediate is oversized. + +Test op that I found this on is here `66 0f c2 c0 d1 cmppd xmm0,xmm0,0xd1` +According to the x86-64 documentation only bits [2:0] are used for these ops (and [4:0] for the AVX variant) +Currently qemu just checks if the value is >=8 and will throw a sigill in that case. It instead needs to mask. + +I have a small patch that fixes the issue for the SSE variant. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1833 b/results/classifier/gemma3:27b/instruction/1833 new file mode 100644 index 000000000..39a745ea4 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1833 @@ -0,0 +1,87 @@ + + + +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/gemma3:27b/instruction/1841990 b/results/classifier/gemma3:27b/instruction/1841990 new file mode 100644 index 000000000..309b9baa5 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1841990 @@ -0,0 +1,41 @@ + + + +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/gemma3:27b/instruction/1847467 b/results/classifier/gemma3:27b/instruction/1847467 new file mode 100644 index 000000000..e0900ebd8 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1847467 @@ -0,0 +1,19 @@ + + + +qemu-x86_64 segment prefixes error + +qemu-x86_64 version 4.1.0 (qemu-x86_64 version 4.0.0 also have the issue) + +In 64-bit mode (x86_64) the DS, ES, SS or CS segment prefixes should be ignored; qemu-x86_64 does not ignore them. + +example: an x86_64 instructions preceded by FS DS (0x64 0x26) segment prefixes have the linear address of its memory reference flat-mapped (as if DS was in action) whereas it should be FS-mapped (offset by FS_base, because the DS, ES, SS or CS are just ignored). + + +I attach a small C++ program that shows this discrepancy. + +$ ./sample +I'm not in QEMU + +$ qemu-x86_64 ./sample +I'm in QEMU \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1854738 b/results/classifier/gemma3:27b/instruction/1854738 new file mode 100644 index 000000000..b4fa75fd3 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1854738 @@ -0,0 +1,31 @@ + + + +ppc doesn't support for mttcg but ppc64 supported + +Currently ppc and ppc64abi32 doesn't suppport for mttcg, I am looking for support +``` + ppc) + gdb_xml_files="power-core.xml power-fpu.xml power-altivec.xml power-spe.xml" + ;; + ppc64) + TARGET_BASE_ARCH=ppc + TARGET_ABI_DIR=ppc + mttcg=yes + gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml power-spe.xml power-vsx.xml" + ;; + ppc64le) + TARGET_ARCH=ppc64 + TARGET_BASE_ARCH=ppc + TARGET_ABI_DIR=ppc + mttcg=yes + gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml power-spe.xml power-vsx.xml" + ;; + ppc64abi32) + TARGET_ARCH=ppc64 + TARGET_BASE_ARCH=ppc + TARGET_ABI_DIR=ppc + echo "TARGET_ABI32=y" >> $config_target_mak + gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml power-spe.xml power-vsx.xml" + ;; +``` \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1859713 b/results/classifier/gemma3:27b/instruction/1859713 new file mode 100644 index 000000000..52aabc3d9 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1859713 @@ -0,0 +1,28 @@ + + + +ARM v8.3a pauth not working + +Host: Ubuntu 19.10 - x86_64 machine +QEMU version: 3a63b24a1bbf166e6f455fe43a6bbd8dea413d92 (master) + +ARMV8.3 pauth is not working well. + +With a test code containing two pauth instructions: + - paciasp that sign LR with A key and sp as context; + - autiasp that verify the signature. + +Test: + - Run the program and corrupt LR just before autiasp (ex 0x3e00000400660 instead of 0x3e000000400664) + +Expected: + - autiasp places an invalid pointer in LR + +Result: + - autiasp successfully auth the pointer and places 0x0400660 in LR. + +Further explanations: + Adding traces in qemu code shows that "pauth_computepac" is not robust enough against truncating. + With 0x31000000400664 as input of pauth_auth, we obtain "0x55b1d65b2c138e14" for PAC, "0x30" for bot_bit and "0x38" for top_bit. + With 0x310040008743ec as input of pauth (with same key), we obtain "0x55b1d65b2c138ef4" for PAC, "0x30" for bot_bit and "0x38" for top_bit. + Values of top_bit and bottom_bit are strictly the same and it should not. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1861404 b/results/classifier/gemma3:27b/instruction/1861404 new file mode 100644 index 000000000..769be0f54 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1861404 @@ -0,0 +1,53 @@ + + + +AVX instruction VMOVDQU implementation error for YMM registers + +Hi, + +Tested with Qemu 4.2.0, and with git version bddff6f6787c916b0e9d63ef9e4d442114257739. + +The x86 AVX instruction VMOVDQU doesn't work properly with YMM registers (32 bytes). +It works with XMM registers (16 bytes) though. + +See the attached test case `ymm.c`: when copying from memory-to-ymm0 and then back from ymm0-to-memory using VMOVDQU, Qemu only copies the first 16 of the total 32 bytes. + +``` +user@ubuntu ~/Qemu % gcc -o ymm ymm.c -Wall -Wextra -Werror + +user@ubuntu ~/Qemu % ./ymm +00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F + +user@ubuntu ~/Qemu % ./x86_64-linux-user/qemu-x86_64 -cpu max ymm +00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +``` + +This seems to be because in `translate.c > gen_sse()`, the case handling the VMOVDQU instruction calls `gen_ldo_env_A0` which always performs a 16 bytes copy using two 8 bytes load and store operations (with `tcg_gen_qemu_ld_i64` and `tcg_gen_st_i64`). + +Instead, the `gen_ldo_env_A0` function should generate a copy with a size corresponding to the used register. + + +``` +static void gen_sse(CPUX86State *env, DisasContext *s, int b, + target_ulong pc_start, int rex_r) +{ + [...] + case 0x26f: /* movdqu xmm, ea */ + if (mod != 3) { + gen_lea_modrm(env, s, modrm); + gen_ldo_env_A0(s, offsetof(CPUX86State, xmm_regs[reg])); + } else { + [...] +``` + +``` +static inline void gen_ldo_env_A0(DisasContext *s, int offset) +{ + int mem_index = s->mem_index; + tcg_gen_qemu_ld_i64(s->tmp1_i64, s->A0, mem_index, MO_LEQ); + tcg_gen_st_i64(s->tmp1_i64, cpu_env, offset + offsetof(ZMMReg, ZMM_Q(0))); + tcg_gen_addi_tl(s->tmp0, s->A0, 8); + tcg_gen_qemu_ld_i64(s->tmp1_i64, s->tmp0, mem_index, MO_LEQ); + tcg_gen_st_i64(s->tmp1_i64, cpu_env, offset + offsetof(ZMMReg, ZMM_Q(1))); +} +``` \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1861605 b/results/classifier/gemma3:27b/instruction/1861605 new file mode 100644 index 000000000..09ddfa40c --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1861605 @@ -0,0 +1,19 @@ + + + +LL/SC broken for MIPS after 7dd547e5ab6b31e7a0cfc182d3ad131dd55a948f + +In that commit the env->llval value is loaded as an unsigned value (instead of sign-extended as before and therefore the CMPXCHG in gen_st_cond() in translate.c fails. + +I have committed a fix for this issue as https://github.com/CTSRD-CHERI/qemu/commit/a18d80c629989d002794f558968e1561edaf3dfd + +An alternative solution would be to change the cmpxchg line to perform a non-sign-extended compare, i.e. replace + tcg_gen_atomic_cmpxchg_tl(t0, addr, cpu_llval, val, + eva ? MIPS_HFLAG_UM : ctx->mem_idx, tcg_mo); +with + tcg_gen_atomic_cmpxchg_tl(t0, addr, cpu_llval, val, + eva ? MIPS_HFLAG_UM : ctx->mem_idx, tcg_mo & ~MO_SIGN); + + +I cannot send this patch to the QEMU mailing list as I am not able to setup git-send-email. +Feel free to apply this commit or the alternative solution. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1862167 b/results/classifier/gemma3:27b/instruction/1862167 new file mode 100644 index 000000000..512a54b7c --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1862167 @@ -0,0 +1,6 @@ + + + +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/gemma3:27b/instruction/1863247 b/results/classifier/gemma3:27b/instruction/1863247 new file mode 100644 index 000000000..06754fce8 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1863247 @@ -0,0 +1,11 @@ + + + +AArch64 EXT instruction for V register does not clear MSB side bits + +On AArch64 CPU with SVE register, there seems to be a bug in the operation when executing EXT instruction to V registers. Bits above the 128 bits of the SVE register must be cleared to 0, but qemu-aarch64 seems to hold the value. + +Example +ext v0.16b, v1.16b v2.16b, 8 + +After executing above instruction, (N-1) to 128 bits of z0 register must be 0, where N is SVE register width. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1873898 b/results/classifier/gemma3:27b/instruction/1873898 new file mode 100644 index 000000000..452c82c83 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1873898 @@ -0,0 +1,41 @@ + + + +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/gemma3:27b/instruction/1874888 b/results/classifier/gemma3:27b/instruction/1874888 new file mode 100644 index 000000000..8a9610f12 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1874888 @@ -0,0 +1,46 @@ + + + +certain programs make QEMU crash with "tcg fatal error" + +The following code snippet crashes qemu with + +.../tcg/tcg.c:3279: tcg fatal error +qemu-x86_64: /usr/local/google/home/kostik/qemu-5.0.0-rc4/accel/tcg/cpu-exec.c:701: int cpu_exec(CPUState *): Assertion `!have_mmap_lock()' failed. + +================ +int main() { + /* +00000000 <.data>: + 0: 2e 45 71 ff cs rex.RB jno 0x3 + 4: e9 00 00 f0 00 jmp 0xf00009 + 9: c4 42 7d 31 3e vpmovzxbd ymm15,QWORD PTR [r14] + e: c4 a3 7d 08 64 82 44 vroundps ymm4,YMMWORD PTR [rdx+r8*4+0x44],0x0 + 15: 00 + 16: 0f 1e 0a nop DWORD PTR [rdx] + 19: 43 0f ec 20 rex.XB paddsb mm4,QWORD PTR [r8] + 1d: 66 47 0f 3a 0c 3d 00 rex.RXB blendps xmm15,XMMWORD PTR [rip+0x8000],0x0 # 0x8028 + 24: 80 00 00 00 + 28: c4 e3 f9 df 5f 86 0d vaeskeygenassist xmm3,XMMWORD PTR [rdi-0x7a],0xd + 2f: c4 e2 55 92 74 fc 0a vgatherdps ymm6,DWORD PTR [rsp+ymm7*8+0xa],ymm5 + 36: c4 e2 f9 17 9a 01 00 vptest xmm3,XMMWORD PTR [rdx+0x1] + 3d: 00 00 +*/ + char buf[] = { + 0x2E, 0x45, 0x71, 0xFF, 0xE9, 0x00, 0x00, 0xF0, 0x00, 0xC4, 0x42, 0x7D, 0x31, 0x3E, 0xC4, 0xA3, 0x7D, 0x08, 0x64, 0x82, 0x44, 0x00, 0x0F, 0x1E, 0x0A, 0x43, 0x0F, 0xEC, 0x20, 0x66, 0x47, 0x0F, 0x3A, 0x0C, 0x3D, 0x00, 0x80, 0x00, 0x00, 0x00, 0xC4, 0xE3, 0xF9, 0xDF, 0x5F, 0x86, 0x0D, 0xC4, 0xE2, 0x55, 0x92, 0x74, 0xFC, 0x0A, 0xC4, 0xE2, 0xF9, 0x17, 0x9A, 0x01, 0x00, 0x00, 0x00 + }; + void (*f)(void) = (void (*) (void))buf; + f(); + return 0; +} +================ +Steps to reproduce: +1) clang -static repro.c -o repro +2) qemu-x86_64-static repro + +Tested with 4.2.0 and 5.0.0-rc4. Both -user and -system variants are affected. + +A few more snippets that cause the same sort of behavior: +1) 0x64, 0x46, 0x7D, 0xFF, 0xDF, 0x27, 0x46, 0x0F, 0xD4, 0x83, 0x5E, 0x00, 0x00, 0x00, 0x3E, 0x0F, 0x6A, 0xEF, 0x0F, 0x05, 0xC4, 0x42, 0xFD, 0x1E, 0xCF, 0x46, 0x18, 0xE3, 0x47, 0xCD, 0x4E, 0x6E, 0x0F, 0x0F, 0x16, 0x8A + +2) 0x67, 0x45, 0xDB, 0xD0, 0xAA, 0xC4, 0xE2, 0xB1, 0x01, 0x57, 0x00, 0xF3, 0x6F, 0xF3, 0x42, 0x0F, 0x1E, 0xFD, 0x64, 0x2E, 0xF2, 0x45, 0xD9, 0xC4, 0x3E, 0xF3, 0x0F, 0xAE, 0xF4, 0x3E, 0x47, 0x0F, 0x1C, 0x22, 0x42, 0x73, 0xFF, 0xD9, 0xFD \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1877794 b/results/classifier/gemma3:27b/instruction/1877794 new file mode 100644 index 000000000..936efc4c8 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1877794 @@ -0,0 +1,6 @@ + + + +Constant Folding on 64-bit Subtraction causes SIGILL on linux-user glxgears ppc64le to x86_64 by way of generating bad shift instruction with c=-1 + +Hello, I've been recently working on my own little branch of QEMU implementing the drm IOCTLs, when I discovered that glxgears seems to crash in GLXSwapBuffers(); with a SIGILL. I investigated this for about 2 weeks, manually trying to trace the call stack, only to find that we seemingly crash in a bad shift instruction. Originally intended to be an shr_i64 generated to an RLDICL, we end up with an all ones(-1) c value, which gets thrown to the macro for generating the MB, and replaces the instruction with mostly ones. This new instruction, FFFFFFE0 is invalid on ppc64le, and crashes in a host SIGILL in codegen_buffer. I tried to see if the output of translate.c had this bad instruction, but all I got were two (shr eax, cl) instructions, and upon creating a test program with shr (eax, cl) in it, nothing happened. Then figuring that there was nothing actually wrong with the instruction in the first place, I turned my eye to the optimizer, and completely disabled constant folding for arithmetic instructions. This seemed to actually resolve the issue, and then I slowly enabled constant folding again on various instructions only to find that enabling not on the shifts, but on subtraction seemed to cause the bug to reappear. I am bewildered and frankly at this point I'm not sure I have a chance in hell of figuring out what causes it, so I'm throwing it here. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1881450 b/results/classifier/gemma3:27b/instruction/1881450 new file mode 100644 index 000000000..37d7e0e6e --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1881450 @@ -0,0 +1,26 @@ + + + +Emulation of a math function fails for m68k Linux user mode + +Please check the attached math-example.c file. +When running the m68k executable under QEMU, it results in an "Illegal instruction" error. +Other targets don't produce this error. + +Steps to reproduce the bug: + +1. Download the math-example.c attached file. +2. Compile it by running: + m68k-linux-gnu-gcc -O2 -static math-example.c -o math-example-m68k -lm +3. Run the executable with QEMU: + /build/qemu-5.0.0/build-gcc/m68k-linux-user/qemu-m68k math-example-m68k + +The output of execution is: + Profiling function expm1f(): + qemu: uncaught target signal 4 (Illegal instruction) - core dumped + Illegal instruction (core dumped) + +Expected output: + Profiling function expm1f(): + Elapsed time: 47 ms + Control result: 71804.953125 \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1885350 b/results/classifier/gemma3:27b/instruction/1885350 new file mode 100644 index 000000000..c4b1be6a4 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1885350 @@ -0,0 +1,26 @@ + + + +RISCV dynamic rounding mode is not behaving correctly + +Hello, + +I’ve gone through the RISC-V code in latest QEMU release (qemu-5.0.0-rc2) and when checking the Floating point encodings I found the rounding mode is only updated if the opcode field “rm” is changed “ctx->frm == rm”. But according to RISC-V Volume I: Unprivileged ISA, there’s a dynamic mode when rm=7 where the rounding mode is set with frm value. + +So for the same rm value (=7) and when changing frm value seeking different rounding modes, and according to the below code, the rounding mode won’t be updated. Please correct me if I got this implementation wrong. + +static void gen_set_rm(DisasContext *ctx, int rm) +{ + TCGv_i32 t0; + if (ctx->frm == rm) { + return; + } + ctx->frm = rm; + t0 = tcg_const_i32(rm); + gen_helper_set_rounding_mode(cpu_env, t0); + tcg_temp_free_i32(t0); +} + + +My testcase: +I set statically the rm field in the instruction to 7 and before this execution I changed the value of frm field in fcsr register. For the 1st time it worked (according to the code above, the rm is updated so the round mode will also be updated). But when changing fcsr register an re-execute the instruction, there's no difference and the rounding mode is the same like the previous frm value. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1889288 b/results/classifier/gemma3:27b/instruction/1889288 new file mode 100644 index 000000000..352290089 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1889288 @@ -0,0 +1,10 @@ + + + +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/gemma3:27b/instruction/1892081 b/results/classifier/gemma3:27b/instruction/1892081 new file mode 100644 index 000000000..2410ef983 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1892081 @@ -0,0 +1,17 @@ + + + +Performance improvement when using "QEMU_FLATTEN" with softfloat type conversions + +Attached below is a matrix multiplication program for double data +types. The program performs the casting operation "(double)rand()" +when generating random numbers. + +This operation calls the integer to float softfloat conversion +function "int32_to_float_64". + +Adding the "QEMU_FLATTEN" attribute to the function definition +decreases the instructions per call of the function by about 63%. + +Attached are before and after performance screenshots from +KCachegrind. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1898954 b/results/classifier/gemma3:27b/instruction/1898954 new file mode 100644 index 000000000..77df51de8 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1898954 @@ -0,0 +1,73 @@ +instruction: 0.923 +mistranslation: 0.880 +boot: 0.854 +graphic: 0.850 +other: 0.845 +KVM: 0.778 +device: 0.762 +semantic: 0.752 +socket: 0.648 +network: 0.624 +assembly: 0.575 +vnc: 0.567 + +x86 f1 opcode hangs qemu + +I have qemu installed and running in linux and windows +in linux i execute the following simple code in real mode of cpu in my vm +90 nop +90 nop +90 nop +f1 ;this should conjure up my interrupt handler from ivt int 1 +--------- end of code ---- +it works properly in vbox,qemu linux,and even in my boot loder +on a real platform + it doeas not work fine in windows 10 (32 bit efi) based qemu +--- +all of the below was retyped there may be typo +so onwards to the flawed software +********** for qemu-system-x86_64.exe ********** +info version +4.2.0v4.2.0.11797-g2890edc853-dirty +********** for qemu-system-i386.exe ********** +info version +4.2.0v4.2.0.11797-g2890edc853-dirty +*********************************************** +my startup code is +"d:\programs\qemu\qemu-system-x86_64.exe" -m 16M -boot a -fda "d:\floppy.img" -cpu Nehalem -machine pc +--- +also same flaw if i change above section to +"d:\programs\qemu\qemu-system-i386.exe" + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + diff --git a/results/classifier/gemma3:27b/instruction/1901 b/results/classifier/gemma3:27b/instruction/1901 new file mode 100644 index 000000000..dd2f3a207 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1901 @@ -0,0 +1,22 @@ + + + +qemu-sparc64 / sparc32plus apparent wrong results from VIS fmul8x16 instruction +Description of problem: +Experimenting with SPARC emulation, I noticed that the results of the UltraSparc fmul8x16 instruction don't appear to match the behaviour of real silicon (aka it doesn't appear to work at all -- in the test program, the result seems to be always 0). Other VIS instructions I tried seem to be OK (I have not tried all of them). + +The same problem is observed both in 64-bit (qemu-sparc64) and 32-bit (qemu-sparc32plus) applications. +Steps to reproduce: +1. Compile the attached test program (which exhaustively tests all possible combinations of 16-bit and 8-bit inputs) with gcc: + ``` + sparc64-unknown-linux-gnu-gcc -static -Os -mcpu=ultrasparc -mvis -o test_fmul8x16 test_fmul8x16.c + ``` +2. Run it in qemu-sparc64: + ``` + qemu-sparc64 -cpu 'TI UltraSparc II' ./test_fmul8x16 + ``` +3. Observe almost all tests fail. + + Running the exact same compiled binary on a real UltraSparc II CPU gives all pass results. +Additional information: +[test_fmul8x16.c](/uploads/2bf68e53652fba2ed69ac3ebb3f4b5e9/test_fmul8x16.c) diff --git a/results/classifier/gemma3:27b/instruction/1904210 b/results/classifier/gemma3:27b/instruction/1904210 new file mode 100644 index 000000000..6a5a268f2 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1904210 @@ -0,0 +1,54 @@ + + + +Crashed with 'uncaught target signal SIGILL' while program has registered by signal(SIGILL, handler) + +This binary is an CTF reverse challenge binary, it registers signal handler via 'signal(SIGILL, 0x1193D);' while 0x1193D is the SIGILL handler. + +Please see the attachment, the file 'repair' is the binary i mentioned above, the file 'qemu-arm' is an old version qemu at 2.5.0, and it seems an official release (not modified). + +Which means, it could be a bug in recent release. + +You need to input 'flag{' to the stdin to let the binary execute the illegal instruction at 0x10A68. + +In 2.5.0 version the -strace logs: +116 uname(0xf6ffed40) = 0 +116 brk(NULL) = 0x0009f000 +116 brk(0x0009fd00) = 0x0009fd00 +116 readlink("/proc/self/exe",0xf6ffde78,4096) = 21 +116 brk(0x000c0d00) = 0x000c0d00 +116 brk(0x000c1000) = 0x000c1000 +116 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory) +116 rt_sigaction(SIGILL,0xf6ffec48,0xf6ffecd4) = 0 +116 fstat64(1,0xf6ffe8e8) = 0 +116 ioctl(1,21505,-151000980,-151000924,652480,640808) = 0 +116 fstat64(0,0xf6ffe7d0) = 0 +116 ioctl(0,21505,-151001260,-151001204,652480,641152) = 0 +116 write(1,0xa5548,6)input: = 6 +116 read(0,0xa6550,4096)flag{ + = 6 +116 write(1,0xa5548,7)wrong! + = 7 +116 _llseek(0,4294967295,4294967295,0xf6ffee18,SEEK_CUR) = -1 errno=29 (Illegal seek) +116 exit_group(0) + +In 2.11.1, it shows: +113 uname(0xfffeed30) = 0 +113 brk(NULL) = 0x0009f000 +113 brk(0x0009fd00) = 0x0009fd00 +113 readlink("/proc/self/exe",0xfffede68,4096) = 21 +113 brk(0x000c0d00) = 0x000c0d00 +113 brk(0x000c1000) = 0x000c1000 +113 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory) +113 rt_sigaction(SIGILL,0xfffeec38,0xfffeecc4) = 0 +113 fstat64(1,0xfffee8d8) = 0 +113 ioctl(1,21505,-71588,-71532,652480,640808) = 0 +113 fstat64(0,0xfffee7c0) = 0 +113 ioctl(0,21505,-71868,-71812,652480,641152) = 0 +113 write(1,0xa5548,6)input: = 6 +113 read(0,0xa6550,4096)flag{ + = 6 +--- SIGILL {si_signo=SIGILL, si_code=2, si_addr=0x00010a68} --- +--- SIGILL {si_signo=SIGILL, si_code=2, si_addr=0x0001182c} --- +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction (core dumped) \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1905356 b/results/classifier/gemma3:27b/instruction/1905356 new file mode 100644 index 000000000..7c92cb919 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1905356 @@ -0,0 +1,15 @@ + + + +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/gemma3:27b/instruction/1906536 b/results/classifier/gemma3:27b/instruction/1906536 new file mode 100644 index 000000000..ce49bf0bc --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1906536 @@ -0,0 +1,33 @@ + + + +Unable to set SVE VL to 1024 bits or above since 7b6a2198 + +Prior to 7b6a2198e71794c851f39ac7a92d39692c786820, the QEMU option sve-max-vq could be used to set the vector length of the implementation. This is useful (among other reasons) for testing software compiled with a fixed SVE vector length. Since this commit, the vector length is capped at 512 bits. + +To reproduce the issue: + +$ cat rdvl.s +.global _start +_start: + rdvl x0, #1 + asr x0, x0, #4 + mov x8, #93 // exit + svc #0 +$ aarch64-linux-gnu-as -march=armv8.2-a+sve rdvl.s -o rdvl.o +$ aarch64-linux-gnu-ld rdvl.o +$ for vl in 1 2 4 8 16; do ../build-qemu/aarch64-linux-user/qemu-aarch64 -cpu max,sve-max-vq=$vl a.out; echo $?; done +1 +2 +4 +4 +4 + +For a QEMU built prior to the above revision, we get the output: +1 +2 +4 +8 +16 + +as expected. It seems that either the old behavior should be restored, or there should be an option to force a higher vector length? \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1908626 b/results/classifier/gemma3:27b/instruction/1908626 new file mode 100644 index 000000000..a5714eef2 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1908626 @@ -0,0 +1,68 @@ + + + +Atomic test-and-set instruction does not work on qemu-user + +I try to compile and run PostgreSQL/Greenplum database inside docker container/qemu-aarch64-static: +``` + host: CentOS7 x86_64 + container: centos:centos7.9.2009 --platform linux/arm64/v8 + qemu-user-static: https://github.com/multiarch/qemu-user-static/releases/ +``` + +However, GP/PG's spinlock always gets stuck and reports PANIC errors. It seems its spinlock +has something wrong. +``` +https://github.com/greenplum-db/gpdb/blob/master/src/include/storage/s_lock.h +https://github.com/greenplum-db/gpdb/blob/master/src/backend/storage/lmgr/s_lock.c +``` + +So I extract its spinlock implementation into one test C source file (see attachment file), +and get reprodcued: + +``` +$ gcc spinlock_qemu.c +$ ./a.out +C -- slock inited, lock value is: 0 +parent 139642, child 139645 +P -- slock lock before, lock value is: 0 +P -- slock locked, lock value is: 1 +P -- slock unlock after, lock value is: 0 +C -- slock lock before, lock value is: 1 +P -- slock lock before, lock value is: 1 +C -- slock locked, lock value is: 1 +C -- slock unlock after, lock value is: 0 +C -- slock lock before, lock value is: 1 +P -- slock locked, lock value is: 1 +P -- slock unlock after, lock value is: 0 +P -- slock lock before, lock value is: 1 +C -- slock locked, lock value is: 1 +C -- slock unlock after, lock value is: 0 +P -- slock locked, lock value is: 1 +C -- slock lock before, lock value is: 1 +P -- slock unlock after, lock value is: 0 +C -- slock locked, lock value is: 1 +P -- slock lock before, lock value is: 1 +C -- slock unlock after, lock value is: 0 +P -- slock locked, lock value is: 1 +C -- slock lock before, lock value is: 1 +P -- slock unlock after, lock value is: 0 +C -- slock locked, lock value is: 1 +P -- slock lock before, lock value is: 1 +C -- slock unlock after, lock value is: 0 +P -- slock locked, lock value is: 1 +C -- slock lock before, lock value is: 1 +P -- slock unlock after, lock value is: 0 +P -- slock lock before, lock value is: 1 +spin timeout, lock value is 1 (pid 139642) +spin timeout, lock value is 1 (pid 139645) +spin timeout, lock value is 1 (pid 139645) +spin timeout, lock value is 1 (pid 139642) +spin timeout, lock value is 1 (pid 139645) +spin timeout, lock value is 1 (pid 139642) +... +... +... +``` + +NOTE: this code always works on PHYSICAL ARM64 server. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1910 b/results/classifier/gemma3:27b/instruction/1910 new file mode 100644 index 000000000..cd18fcd56 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1910 @@ -0,0 +1,65 @@ + + + +Signal handlers in x86_64 userspace have wrongly aligned stack +Description of problem: +Various applications crash in signal handlers due to `movaps` getting a misaligned stack address. For some reason this is reported as a NULL deref, but `gdb` clearly shows the true cause. + +```plaintext +> qemu-x86_64 /usr/bin/ruby -e '`true`' +-e:1: [BUG] Segmentation fault at 0x0000000000000000 +ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux-gnu] + +-- Control frame information ----------------------------------------------- +c:0003 p:---- s:0011 e:000010 CFUNC :` +c:0002 p:0005 s:0006 e:000005 EVAL -e:1 [FINISH] +c:0001 p:0000 s:0003 E:0015b0 DUMMY [FINISH] + +-- Ruby level backtrace information ---------------------------------------- +-e:1:in `<main>' +-e:1:in ``' + +-- Machine register context ------------------------------------------------ + RIP: 0x00002aaaab50f98a RBP: 0x00002aaaabb136b8 RSP: 0x00002aaaab2a9c98 + RAX: 0x0000000000000000 RBX: 0x0000000000004946 RCX: 0x0000000000000000 + RDX: 0x00002aaaab2a9c98 RDI: 0x000000000caf0000 RSI: 0x0000000000000000 + R8: 0x00002aaaab2aaa50 R9: 0x0000000000000050 R10: 0x0000000000000008 + R11: 0x0000000000000000 R12: 0x0000000000000002 R13: 0x0000000000007310 + R14: 0x0000000000005e10 R15: 0x00002aaab0537f20 EFL: 0x0000000000000246 + +-- C level backtrace information ------------------------------------------- +``` + +```plaintext +(gdb) x/i $pc +=> 0x2aaaab50f98a: movaps %xmm0,(%rsp) +(gdb) p/x $rsp +$3 = 0x2aaaab2a9998 +``` +Steps to reproduce: +1. ```qemu-x86_64 /usr/bin/ruby -e '`true`'``` +Additional information: +The x86_64 psABI says: + +> the value (%rsp − 8) is always a multiple of 16 when control is transferred to the function entry point. + +However, when QEMU jumps to the signal handler, $rsp is aligned to 16B, i.e. ends in `0x..0`. + +The relevant kernel code: + +https://elixir.bootlin.com/linux/v6.5.5/source/arch/x86/kernel/signal.c#L123 + +```plaintext + sp -= frame_size; + + if (ia32_frame) + /* + * Align the stack pointer according to the i386 ABI, + * i.e. so that on function entry ((sp + 4) & 15) == 0. + */ + sp = ((sp + 4) & -FRAME_ALIGNMENT) - 4; + else + sp = round_down(sp, FRAME_ALIGNMENT) - 8; +``` + +CC @lvivier @bonzini @rth7680 diff --git a/results/classifier/gemma3:27b/instruction/1912934 b/results/classifier/gemma3:27b/instruction/1912934 new file mode 100644 index 000000000..93b930bf7 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1912934 @@ -0,0 +1,20 @@ + + + +QEMU emulation of fmadds instruction on powerpc64le is buggy + +The attached program test-fmadds.c tests the fmadds instruction on powerpc64le. + +Result on real hardware (POWER8E processor): +$ ./a.out ; echo $? +0 + +Result in Alpine Linux 3.13/powerpcle, emulated by QEMU 5.0.0 on Ubuntu 16.04: +$ ./a.out ; echo $? +32 + +Result in Debian 8.6.0/ppc64el, emulated by QEMU 2.9.0 on Ubuntu 16.04: +$ ./a.out ; echo $? +32 + +Through 'nm --dynamic qemu-system-ppc64 | grep fma' I can see that QEMU is NOT using the fmaf() or fma() function from the host system's libc; this function is working fine in glibc of the host system (see https://www.gnu.org/software/gnulib/manual/html_node/fmaf.html ). \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1913913 b/results/classifier/gemma3:27b/instruction/1913913 new file mode 100644 index 000000000..65ce919d2 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1913913 @@ -0,0 +1,21 @@ + + + +i386-linux-user returns -1 in sigcontext->trapno + +QEMU development version, git commit 74208cd252c5da9d867270a178799abd802b9338. Behaviour has been noted in 5.2.0 generally. + +Certain 16-bit windows programs crash WINE under QEMU linux-user with: + +0084:err:seh:segv_handler Got unexpected trap -1 +wine: Unhandled illegal instruction at address 00006D65 (thread 0084), starting debugger... + +They run correctly on native i386. + +Upon further inspection,it becomes clear these programs are failing at addresses where they are making DOS calls (int 21h ie CD 21 for instance). + +It is also clear that WINE is expecting an exception/signal at this point, to patch in the actual int21h handling code inside WINE. + +However, wine uses sigcontext output extensively to do its structured exception handling. sigcontext->trapno being set to -1 seems to confuse it, causing it to treat the exception as an actual unhandled error. + +I do not know if exception_index is being left at -1 due to the case of privileged instructions being executed in 16-bit ldts not being handled specifically, or if there is some other illegal instruction case causing this. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1914021 b/results/classifier/gemma3:27b/instruction/1914021 new file mode 100644 index 000000000..3287d096f --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1914021 @@ -0,0 +1,30 @@ + + + +qemu: uncaught target signal 4 (Illegal instruction) but gdb remote-debug exited normally + +I'm getting Illegal instruction (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. + +readelf -h a.out_err +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: 0x8220 + Start of program headers: 52 (bytes into file) + Start of section headers: 54228 (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: 3 + Size of section headers: 40 (bytes) + Number of section headers: 16 + Section header string table index: 15 + +qemu-arm version 4.0.0 \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1914870 b/results/classifier/gemma3:27b/instruction/1914870 new file mode 100644 index 000000000..9a7c055ba --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1914870 @@ -0,0 +1,60 @@ + + + +libvixl compilation failure on Debian unstable + +As of commit 0e324626306: + +$ lsb_release -d +Description: Debian GNU/Linux bullseye/sid + +Project version: 5.2.50 +C compiler for the host machine: cc (gcc 10.2.1 "cc (Debian 10.2.1-6) 10.2.1 20210110") +C linker for the host machine: cc ld.bfd 2.35.1 +C++ compiler for the host machine: c++ (gcc 10.2.1 "c++ (Debian 10.2.1-6) 10.2.1 20210110") +C++ linker for the host machine: c++ ld.bfd 2.35.1 + +[6/79] Compiling C++ object libcommon.fa.p/disas_libvixl_vixl_utils.cc.o +FAILED: libcommon.fa.p/disas_libvixl_vixl_utils.cc.o +c++ -Ilibcommon.fa.p -I. -I.. -Iqapi -Itrace -Iui/shader -I/usr/include/capstone -I/usr/include/glib-2.0 -I/usr/lib/hppa-linux-gnu/glib-2.0/include -fdiagnostics-color=auto -pipe -Wall -Winvalid-pch -Wnon-virtual-dtor -Werror -std=gnu++11 -O2 -g -isystem /home/philmd/qemu/linux-headers -isystem linux-headers -iquote . -iquote /home/philmd/qemu -iquote /home/philmd/qemu/include -iquote /home/philmd/qemu/disas/libvixl -iquote /home/philmd/qemu/tcg/hppa -iquote /home/philmd/qemu/accel/tcg -pthread -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wundef -Wwrite-strings -fno-strict-aliasing -fno-common -fwrapv -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wendif-labels -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi -fPIE -MD -MQ libcommon.fa.p/disas_libvixl_vixl_utils.cc.o -MF libcommon.fa.p/disas_libvixl_vixl_utils.cc.o.d -o libcommon.fa.p/disas_libvixl_vixl_utils.cc.o -c ../disas/libvixl/vixl/utils.cc +In file included from /home/philmd/qemu/disas/libvixl/vixl/utils.h:30, + from ../disas/libvixl/vixl/utils.cc:27: +/usr/include/string.h:36:43: error: missing binary operator before token "(" + 36 | #if defined __cplusplus && (__GNUC_PREREQ (4, 4) \ + | ^ +/usr/include/string.h:53:62: error: missing binary operator before token "(" + 53 | #if defined __USE_MISC || defined __USE_XOPEN || __GLIBC_USE (ISOC2X) + | ^ +/usr/include/string.h:165:21: error: missing binary operator before token "(" + 165 | || __GLIBC_USE (LIB_EXT2) || __GLIBC_USE (ISOC2X)) + | ^ +/usr/include/string.h:174:43: error: missing binary operator before token "(" + 174 | #if defined __USE_XOPEN2K8 || __GLIBC_USE (LIB_EXT2) || __GLIBC_USE (ISOC2X) + | ^ +/usr/include/string.h:492:19: error: missing binary operator before token "(" + 492 | #if __GNUC_PREREQ (3,4) + | ^ +In file included from /home/philmd/qemu/disas/libvixl/vixl/utils.h:30, + from ../disas/libvixl/vixl/utils.cc:27: +/usr/include/string.h:28:1: error: ‘__BEGIN_DECLS’ does not name a type + 28 | __BEGIN_DECLS + | ^~~~~~~~~~~~~ +In file included from /home/philmd/qemu/disas/libvixl/vixl/utils.h:30, + from ../disas/libvixl/vixl/utils.cc:27: +/usr/include/string.h:44:8: error: ‘size_t’ has not been declared + 44 | size_t __n) __THROW __nonnull ((1, 2)); + | ^~~~~~ +/usr/include/string.h:44:20: error: expected initializer before ‘__THROW’ + 44 | size_t __n) __THROW __nonnull ((1, 2)); + | ^~~~~~~ +/usr/include/string.h:47:56: error: ‘size_t’ has not been declared + 47 | extern void *memmove (void *__dest, const void *__src, size_t __n) + | ^~~~~~ +/usr/include/string.h:48:6: error: expected initializer before ‘__THROW’ + 48 | __THROW __nonnull ((1, 2)); + | ^~~~~~~ +/usr/include/string.h:61:42: error: ‘size_t’ has not been declared + 61 | extern void *memset (void *__s, int __c, size_t __n) __THROW __nonnull ((1)); + | ^~~~~~ + +Is there a package dependency missing? \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1915327 b/results/classifier/gemma3:27b/instruction/1915327 new file mode 100644 index 000000000..5651f2a1f --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1915327 @@ -0,0 +1,37 @@ + + + +x86_64 cmpxchg behavior in qemu tcg does not match the real CPU + +QEMU version: +1214d55d1c (HEAD, origin/master, origin/HEAD) Merge remote-tracking branch 'remotes/nvme/tags/nvme-next-pull-request' into staging + +Consider the following little program: + +$ cat 1.c +#include <stdio.h> +int main() { + int mem = 0x12345678; + register long rax asm("rax") = 0x1234567812345678; + register int edi asm("edi") = 0x77777777; + asm("cmpxchg %[edi],%[mem]" + : [ mem ] "+m"(mem), [ rax ] "+r"(rax) + : [ edi ] "r"(edi)); + long rax2 = rax; + printf("rax2 = %lx\n", rax2); +} + +According to the Intel Manual, cmpxchg should not touch the accumulator in case the values are equal, which is indeed the case on the real CPU: + +$ gcc 1.c +$ ./a.out +rax2 = 1234567812345678 + +However, QEMU appears to zero extend EAX to RAX: + +$ qemu-x86_64 ./a.out +rax2 = 12345678 + +This is also the case for lock cmpxchg. + +Found in BPF development context: https://lore<email address hidden> \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1916269 b/results/classifier/gemma3:27b/instruction/1916269 new file mode 100644 index 000000000..6c64e5313 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1916269 @@ -0,0 +1,22 @@ + + + +TCG: QEMU incorrectly raises exception on SSE4.2 CRC32 instruction + +If I run FreeBSD on QEMU 5.2 with TCG acceleration -cpu Nehalem, I get a FPU exception when executing crc32 (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253617). This is not a problem with the default CPU (or KVM) since that does not support SSE 4.2. + +Attaching GDB shows this is triggered in target/i386/tcg/translate.c:3067 + + /* simple MMX/SSE operation */ + if (s->flags & HF_TS_MASK) { + gen_exception(s, EXCP07_PREX, pc_start - s->cs_base); + return; + } + +However, according to https://software.intel.com/sites/default/files/m/8/b/8/D9156103.pdf, page 61 the CRC32 instruction works no matter what the value of the TS bit. + +The code sequence in question is: +0xffffffff8105a4de <+126>: f2 48 0f 38 f1 de crc32q %rsi,%rbx +0xffffffff8105a4e4 <+132>: f2 48 0f 38 f1 ca crc32q %rdx,%rcx. + +This should work even with the FPU disabled. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1918026 b/results/classifier/gemma3:27b/instruction/1918026 new file mode 100644 index 000000000..17a762155 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1918026 @@ -0,0 +1,32 @@ + + + +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/gemma3:27b/instruction/1922887 b/results/classifier/gemma3:27b/instruction/1922887 new file mode 100644 index 000000000..1cdbb541c --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1922887 @@ -0,0 +1,33 @@ + + + +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/gemma3:27b/instruction/1925512 b/results/classifier/gemma3:27b/instruction/1925512 new file mode 100644 index 000000000..a847cd79a --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1925512 @@ -0,0 +1,21 @@ + + + +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/gemma3:27b/instruction/1926202 b/results/classifier/gemma3:27b/instruction/1926202 new file mode 100644 index 000000000..8a2a96e8b --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1926202 @@ -0,0 +1,21 @@ + + + +qemu-user can't run some ppc binaries + +qemu-user v6.0.0-rc5, built in static mode, will crash for certain ppc binaries. It seems to have something to do with glibc for some Centos versions. The problem is easiest to see with statically-linked binaries. + +The attached Dockerfile shows how to produce a ppc binary that will crash qemu-user. Here is how to reproduce the problem: + +$ uname -m +x86_64 +$ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes +$ docker build -t qemu-bug:centos -f Dockerfile.centos . +$ docker run --rm -it -v$PWD:$PWD -w$PWD qemu-bug:centos cp /helloworld-centos.static.ppc . +$ qemu-ppc version 5.2.95 (v6.0.0-rc5) +Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers +$ qemu-ppc-static ./helloworld-centos.static.ppc +emu: uncaught target signal 4 (Illegal instruction) - core dumped +[1] 16678 illegal hardware instruction (core dumped) qemu-ppc-static ./helloworld-centos.static.ppc + +I can also provide the binary if necessary. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1926759 b/results/classifier/gemma3:27b/instruction/1926759 new file mode 100644 index 000000000..437445902 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1926759 @@ -0,0 +1,21 @@ + + + +WFI instruction results in unhandled CPU exception + +Hi + +I refer to the WFI instruction. The bytecode is 0xe320f003. After the execution, qemu exit with the following crash log. + +qemu: unhandled CPU exception 0x10001 - aborting +R00=00000001 R01=40800b34 R02=40800b3c R03=000102ec +R04=00010a28 R05=00010158 R06=00087460 R07=00010158 +R08=00000000 R09=00000000 R10=00085b7c R11=408009f4 +R12=40800a08 R13=408009f0 R14=0001057c R15=000102f8 +PSR=60000010 -ZC- A usr32 +qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x7f5c21d0fa12 + +WFI aims to enter a low-power state and wait for interrupt. The raised exception seems not a right behavior. I can provide a testcase if you needed. Many thanks. + +Regards +Muhui \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/1941 b/results/classifier/gemma3:27b/instruction/1941 new file mode 100644 index 000000000..4624fd6d6 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1941 @@ -0,0 +1,105 @@ + + + +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/gemma3:27b/instruction/1955 b/results/classifier/gemma3:27b/instruction/1955 new file mode 100644 index 000000000..17cd3a9de --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1955 @@ -0,0 +1,39 @@ +instruction: 0.950 +graphic: 0.840 +semantic: 0.801 +device: 0.645 +other: 0.493 +socket: 0.420 +network: 0.394 +mistranslation: 0.346 +boot: 0.280 +vnc: 0.269 +assembly: 0.183 +KVM: 0.107 + +powerpc instruction 'mffsl' not emulated on POWER8 +Description of problem: +Since 2019, the function feenableexcept() in GNU libc makes use of the "mffsl" instruction. +See https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/powerpc/fpu/feenablxcpt.c;h=b111ceaa4e2e1864fcbe043ccda34e03e9f14062;hb=HEAD#l28 +and https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/powerpc/fpu/fenv_libc.h;h=a2a12d914b47e99746003482b349a0675cc5ad34;hb=HEAD#l57 + +In the emulated Debian system, executables that make use of this instruction crash with SIGILL. +Likewise, under gdb (in the emulated system), there is a SIGILL at the 'mffsl' instruction. + +From the comments in the above glibc source, added by Paul A. Clarke <pc@us.ibm.com>: + "Nicely, it turns out that the 'mffsl' instruction will decode to + 'mffs' on architectures older than "power9" because the additional + bits set for 'mffsl' are "don't care" for 'mffs'. 'mffs' is a superset + of 'mffsl'." + +This is indeed what I observe by compiling and running the attached program foo.c on a hardware machine with a POWER8 CPU: That program does not crash with a SIGILL. +Steps to reproduce: +1. Either run the attached 'test-fenv-except-tracking-5.ppc' (32-bit) program under qemu-system-ppc. +2. Or run the the attached 'test-fenv-except-tracking-5.ppc64' (64-bit) program under qemu-system-ppc64 with -cpu POWER8. +3. Or compile and run the attached foo.c and run it under QEMU. +Additional information: +[test-fenv-except-tracking-5.ppc.xz](/uploads/8222ebac115e8a865d5e520b25d423ff/test-fenv-except-tracking-5.ppc.xz) + +[test-fenv-except-tracking-5.ppc64.xz](/uploads/d0522723541a46e11ab55b8f45dfb574/test-fenv-except-tracking-5.ppc64.xz) + +[foo.c](/uploads/35d8b3b1e5b39ecb6a2a899132858ded/foo.c) diff --git a/results/classifier/gemma3:27b/instruction/1967248 b/results/classifier/gemma3:27b/instruction/1967248 new file mode 100644 index 000000000..c84ead78a --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/1967248 @@ -0,0 +1,41 @@ + + + +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/gemma3:27b/instruction/2078 b/results/classifier/gemma3:27b/instruction/2078 new file mode 100644 index 000000000..73f219935 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2078 @@ -0,0 +1,37 @@ + + + +Qemu crashes with SIGFPE on certain trapping arithmetic operations on m68k target +Description of problem: +I recently ported NetBSD to the Qemu m68k "virt" platform, and this was discovered when running NetBSD's automated tests. Certain arithmetic operation that will trap in the guest will crash Qemu. First case encountered is below. +Steps to reproduce: +1. Compile and run the following program in the m68k guest: + +``` +virt68k:thorpej 3$ cat crash-qemu.c +#include <limits.h> +#include <stdlib.h> + +int divisor = -1; + +int +main(int argc, char *argv[]) +{ + + if (argc > 1) + divisor = atoi(argv[1]); + + return INT_MIN / divisor; +} +virt68k:thorpej 4$ +``` + +Another minimal case would be: + +``` +move.l #-2147483648,%d0 +move.l #-1,%d1 +divsl.l %d1,%d1:%d0 +``` +Additional information: + diff --git a/results/classifier/gemma3:27b/instruction/2083 b/results/classifier/gemma3:27b/instruction/2083 new file mode 100644 index 000000000..ca2fcabbd --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2083 @@ -0,0 +1,114 @@ + + + +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/gemma3:27b/instruction/2089 b/results/classifier/gemma3:27b/instruction/2089 new file mode 100644 index 000000000..42ff91e11 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2089 @@ -0,0 +1,30 @@ + + + +aarch64: incorrect emulation of sqshrn instruction +Description of problem: +`sqshrn` instruction test fails with qemu-aarch64, but passes on real aarch64 hardware. +Steps to reproduce: +1. Build [inline_asm_tests](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/libs/binary_translation/tests/inline_asm_tests/) and run with qemu-aarch64 +2. Observe two failures + +``` +[ RUN ] Arm64InsnTest.SignedSaturatingShiftRightNarrowInt16x1 +frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc:6697: Failure +Expected equality of these values: + res1 + Which is: 4294967188 + MakeUInt128(0x94U, 0U) + Which is: 148 +[ FAILED ] Arm64InsnTest.SignedSaturatingShiftRightNarrowInt16x1 (5 ms) +[ RUN ] Arm64InsnTest.SignedSaturatingRoundingShiftRightNarrowInt16x1 +frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc:6793: Failure +Expected equality of these values: + res3 + Which is: 4294967168 + MakeUInt128(0x0000000000000080ULL, 0x0000000000000000ULL) + Which is: 128 +[ FAILED ] Arm64InsnTest.SignedSaturatingRoundingShiftRightNarrowInt16x1 (2 ms) +``` +Additional information: +[Direct link to SignedSaturatingShiftRightNarrowInt16x1 test source](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/libs/binary_translation/tests/inline_asm_tests/main_arm64.cc;l=6692;drc=4ee2c3035fa5dc0b7a48b6c6dc498296be071861) diff --git a/results/classifier/gemma3:27b/instruction/2136 b/results/classifier/gemma3:27b/instruction/2136 new file mode 100644 index 000000000..20d62a582 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2136 @@ -0,0 +1,38 @@ + + + +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/gemma3:27b/instruction/2175 b/results/classifier/gemma3:27b/instruction/2175 new file mode 100644 index 000000000..1ed7e24f6 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2175 @@ -0,0 +1,41 @@ + + + +Intel BLSI CF computation bug +Description of problem: +CF flag computation of BLSI instruction is wrong. It seems #1370 was not completely fixed. +Steps to reproduce: +1. Compile `example.c` using this command: `gcc -o example.bin example.c`. My gcc version is 12.3.0, but other versions may work. +``` +int main() { + __asm__ ( + "movq $0x1, %r8\n" + "mov $0xedbf530a, %r9\n" + "push $0x1\n" + "popf\n" + "blsi %r9d, %r8d\n" + "pushf\n" + "pop %rax\n" + "pop %rbp\n" + "ret\n" + ); + + return 0; +} +``` +2. Run `./example.bin`. Then check the return code using `echo $?`. It should be 3. +``` +$ ./example.bin +$ echo $? +3 +``` +3. Run `./qemu-x86_64 ./example.bin`. Then check the return code using `echo $?`. It should be 2. +``` +$ ./qemu-x86_64 ./example.bin +$ echo $? +2 +``` + +The return code of `./example.bin` contains the value of the `RFLAGS` register after executing the `BLSI` instruction. +Additional information: + diff --git a/results/classifier/gemma3:27b/instruction/2203 b/results/classifier/gemma3:27b/instruction/2203 new file mode 100644 index 000000000..b2e549ee0 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2203 @@ -0,0 +1,4 @@ + + + +RISC-V RVV fractional LMUL check is wrong diff --git a/results/classifier/gemma3:27b/instruction/2208 b/results/classifier/gemma3:27b/instruction/2208 new file mode 100644 index 000000000..aceb5eff3 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2208 @@ -0,0 +1,91 @@ + + + +PC is not updated for each instruction in TCG plugins +Description of problem: +I have checkout the `master` branch (the latest available commit on my machine is *7d4e29ef80*) to test the new functions that allow plugins to read registers. See https://gitlab.com/qemu-project/qemu/-/issues/1706 that has been closed last Friday. + +I am using a simple hello-world binary for ARM for my tests: + +```bash +% ./qemu-aarch64 hello-world.out +Hello World! +``` + +I run this binary with the *execlog* plugin enabled, and with the `-one-insn-per-tb` option: + +```bash +% ./qemu-aarch64 -d plugin -plugin ./contrib/plugins/libexeclog.so,reg=pc -one-insn-per-tb hello-world.out +``` + +Here is the end of the execution: + +```raw +0, 0x40e470, 0x54000040, "b.eq #0x40e478", pc -> 0x00000000000040e474 +0, 0x40e474, 0xd65f03c0, "ret ", pc -> 0x00000000000040d38c +0, 0x40d38c, 0xf945fab5, "ldr x21, [x21, #0xbf0]", load, 0x00490bf0, pc -> 0x00000000000040d390 +0, 0x40d390, 0xf9404fe0, "ldr x0, [sp, #0x98]", load, 0x7f635a9e7f28, pc -> 0x00000000000040d394 +0, 0x40d394, 0xf94002a1, "ldr x1, [x21]", load, 0x0048f9e8, pc -> 0x00000000000040d398 +0, 0x40d398, 0xeb010000, "subs x0, x0, x1", pc -> 0x00000000000040d39c +0, 0x40d39c, 0xd2800001, "movz x1, #0", pc -> 0x00000000000040d3a0 +0, 0x40d3a0, 0x540006e1, "b.ne #0x40d47c", pc -> 0x00000000000040d3a4 +0, 0x40d3a4, 0x2a1903e0, "mov w0, w25", pc -> 0x00000000000040d3a8 +0, 0x40d3a8, 0xa94153f3, "ldp x19, x20, [sp, #0x10]", load, 0x7f635a9e7ea0, pc -> 0x00000000000040d3ac +0, 0x40d3ac, 0xa9425bf5, "ldp x21, x22, [sp, #0x20]", load, 0x7f635a9e7eb0, pc -> 0x00000000000040d3b0 +0, 0x40d3b0, 0xa94363f7, "ldp x23, x24, [sp, #0x30]", load, 0x7f635a9e7ec0, pc -> 0x00000000000040d3b4 +0, 0x40d3b4, 0xa9446bf9, "ldp x25, x26, [sp, #0x40]", load, 0x7f635a9e7ed0, pc -> 0x00000000000040d3b8 +0, 0x40d3b8, 0xa8ca7bfd, "ldp x29, x30, [sp], #0xa0", load, 0x7f635a9e7e90, pc -> 0x00000000000040d3bc +0, 0x40d3bc, 0xd65f03c0, "ret ", pc -> 0x000000000000405d80 +0, 0x405d80, 0xeb13029f, "cmp x20, x19", pc -> 0x000000000000405d84 +0, 0x405d84, 0x91000694, "add x20, x20, #1", pc -> 0x000000000000405d88 +0, 0x405d88, 0x54ffff81, "b.ne #0x405d78", pc -> 0x000000000000405d8c +0, 0x405d8c, 0x2a1703e0, "mov w0, w23", pc -> 0x000000000000405d90 +0, 0x405d90, 0x94004c20, "bl #0x418e10", pc -> 0x000000000000418e10 +0, 0x418e10, 0x93407c02, "sxtw x2, w0", pc -> 0x000000000000418e14 +0, 0x418e14, 0x900003c4, "adrp x4, #0x490000", pc -> 0x000000000000418e18 +0, 0x418e18, 0xf946f084, "ldr x4, [x4, #0xde0]", load, 0x00490de0, pc -> 0x000000000000418e1c +0, 0x418e1c, 0xd53bd043, "mrs x3, tpidr_el0", pc -> 0x000000000000418e20 +0, 0x418e20, 0xaa0203e0, "mov x0, x2", pc -> 0x000000000000418e24 +0, 0x418e24, 0xd2800bc8, "movz x8, #0x5e", pc -> 0x000000000000418e28 +0, 0x418e28, 0xd4000001, "svc #0" +``` + +Now, here is the same part of the execution but without the `-one-insn-per-tb` option: + +```raw +0, 0x40e470, 0x54000040, "b.eq #0x40e478" +0, 0x40e474, 0xd65f03c0, "ret ", pc -> 0x00000000000040d38c +0, 0x40d38c, 0xf945fab5, "ldr x21, [x21, #0xbf0]", load, 0x00490bf0 +0, 0x40d390, 0xf9404fe0, "ldr x0, [sp, #0x98]", load, 0x7f4d42108f28 +0, 0x40d394, 0xf94002a1, "ldr x1, [x21]", load, 0x0048f9e8 +0, 0x40d398, 0xeb010000, "subs x0, x0, x1" +0, 0x40d39c, 0xd2800001, "movz x1, #0" +0, 0x40d3a0, 0x540006e1, "b.ne #0x40d47c", pc -> 0x00000000000040d3a4 +0, 0x40d3a4, 0x2a1903e0, "mov w0, w25" +0, 0x40d3a8, 0xa94153f3, "ldp x19, x20, [sp, #0x10]", load, 0x7f4d42108ea0 +0, 0x40d3ac, 0xa9425bf5, "ldp x21, x22, [sp, #0x20]", load, 0x7f4d42108eb0 +0, 0x40d3b0, 0xa94363f7, "ldp x23, x24, [sp, #0x30]", load, 0x7f4d42108ec0 +0, 0x40d3b4, 0xa9446bf9, "ldp x25, x26, [sp, #0x40]", load, 0x7f4d42108ed0 +0, 0x40d3b8, 0xa8ca7bfd, "ldp x29, x30, [sp], #0xa0", load, 0x7f4d42108e90 +0, 0x40d3bc, 0xd65f03c0, "ret ", pc -> 0x000000000000405d80 +0, 0x405d80, 0xeb13029f, "cmp x20, x19" +0, 0x405d84, 0x91000694, "add x20, x20, #1" +0, 0x405d88, 0x54ffff81, "b.ne #0x405d78", pc -> 0x000000000000405d8c +0, 0x405d8c, 0x2a1703e0, "mov w0, w23" +0, 0x405d90, 0x94004c20, "bl #0x418e10", pc -> 0x000000000000418e10 +0, 0x418e10, 0x93407c02, "sxtw x2, w0" +0, 0x418e14, 0x900003c4, "adrp x4, #0x490000" +0, 0x418e18, 0xf946f084, "ldr x4, [x4, #0xde0]", load, 0x00490de0 +0, 0x418e1c, 0xd53bd043, "mrs x3, tpidr_el0" +0, 0x418e20, 0xaa0203e0, "mov x0, x2" +0, 0x418e24, 0xd2800bc8, "movz x8, #0x5e" +0, 0x418e28, 0xd4000001, "svc #0" +``` + +The [documentation](https://www.qemu.org/docs/master/devel/tcg-plugins.html) says: + +> This plugin can also dump registers when they change value. Specify the name of the registers with multiple reg options. + +The `pc` register changes for each instruction. I would expect the plugin to produce the same output with or without the `-one-insn-per-tb` option. +Additional information: +The code that prints "pc -> 0x......" is in `insn_check_regs()` in `contrib/plugins/execlog.c`. It uses the new `qemu_plugin_read_register()` function and compares the new value to the previous value. The code seems OK. It means that the implementation of `qemu_plugin_read_register()` gets the same value several times in a row, instead of a new value each time. diff --git a/results/classifier/gemma3:27b/instruction/2248 b/results/classifier/gemma3:27b/instruction/2248 new file mode 100644 index 000000000..9a2f29fd8 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2248 @@ -0,0 +1,39 @@ + + + +qemu-aarch64: wrong execution result when executing the code +Description of problem: +The following aarch64 code results in the wrong execution result `4611686018427387903`, which is `0x3fffffffffffffff`. (The correct result is `-1`) The bug seems to be introduced in between v8.1.5 and v8.2.1 since the results are correct in v8.1.5. + +```c +// foo.c +#include <stdio.h> +#include <stdint.h> + +int64_t callme(size_t _1, size_t _2, int64_t a, int64_t b, int64_t c); + +int main() { + int64_t ret = callme(0, 0, 0, 1, 2); + printf("%ld\n", ret); + return 0; +} +``` + +```s +// foo.S +.global callme +callme: + cmp x2, x3 + cset x12, lt + and w11, w12, #0xff + cmp w11, #0x0 + csetm x14, ne + lsr x13, x14, x4 + sxtb x0, w13 + ret +``` +Steps to reproduce: +1. Build the code with `aarch64-linux-gnu-gcc foo.c foo.S -o foo` (`aarch64-linux-gnu-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0`) +2. Run the code with `qemu-aarch64 -L /usr/aarch64-linux-gnu -E LD_LIBRARY_PATH=/usr/aarch64-linux-gnu/lib foo` and see the result +Additional information: +- Original discussion is held in [this wasmtime issue](https://github.com/bytecodealliance/wasmtime/issues/8233). Thanks to Alex Crichton for clarifying this bug. diff --git a/results/classifier/gemma3:27b/instruction/2302 b/results/classifier/gemma3:27b/instruction/2302 new file mode 100644 index 000000000..687b2201f --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2302 @@ -0,0 +1,28 @@ + + + +qemu-x86_64 crashes with "Illegal Instruction" on SPECCPU2017 Benchmarks +Description of problem: +I am running qemu-x86_64 with SPEC CPU 2017 benchmarks, and the compiled benchmarks such as Perlbench will crash unexpectedly. I have changed to three other machines to run it and still get crashes on two of them, I don't know what's the problem and want some help. +Steps to reproduce: +1. Compile SPEC CPU 2017 basic Perlbench binary. +2. Use the above command line to run it. +Additional information: +I have added some debugging flags to qemu-x86_64 to test it. The "-d in_asm" flag gives me the instructions before the crash like this: +``` +---------------- +IN: Perl_lex_start +0x555555678a79: 48 89 83 a8 00 00 00 movq %rax, 0xa8(%rbx) +0x555555678a80: e9 01 ff ff ff jmp 0x555555678986 + +---------------- +IN: Perl_lex_start +0x555555678986: 48 8b 50 10 movq 0x10(%rax), %rdx +0x55555567898a: 41 83 e4 16 andl $0x16, %r12d +0x55555567898e: 48 89 93 d0 00 00 00 movq %rdx, 0xd0(%rbx) +0x555555678995: 48 89 93 c0 00 00 00 movq %rdx, 0xc0(%rbx) +0x55555567899c: 62 .byte 0x62 + +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction (core dumped) +``` diff --git a/results/classifier/gemma3:27b/instruction/2317 b/results/classifier/gemma3:27b/instruction/2317 new file mode 100644 index 000000000..34e976a1c --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2317 @@ -0,0 +1,41 @@ + + + +SH4: ADDV instruction not emulated properly +Description of problem: +ADDV opcode is emulated incorrectly. + +The documentation says: + +`ADDV Rm, Rn Rn + Rm -> Rn, overflow -> T` + +What Qemu actually emulates: + +`ADDV Rm, Rn Rn + Rm -> Rm, overflow -> T` +Steps to reproduce: +```c +#include <stdio.h> + +int main(void) +{ + register unsigned int a asm("r8") = 0x7fffffff; + register unsigned int b asm("r9") = 1; + register unsigned int c asm("r10"); + + asm volatile("clrt\n" + "addv %2,%0\n" + "movt %1\n" + : "+r"(a), "=r"(c) : "r"(b) :); + + printf("Values: a=0x%x b=0x%x c=0x%x\n", a, b, c); + + return 0; +} + +``` +Additional information: +Tested on real hardware (SEGA Dreamcast, GCC 15.0), the program above prints: +`Values: a=0x80000000 b=0x1 c=0x1` + +Running with Qemu (and GCC 13.0), the same program prints: +`Values: a=0x7fffffff b=0x80000000 c=0x1` diff --git a/results/classifier/gemma3:27b/instruction/2318 b/results/classifier/gemma3:27b/instruction/2318 new file mode 100644 index 000000000..9ed785f09 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2318 @@ -0,0 +1,37 @@ + + + +SH4: SUBV instruction not emulated properly +Description of problem: +SUBV opcode is emulated incorrectly. + +The documentation says: + +`SUBV Rm, Rn Rn - Rm -> Rn, underflow -> T` + +Qemu seems to perform the subtraction correctly, but will not detect an underflow. +Steps to reproduce: +```c +#include <stdio.h> + +int main(void) +{ + register unsigned int a asm("r8") = 0x80000001; + register unsigned int b asm("r9") = 0x2; + register unsigned int c asm("r10"); + + asm volatile("subv %2,%0\n" + "movt %1\n" + : "+r"(a), "=r"(c) : "r"(b) :); + + printf("Values: a=0x%x b=0x%x c=0x%x\n", a, b, c); + + return 0; +} +``` +Additional information: +Tested on real hardware (SEGA Dreamcast, GCC 15.0), the program above prints: +`Values: a=0x7fffffff b=0x2 c=0x1` + +Running with Qemu (and GCC 13.0), the same program prints: +`Values: a=0x7fffffff b=0x2 c=0x0` diff --git a/results/classifier/gemma3:27b/instruction/2319 b/results/classifier/gemma3:27b/instruction/2319 new file mode 100644 index 000000000..98e922d21 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2319 @@ -0,0 +1,20 @@ + + + +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/gemma3:27b/instruction/2371 b/results/classifier/gemma3:27b/instruction/2371 new file mode 100644 index 000000000..9a778851f --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2371 @@ -0,0 +1,55 @@ + + + +A bug in RISC-V froundnx.h instruction +Description of problem: +According to the RISCV ISA manual, the froundnx.h instruction rounds a half-precision floating-point number in the source register to an integer and writes the integer, represented as a half-precision floating-point number, to the destination register. Because the values are stored in 64-bit width registers, they must be NaN-unboxed/boxed before/after the operation. When an input value lacks the proper form of NaN-boxing, it should be treated as a canonical NaN. +However, when an incorrectly NaN-boxed value is passed to froundnx.h, QEMU produces 0 instead of the canonical NaN. This is because there is a typo in the definition of helper_froundnx_h: +``` +// target/riscv/fpu_helper.c +uint64_t helper_froundnx_h(CPURISCVState *env, uint64_t rs1) +{ + float16 frs1 = check_nanbox_s(env, rs1); // This should be check_nanbox_h. + frs1 = float16_round_to_int(frs1, &env->fp_status); + return nanbox_h(env, frs1); +} +``` +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdio.h> + +char i_F6[8] = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 }; +char o_F5[8]; + +void __attribute__ ((noinline)) show_state() { + for (int i = 0; i < 8; i++) { + printf("%02x ", o_F5[i]); + } + printf("\n"); +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + "lui t5, %hi(i_F6)\n" + "addi t5, t5, %lo(i_F6)\n" + "fld ft6, 0(t5)\n" + ".insn 0x445372d3\n" // froundnx.h ft5, ft6 + "lui t5, %hi(o_F5)\n" + "addi t5, t5, %lo(o_F5)\n" + "fsd ft5, 0(t5)\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + + return 0; +} +``` +2. Compile `test.bin` using this command: `riscv64-linux-gnu-gcc-12 -O2 -no-pie -march=rv64iv ./test.c -o ./test.bin`. +3. Run QEMU using this command: `qemu-riscv64 -L /usr/riscv64-linux-gnu/ ./test.bin`. +4. The program, runs on top of the buggy QEMU, prints `00 00 ff ff ff ff ff ff`. It should print `00 7e ff ff ff ff ff ff` after the bug is fixed. +Additional information: + diff --git a/results/classifier/gemma3:27b/instruction/2372 b/results/classifier/gemma3:27b/instruction/2372 new file mode 100644 index 000000000..007c25eab --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2372 @@ -0,0 +1,112 @@ + + + +A bug in AArch64 UMOPA/UMOPS (4-way) instruction +Description of problem: +umopa computes the multiplication of two matrices in the source registers and accumulates the result to the destination register. A source register’s element size is 16 bits, while a destination register’s element size is 64 bits in case of the 4-way variant of this instruction. Before performing matrix multiplication, each element should be zero-extended to a 64-bit element. + +However, the current implementation of the helper function fails to convert the element type correctly. Below is the helper function implementation: +``` +// target/arm/tcg/sme_helper.c +#define DEF_IMOP_64(NAME, NTYPE, MTYPE) \ +static uint64_t NAME(uint64_t n, uint64_t m, uint64_t a, uint8_t p, bool neg) \ +{ \ + uint64_t sum = 0; \ + /* Apply P to N as a mask, making the inactive elements 0. */ \ + n &= expand_pred_h(p); \ + sum += (NTYPE)(n >> 0) * (MTYPE)(m >> 0); \ + sum += (NTYPE)(n >> 16) * (MTYPE)(m >> 16); \ + sum += (NTYPE)(n >> 32) * (MTYPE)(m >> 32); \ + sum += (NTYPE)(n >> 48) * (MTYPE)(m >> 48); \ + return neg ? a - sum : a + sum; \ +} + +DEF_IMOP_64(umopa_d, uint16_t, uint16_t) +``` +When the multiplication is performed, each element, such as `(NTYPE)(n >> 0)`, is automatically converted to `int32_t`, so the computation result has a type `int32_t`. The result is then converted to `uint64_t`, and it is added to `sum`. It seems the elements should be casted to `uint64_t` **before** performing the multiplication. +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdio.h> + +char i_P1[4] = { 0xff, 0xff, 0xff, 0xff }; +char i_P5[4] = { 0xff, 0xff, 0xff, 0xff }; +char i_Z0[32] = { // Set only the first element as non-zero + 0xff, 0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, +}; +char i_Z20[32] = { // Set only the first element as non-zero + 0xff, 0xff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, +}; +char i_ZA2H[128] = { 0x0, }; +char o_ZA2H[128]; + +void __attribute__ ((noinline)) show_state() { + for (int i = 0; i < 8; i++) { + for (int j = 0; j < 16; j++) { + printf("%02x ", o_ZA2H[16*i+j]); + } + printf("\n"); + } +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + ".arch armv9.3-a+sme\n" + "smstart\n" + "adrp x29, i_P1\n" + "add x29, x29, :lo12:i_P1\n" + "ldr p1, [x29]\n" + "adrp x29, i_P5\n" + "add x29, x29, :lo12:i_P5\n" + "ldr p5, [x29]\n" + "adrp x29, i_Z0\n" + "add x29, x29, :lo12:i_Z0\n" + "ldr z0, [x29]\n" + "adrp x29, i_Z20\n" + "add x29, x29, :lo12:i_Z20\n" + "ldr z20, [x29]\n" + "adrp x29, i_ZA2H\n" + "add x29, x29, :lo12:i_ZA2H\n" + "mov x15, 0\n" + "ld1d {za2h.d[w15, 0]}, p1, [x29]\n" + "add x29, x29, 32\n" + "ld1d {za2h.d[w15, 1]}, p1, [x29]\n" + "add x29, x29, 32\n" + "mov x15, 2\n" + "ld1d {za2h.d[w15, 0]}, p1, [x29]\n" + "add x29, x29, 32\n" + "ld1d {za2h.d[w15, 1]}, p1, [x29]\n" + ".inst 0xa1f43402\n" // umopa za2.d, p5/m, p1/m, z0.h, z20.h + "adrp x29, o_ZA2H\n" + "add x29, x29, :lo12:o_ZA2H\n" + "mov x15, 0\n" + "st1d {za2h.d[w15, 0]}, p1, [x29]\n" + "add x29, x29, 32\n" + "st1d {za2h.d[w15, 1]}, p1, [x29]\n" + "add x29, x29, 32\n" + "mov x15, 2\n" + "st1d {za2h.d[w15, 0]}, p1, [x29]\n" + "add x29, x29, 32\n" + "st1d {za2h.d[w15, 1]}, p1, [x29]\n" + "smstop\n" + ".arch armv8-a\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + return 0; +} +``` +2. Compile `test.bin` using this command: `aarch64-linux-gnu-gcc-12 -O2 -no-pie ./test.c -o ./test.bin`. +3. Run `QEMU` using this command: `qemu-aarch64 -L /usr/aarch64-linux-gnu/ -cpu max,sme256=on ./test.bin`. +4. The program, runs on top of the buggy QEMU, prints the first 8 bytes of `ZA2H` as `01 00 fe ff ff ff ff ff`. It should print `01 00 fe ff 00 00 00 00` after the bug is fixed. +Additional information: + diff --git a/results/classifier/gemma3:27b/instruction/2373 b/results/classifier/gemma3:27b/instruction/2373 new file mode 100644 index 000000000..57a05a745 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2373 @@ -0,0 +1,98 @@ + + + +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/gemma3:27b/instruction/2374 b/results/classifier/gemma3:27b/instruction/2374 new file mode 100644 index 000000000..3b6a0325a --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2374 @@ -0,0 +1,114 @@ + + + +A bug in AArch64 FMOPA/FMOPS (non-widening) instruction +Description of problem: +fmopa computes the multiplication of two matrices in the source registers and accumulates the result to the destination register. Depending on the instruction encoding, the element size of operands is either 32 bits or 64 bits. When the computation produces a NaN as a result, the default NaN should be generated. + +However, the current implementation of 32-bit variant of this instruction does not generate default NaNs, because invalid float_status pointer is passed: +``` +// target/arm/tcg/sme_helper.c +void HELPER(sme_fmopa_s)(void *vza, void *vzn, void *vzm, void *vpn, + void *vpm, void *vst, uint32_t desc) +{ +... + float_status fpst; + + /* + * Make a copy of float_status because this operation does not + * update the cumulative fp exception status. It also produces + * default nans. + */ + fpst = *(float_status *)vst; + set_default_nan_mode(true, &fpst); + +... + *a = float32_muladd(n, *m, *a, 0, vst); // &fpst should be used +... +} +``` +Steps to reproduce: +1. Write `test.c`. +``` +#include <stdio.h> + +char i_P0[4] = { 0xff, 0xff, 0xff, 0xff }; +char i_P6[4] = { 0xff, 0xff, 0xff, 0xff }; +char i_Z9[32] = { // Set only the first element as NaN, but it is not default NaN. + 0xff, 0xff, 0xff, 0xff, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, +}; +char i_Z27[32] = { + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, +}; +char i_ZA1H[128] = { 0x0, }; +char o_ZA1H[128]; + +void __attribute__ ((noinline)) show_state() { + for (int i = 0; i < 8; i++) { + for (int j = 0; j < 16; j++) { + printf("%02x ", o_ZA1H[16*i+j]); + } + printf("\n"); + } +} + +void __attribute__ ((noinline)) run() { + __asm__ ( + ".arch armv9.3-a+sme\n" + "smstart\n" + "adrp x29, i_P0\n" + "add x29, x29, :lo12:i_P0\n" + "ldr p0, [x29]\n" + "adrp x29, i_P6\n" + "add x29, x29, :lo12:i_P6\n" + "ldr p6, [x29]\n" + "adrp x29, i_Z9\n" + "add x29, x29, :lo12:i_Z9\n" + "ldr z9, [x29]\n" + "adrp x29, i_Z27\n" + "add x29, x29, :lo12:i_Z27\n" + "ldr z27, [x29]\n" + "adrp x29, i_ZA1H\n" + "add x29, x29, :lo12:i_ZA1H\n" + "mov x15, 0\n" + "ld1w {za1h.s[w15, 0]}, p0, [x29]\n" + "add x29, x29, 32\n" + "ld1w {za1h.s[w15, 1]}, p0, [x29]\n" + "add x29, x29, 32\n" + "mov x15, 2\n" + "ld1w {za1h.s[w15, 0]}, p0, [x29]\n" + "add x29, x29, 32\n" + "ld1w {za1h.s[w15, 1]}, p0, [x29]\n" + ".inst 0x809bc121\n" // fmopa za1.s, p0/m, p6/m, z9.s, z27.s + "adrp x29, o_ZA1H\n" + "add x29, x29, :lo12:o_ZA1H\n" + "mov x15, 0\n" + "st1w {za1h.s[w15, 0]}, p0, [x29]\n" + "add x29, x29, 32\n" + "st1w {za1h.s[w15, 1]}, p0, [x29]\n" + "add x29, x29, 32\n" + "mov x15, 2\n" + "st1w {za1h.s[w15, 0]}, p0, [x29]\n" + "add x29, x29, 32\n" + "st1w {za1h.s[w15, 1]}, p0, [x29]\n" + ".arch armv8-a\n" + ); +} + +int main(int argc, char **argv) { + run(); + show_state(); + return 0; +} +``` +2. Compile `test.bin` using this command: `aarch64-linux-gnu-gcc-12 -O2 -no-pie ./test.c -o ./test.bin`. +3. Run QEMU using this command: `qemu-aarch64 -L /usr/aarch64-linux-gnu/ -cpu max,sme256=on ./test.bin`. +4. The program, runs on top of the buggy QEMU, prints 8 non-default NaNs (ff ff ff ff). It should print 8 default NaNs (00 00 c0 7f) after the bug is fixed. +Additional information: + diff --git a/results/classifier/gemma3:27b/instruction/2375 b/results/classifier/gemma3:27b/instruction/2375 new file mode 100644 index 000000000..68c073b1b --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2375 @@ -0,0 +1,88 @@ + + + +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/gemma3:27b/instruction/2376 b/results/classifier/gemma3:27b/instruction/2376 new file mode 100644 index 000000000..2f1d3c564 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2376 @@ -0,0 +1,117 @@ + + + +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/gemma3:27b/instruction/2386 b/results/classifier/gemma3:27b/instruction/2386 new file mode 100644 index 000000000..e62e288cb --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2386 @@ -0,0 +1,46 @@ + + + +RISCV - Incorrect behaviour of the SLL instruction +Description of problem: +`SLL` (and probably other similar instructions) produce incorrect results. To quote the [RISCV ISA manual](https://drive.google.com/file/d/1uviu1nH-tScFfgrovvFCrj7Omv8tFtkp/view): + +> SLL, SRL, and SRA perform logical left, logical right, and arithmetic right shifts on the value in register +rs1 by the shift amount held in the lower 5 bits of register rs2. + +This instruction should perform a logical shift left by the shift amount from the lower 5 bits held in the third operand, however, it doesn't seem to be the case. As can be seen from the result of the snippet below: `55c3585000000000`, it seems that it calculates the correct value, but then shifts it by another 32 bits to the left: + +```python +correct_shift_res = (0xDB4D6868655C3585 << (0x69C99AB9B9401024 & 0b11111)) & (2 ** 64 - 1) +incorrect_qemu_produced = (correct_shift_res << 32) & (2 ** 64 - 1) +``` +Steps to reproduce: +1. Compile the attached source file: `riscv64-linux-gnu-gcc -static repro.c -o ./repro.elf` + +```c +#include <stdint.h> +#include <stdio.h> + +int main() { + uint64_t a = 0x69C99AB9B9401024; + uint64_t b = 0xDB4D6868655C3585; + uint64_t c; + + asm volatile("sll %0, %1, %2" : "=r"(c) : "r"(b), "r"(a)); + + printf("s8 : %lx\n", c); + printf("expected: %lx\n", 0xb4d6868655c35850); + + return 0; +} +``` + +2. Run qemu: `./qemu-riscv64 ./repro.elf` +3. You will see the output and what the result of the computation should really be: + +``` +s8 : 55c3585000000000 +expected: b4d6868655c35850 +``` +Additional information: + diff --git a/results/classifier/gemma3:27b/instruction/2419 b/results/classifier/gemma3:27b/instruction/2419 new file mode 100644 index 000000000..e3b6e57cc --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2419 @@ -0,0 +1,21 @@ + + + +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/gemma3:27b/instruction/2422 b/results/classifier/gemma3:27b/instruction/2422 new file mode 100644 index 000000000..b3ada641f --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2422 @@ -0,0 +1,72 @@ + + + +`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/gemma3:27b/instruction/2474 b/results/classifier/gemma3:27b/instruction/2474 new file mode 100644 index 000000000..9a7c3f996 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2474 @@ -0,0 +1,99 @@ + + + +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/gemma3:27b/instruction/2483 b/results/classifier/gemma3:27b/instruction/2483 new file mode 100644 index 000000000..7c0fba74f --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2483 @@ -0,0 +1,23 @@ + + + +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/gemma3:27b/instruction/2487 b/results/classifier/gemma3:27b/instruction/2487 new file mode 100644 index 000000000..c5d0c2770 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2487 @@ -0,0 +1,71 @@ + + + +qemu-x86_64: qemu/tcg/ppc/tcg-target.c.inc:1777:tcg_out_test: code should not be reached +Description of problem: +Using this basic test file: + +```c +int +main (void) +{ + return 0; +} +``` + +compiled into a static executable using an x86_64 toolchain (glibc or musl both tested), + +``` +gwyn ~/qemu-bug # file test1 +test1: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked, with debug_info, not stripped + +gwyn ~/qemu-bug # file test2 +test2: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=276dc49ee7cbd3b760e24761bf9fb9e1cc4b4349, for GNU/Linux 3.2.0, not stripped +``` + +Using QEMU from 15957eb9efe2da67c796612cead95cba28ba9bda or newer: + +``` +gwyn ~/qemu-bug # ../emus-ppc64/bin/qemu-x86_64 --version +qemu-x86_64 version 9.0.50 (v9.0.0-521-g15957eb9ef-dirty) +Copyright (c) 2003-2024 Fabrice Bellard and the QEMU Project developers +``` + +QEMU crashes: + +``` +gwyn ~/qemu-bug # ../emus-ppc64/bin/qemu-x86_64 ./test2 +** +ERROR:/root/qemu/tcg/ppc/tcg-target.c.inc:1777:tcg_out_test: code should not be reached +Bail out! ERROR:/root/qemu/tcg/ppc/tcg-target.c.inc:1777:tcg_out_test: code should not be reached +Aborted +``` +Steps to reproduce: +1. Build QEMU user for ppc64 (may affect other hosts) using commit 15957eb9efe2da67c796612cead95cba28ba9bda or newer. +2. Run any simple x86_64 executable. +3. Observe the crash. +Additional information: +Bisected to here: + +``` +commit 15957eb9efe2da67c796612cead95cba28ba9bda +Author: Paolo Bonzini <pbonzini@redhat.com> +Date: Fri Oct 27 05:57:31 2023 +0200 + + target/i386: use TSTEQ/TSTNE to test low bits + + When testing the sign bit or equality to zero of a partial register, it + is useful to use a single TSTEQ or TSTNE operation. It can also be used + to test the parity flag, using bit 0 of the population count. + + Do not do this for target_ulong-sized values however; the optimizer would + produce a comparison against zero anyway, and it avoids shifts by 64 + which are undefined behavior. + + Reviewed-by: Richard Henderson <richard.henderson@linaro.org> + Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> + + target/i386/tcg/emit.c.inc | 5 ++--- + target/i386/tcg/translate.c | 28 ++++++++++++++++++++-------- + 2 files changed, 22 insertions(+), 11 deletions(-) +``` diff --git a/results/classifier/gemma3:27b/instruction/2495 b/results/classifier/gemma3:27b/instruction/2495 new file mode 100644 index 000000000..2ba714012 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2495 @@ -0,0 +1,75 @@ + + + +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/gemma3:27b/instruction/2497 b/results/classifier/gemma3:27b/instruction/2497 new file mode 100644 index 000000000..92bc09806 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2497 @@ -0,0 +1,6 @@ + + + +m68k: fpu: FPIAR register is not implemented +Description of problem: +QEMU doesn't currently implement the `FPIAR` register in the FPU which is fine in most cases but test code (like that in 147bug) that is testing if instructions like `fmove` are working correctly by writing to the register and reading it back don't get the value written when reading it back and detect a failure. diff --git a/results/classifier/gemma3:27b/instruction/2498 b/results/classifier/gemma3:27b/instruction/2498 new file mode 100644 index 000000000..bf51612fa --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2498 @@ -0,0 +1,54 @@ + + + +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/gemma3:27b/instruction/2499 b/results/classifier/gemma3:27b/instruction/2499 new file mode 100644 index 000000000..f6bfb80d5 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2499 @@ -0,0 +1,33 @@ + + + +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/gemma3:27b/instruction/2500 b/results/classifier/gemma3:27b/instruction/2500 new file mode 100644 index 000000000..a23fcaed6 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2500 @@ -0,0 +1,7 @@ + + + +m68k: mmu: 68030 mmu instructions are missing +Description of problem: +The 68030 has some mmu instructions like `pmove` that are only valid for the 68030 (and maybe the external mmu for the 68020??). +QEMU doesn't currently implement `pmove` and the encoding of `pmove` seems to be the same as an f-line instruction that should generate an f-line exception on everything except the 68030 so currently an f-line exception happens instead of the intended load/store to the mmu. diff --git a/results/classifier/gemma3:27b/instruction/2536 b/results/classifier/gemma3:27b/instruction/2536 new file mode 100644 index 000000000..afd1e571a --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2536 @@ -0,0 +1,4 @@ + + + +Dynamic translation issue of arm instruction VFNMA and VFNMS diff --git a/results/classifier/gemma3:27b/instruction/2595 b/results/classifier/gemma3:27b/instruction/2595 new file mode 100644 index 000000000..07e871de6 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2595 @@ -0,0 +1,138 @@ + + + +Incorrect behavior with 64-bit element SDOT and UDOT instructions on ARM SVE when sve-default-vector-length>=64 +Description of problem: +The behavior of SDOT and UDOT instructions are incorrect when the Zresult.D register is used, which is the 64-bit svdot_lane\_{s,u}64 intrinsic in ACLE. + +I have tested the same code using [Arm Instruction Emulator](https://developer.arm.com/Tools%20and%20Software/Arm%20Instruction%20Emulator) (which is deprecated though) and gem5 which produced correct result, I believe that the SDOT and UDOT implementation in qemu is incorrect. +Steps to reproduce: +1. Get Arm Gnu toolchain from [Arm GNU Toolchain Downloads – Arm Developer](https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads), for x86 Linux hosts, download arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz and extract it. Alternatively, use any compiler that is able to cross compile for armv8.2-a+sve targets. +2. Compile the following program with these compiler arguments + + ``` + arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu-gcc -O3 -march=armv8.2-a+sve dot_lane.c -o dot_lane + ``` + + ```c + #include <stdio.h> + #include <arm_sve.h> + + int64_t a[32] = { 0 }; + int16_t b[128]; + int16_t c[128]; + int64_t r[32]; + int64_t expected_r[32]; + + #define IMM 0 + + int main(void) + { + for (size_t i = 0; i < 128; i++) { + b[i] = 1; + c[i] = i / 4; + } + + svint64_t av = svld1(svptrue_b64(), a); + svint16_t bv = svld1(svptrue_b16(), b); + svint16_t cv = svld1(svptrue_b16(), c); + + svint64_t result = svdot_lane_s64(av, bv, cv, IMM); + + svst1(svptrue_b64(), r, result); + + for (size_t i = 0; i < svcntd(); i++) { + expected_r[i] = + (int64_t)b[i * 4 + 0] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 0] + + (int64_t)b[i * 4 + 1] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 1] + + (int64_t)b[i * 4 + 2] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 2] + + (int64_t)b[i * 4 + 3] * (int64_t)c[(i - i % 2) * 4 + IMM * 4 + 3] + + a[i]; + } + + printf("%12s", "r: "); + for (size_t i = 0; i < svcntd(); i++) { + printf("%4ld", r[i]); + } + printf("\n"); + printf("%12s", "expected_r: "); + for (size_t i = 0; i < svcntd(); i++) { + printf("%4ld", expected_r[i]); + } + printf("\n\t\t"); + for (size_t i = 0; i < svcntd(); i++) { + if (r[i] != expected_r[i]) { + printf("%4c", '^'); + } else { + printf("%4c", ' '); + } + } + printf("\n"); + printf("idx:\t\t"); + for (size_t i = 0; i < svcntd(); i++) { + if (r[i] != expected_r[i]) { + printf("%4d", i); + } else { + printf("%4c", ' '); + } + } + printf("\n"); + + return 0; + } + ``` +3. Execute it with the following commands: + + ``` + qemu-aarch64 -cpu max,sve-default-vector-length=16 -L arm-gnu-toolchain-13.3.rel1-x86_64-aarch64-none-linux-gnu/bin/../aarch64-none-linux-gnu/libc dot_lane + ``` + + Change the value of `sve-default-vector-length` to 32, 64, 128, 256 and observe the outputs, we should see that for `sve-default-vector-length` \>= 64, the result is incorrect. + + `sve-default-vector-length=16` + + ``` + r: 0 0 + expected_r: 0 0 + + idx: + ``` + + `sve-default-vector-length=32` + + ``` + r: 0 0 8 8 + expected_r: 0 0 8 8 + + idx: + ``` + + `sve-default-vector-length=64` + + ``` + r: 0 0 8 8 8 8 24 24 + expected_r: 0 0 8 8 16 16 24 24 + ^ ^ + idx: 4 5 + ``` + + `sve-default-vector-length=128` + + ``` + r: 0 0 8 8 8 8 24 24 24 24 40 40 40 40 56 56 + expected_r: 0 0 8 8 16 16 24 24 32 32 40 40 48 48 56 56 + ^ ^ ^ ^ ^ ^ + idx: 4 5 8 9 12 13 + ``` + + `sve-default-vector-length=256` + + ``` + r: 0 0 8 8 8 8 24 24 24 24 40 40 40 40 56 56 56 56 72 72 72 72 88 88 88 88 104 104 104 104 120 120 + expected_r: 0 0 8 8 16 16 24 24 32 32 40 40 48 48 56 56 64 64 72 72 80 80 88 88 96 96 104 104 112 112 120 120 + ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ + idx: 4 5 8 9 12 13 16 17 20 21 24 25 28 29 + ``` +4. By passing `-S` to the compiler, we can see that sdot (or udot if using `svdot_lane_u64()`) is produced in assembly (`sdot z0.d, z1.h, z2.h[0]`), which is correct behavior according to [Intrinsics – Arm Developer](https://developer.arm.com/architectures/instruction-sets/intrinsics/svdot_lane%5B_s64%5D). +Additional information: + diff --git a/results/classifier/gemma3:27b/instruction/2604 b/results/classifier/gemma3:27b/instruction/2604 new file mode 100644 index 000000000..eaa3a5380 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2604 @@ -0,0 +1,47 @@ + + + +qemu-user-static crash when executing generated NEON code due to failure to detect invalidation +Description of problem: +`qemu-arm-static` crashes 100% of times when attempting to run NEON code. The same executable, when run in `system` emulation mode, works without issue. + +I experience this particular issue when attempting to test GStreamer's Orc library with NEON codegen with QEMU user emulation. +Steps to reproduce: +1. Clone https://gitlab.freedesktop.org/gstreamer/orc.git +2. Build with `meson setup build -Ddefault_library=static; meson compile -C build` +3. Run `qemu-arm-static ./build/tools/orc-bugreport` +Additional information: +The crash always happens inside the same JIT code. It is not a memory access, so there is no reason for QEMU to report SIGSEGV: + +``` +Program received signal SIGSEGV, Segmentation fault. +0x409e503c in ?? () +(gdb) bt +#0 0x409e503c in ?? () +#1 0x00408bc6 in orc_executor_run (ex=0x51cfc0) at ../orc/orcexecutor.c:51 +#2 0x00489692 in orc_test_compare_output_full_for_target (program=0x4bcd90, flags=0, + target_name=0x0) at ../orc-test/orctest.c:800 +#3 0x00489004 in orc_test_compare_output_full (program=0x4bcd90, flags=0) + at ../orc-test/orctest.c:664 +#4 0x00404826 in test_opcode_src (opcode=0x4b098c <opcodes+2400>) + at ../tools/orc-bugreport.c:252 +#5 0x004045d8 in test_opcodes () at ../tools/orc-bugreport.c:188 +#6 0x004043f2 in main (argc=1, argv=0x40800704) at ../tools/orc-bugreport.c:118 +(gdb) disas 0x409e5030 +No function contains specified address. +(gdb) disas 0x409e5030, +10 +Dump of assembler code from 0x409e5030 to 0x409e503a: + 0x409e5030: vld1.8 {d4-d5}, [r3] + 0x409e5034: vst1.8 {d4-d5}, [r2] + 0x409e5038: add r2, r2, #16 +End of assembler dump. +(gdb) disas 0x409e5030, +20 +Dump of assembler code from 0x409e5030 to 0x409e5044: + 0x409e5030: vld1.8 {d4-d5}, [r3] + 0x409e5034: vst1.8 {d4-d5}, [r2] + 0x409e5038: add r2, r2, #16 +=> 0x409e503c: add r3, r3, #16 + 0x409e5040: subs r12, r12, #1 +End of assembler dump. +(gdb) +``` diff --git a/results/classifier/gemma3:27b/instruction/2632 b/results/classifier/gemma3:27b/instruction/2632 new file mode 100644 index 000000000..32006cbc2 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2632 @@ -0,0 +1,86 @@ + + + +tcg optimization breaking memory access ordering +Description of problem: +The following code creates register dependency between 2 loads, which forces the first load to finish before the second: +``` +movz w0, #0x2 +str w0, [x1] +ldr w2, [x1] +eor w3, w2, w2 +ldr w4, [x5, w3, sxtw] +``` + +While translating it to tcg IR, it keeps this dependency correctly. +But after running tcg optimizations, it optimized the tcg sequence for `eor w3, w2, w2` at `0000000000000144` to `mov_i64 x3,$0x0`. which then removes the dependency between the loads. + +It results in incorrect behavior on the host on a multiple threaded program +Steps to reproduce: +1. +2. +3. +Additional information: +``` +OP: + ld_i32 loc0,env,$0xfffffffffffffff0 + brcond_i32 loc0,$0x0,lt,$L0 + st8_i32 $0x0,env,$0xfffffffffffffff4 + + ---- 0000000000000134 0000000000000000 0000000000000000 + add_i64 x28,x28,$0x2 + + ---- 0000000000000138 0000000000000000 0000000000000000 + mov_i64 x0,$0x2 + + ---- 000000000000013c 0000000000000000 0000000000001c00 + mov_i64 loc3,x1 + mov_i64 loc4,loc3 + qemu_st_a64_i64 x0,loc4,w16+un+leul,2 + + ---- 0000000000000140 0000000000000000 0000000000001c10 + mov_i64 loc5,x1 + mov_i64 loc6,loc5 + qemu_ld_a64_i64 x2,loc6,w16+un+leul,2 + + ---- 0000000000000144 0000000000000000 0000000000000000 + and_i64 loc7,x2,$0xffffffff + xor_i64 x3,x2,loc7 + and_i64 x3,x3,$0xffffffff + + ---- 0000000000000148 0000000000000000 0000000000001c20 + mov_i64 loc9,x5 + mov_i64 loc10,x3 + ext32s_i64 loc10,loc10 + add_i64 loc9,loc9,loc10 + mov_i64 loc11,loc9 + qemu_ld_a64_i64 x4,loc11,w16+un+leul,2 + st8_i32 $0x1,env,$0xfffffffffffffff4 +``` + + +``` +OP after optimization and liveness analysis: + ld_i32 tmp0,env,$0xfffffffffffffff0 pref=0xffffffff + brcond_i32 tmp0,$0x0,lt,$L0 dead: 0 + st8_i32 $0x0,env,$0xfffffffffffffff4 dead: 0 + + ---- 0000000000000134 0000000000000000 0000000000000000 + add_i64 x28,x28,$0x2 sync: 0 dead: 0 1 pref=0xffffffff + + ---- 0000000000000138 0000000000000000 0000000000000000 + mov_i64 x0,$0x2 sync: 0 dead: 0 pref=0xffffffff + + ---- 000000000000013c 0000000000000000 0000000000001c00 + qemu_st_a64_i64 $0x2,x1,w16+un+leul,2 dead: 0 + + ---- 0000000000000140 0000000000000000 0000000000001c10 + qemu_ld_a64_i64 x2,x1,w16+un+leul,2 sync: 0 dead: 0 1 pref=0xffffffff + + ---- 0000000000000144 0000000000000000 0000000000000000 + mov_i64 x3,$0x0 sync: 0 dead: 0 1 pref=0xffffffff + + ---- 0000000000000148 0000000000000000 0000000000001c20 + qemu_ld_a64_i64 x4,x5,w16+un+leul,2 sync: 0 dead: 0 1 pref=0xffffffff + st8_i32 $0x1,env,$0xfffffffffffffff4 dead: 0 +``` diff --git a/results/classifier/gemma3:27b/instruction/266 b/results/classifier/gemma3:27b/instruction/266 new file mode 100644 index 000000000..bd31cb7da --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/266 @@ -0,0 +1,4 @@ + + + +'mtfsf' instruction can clear FI incorrectly diff --git a/results/classifier/gemma3:27b/instruction/2672 b/results/classifier/gemma3:27b/instruction/2672 new file mode 100644 index 000000000..00d274700 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2672 @@ -0,0 +1,23 @@ + + + +Skipping a jal instruction in riscv64 baremetal emulation +Description of problem: +The binary contains an illegal instruction after a jal. Normally the jal should be taken but the illegal instructi[aia_tests2.elf](/uploads/b8b646b01d7bcc15b51c36ddbffacac7/aia_tests2.elf)on next to the jal is executed generating and illegal instruction exception: + +``` +0x80006070: 00200513 addi a0,zero,2 +0x80006074: 89cff0ef jal ra,-3940 # 0x80005110 + +---------------- +IN: _Z15int_switch_modehh +0x80006078: 0000 illegal + +---------------- +IN: mtvec_table +0x8000e600: 64d0406f j 20044 # 0x8001344c +``` +Steps to reproduce: +1. Execute the same binary with QEMU. +Additional information: + diff --git a/results/classifier/gemma3:27b/instruction/2696 b/results/classifier/gemma3:27b/instruction/2696 new file mode 100644 index 000000000..3fdc8f0a0 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2696 @@ -0,0 +1,15 @@ + + + +qemu-hexagon 9.2.0-rc1 hits unreachable assertion in decode_insns() on invalid instruction +Description of problem: +``` +❯ cat start.s +.globl _start +_start: .word 0 +❯ clang start.s -target hexagon-linux -nostdlib -fuse-ld=lld +❯ qemu-hexagon ./a.out +** +ERROR:../target/hexagon/decode.c:492:decode_insns: code should not be reached +Bail out! ERROR:../target/hexagon/decode.c:492:decode_insns: code should not be reached +``` diff --git a/results/classifier/gemma3:27b/instruction/2730 b/results/classifier/gemma3:27b/instruction/2730 new file mode 100644 index 000000000..7d94e5a01 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2730 @@ -0,0 +1,13 @@ + + + +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/gemma3:27b/instruction/2775 b/results/classifier/gemma3:27b/instruction/2775 new file mode 100644 index 000000000..d4fa3fbda --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2775 @@ -0,0 +1,137 @@ + + + +internal assertion failure in sparc64 codegen: translate.c:5695:sparc_tr_insn_start: code should not be reached +Description of problem: +qemu crashes with internal assertion: + +ERROR:../target/sparc/translate.c:5695:sparc_tr_insn_start: code should not be reached +Steps to reproduce: +1. boot emulated NetBSD/sparc64 system +2. cd /usr/tests && atf-run|atf-report + +not 100% reproducable, but happens often +Additional information: +last output: +``` +IN: +0x4102ce80: sethi %hi(0x29e0000), %g1 +0x4102ce84: b,a 0x40d78220 + +---------------- +IN: +0x41029fc0: sethi %hi(0x1e30000), %g1 +0x41029fc4: b,a 0x40e9ccc0 + +---------------- +IN: +0x4102b5e0: sethi %hi(0x23b8000), %g1 +0x4102b5e4: b,a 0x40e9dc20 + +---------------- +IN: +0x4102a6e0: sethi %hi(0x1ff8000), %g1 +0x4102a6e4: b,a 0x40e9cbc0 + +---------------- +IN: +0x410230e0: sethi %hi(0x278000), %g1 +0x410230e4: b,a 0x40e25d60 + +---------------- +IN: +0x41026920: sethi %hi(0x1088000), %g1 +0x41026924: b,a 0x40d77da0 + +---------------- +IN: +0x41024140: sethi %hi(0x690000), %g1 +0x41024144: b,a 0x40e25f00 + +---------------- +IN: +0x00245c20: sethi %hi(0xc8000), %g1 +0x00245c24: sethi %hi(0x40d77c00), %g1 +0x00245c28: jmp %g1 + 0x1a0 ! 0x40d77da0 +0x00245c2c: nop + +---------------- +IN: +0x00245ba0: sethi %hi(0xa8000), %g1 +0x00245ba4: b,a %xcc, 0x245920 + +---------------- +IN: +0x00245ba0: sethi %hi(0xa8000), %g1 +0x00245ba4: sethi %hi(0x40d76c00), %g1 +0x00245ba8: jmp %g1 + 0x80 ! 0x40d76c80 +0x00245bac: nop + +---------------- +IN: +0x00245e60: sethi %hi(0x158000), %g1 +0x00245e64: b,a %xcc, 0x245920 + +---------------- +IN: +0x00245e60: sethi %hi(0x158000), %g1 +0x00245e64: sethi %hi(0x40d76400), %g1 +0x00245e68: jmp %g1 + 0x260 ! 0x40d76660 +0x00245e6c: nop + +---------------- +IN: +0x002465a0: sethi %hi(0x328000), %g1 +0x002465a4: sethi %hi(0x40d69000), %g1 +0x002465a8: jmp %g1 + 0x198 ! 0x40d69198 +0x002465ac: nop + +** +ERROR:../target/sparc/translate.c:5695:sparc_tr_insn_start: code should not be reached +``` + +gdb says: +``` +#0 0x000079343d6ebbfa in _lwp_kill () from /usr/lib/libc.so.12 +#1 0x000079343d6f7034 in abort () + at /home/martin/current/src/lib/libc/stdlib/abort.c:74 +#2 0x000079343e06a03a in g_assertion_message[cold] () + from /usr/pkg/lib/libglib-2.0.so.0 +#3 0x000079343e03c719 in g_assertion_message_expr () + from /usr/pkg/lib/libglib-2.0.so.0 +#4 0x0000000000a23345 in sparc_tr_insn_start (dcbase=<optimized out>, + cs=<optimized out>) at ../target/sparc/translate.c:5695 +#5 0x0000000000aa932f in translator_loop (cpu=cpu@entry=0x7933fac3be40, + tb=tb@entry=0x79341ba52840 <code_gen_buffer+549308435>, + max_insns=max_insns@entry=0x7933fa5d3d44, pc=pc@entry=1206519, + host_pc=host_pc@entry=0x7933f52a58f7, + ops=ops@entry=0xfac3c0 <sparc_tr_ops>, db=db@entry=0x7933fa5d3b80) + at ../accel/tcg/translator.c:152 +#6 0x0000000000a368ca in gen_intermediate_code (cs=cs@entry=0x7933fac3be40, + tb=tb@entry=0x79341ba52840 <code_gen_buffer+549308435>, + max_insns=max_insns@entry=0x7933fa5d3d44, pc=pc@entry=1206519, + host_pc=host_pc@entry=0x7933f52a58f7) at ../target/sparc/translate.c:5816 +#7 0x0000000000aa7e90 in setjmp_gen_code (env=env@entry=0x7933fac3e5e0, + tb=tb@entry=0x79341ba52840 <code_gen_buffer+549308435>, + pc=pc@entry=1206519, host_pc=0x7933f52a58f7, + max_insns=max_insns@entry=0x7933fa5d3d44, ti=<optimized out>) + at ../accel/tcg/translate-all.c:278 +#8 0x0000000000aa835d in tb_gen_code (cpu=cpu@entry=0x7933fac3be40, + pc=pc@entry=1206519, cs_base=cs_base@entry=1206523, flags=2181038080, + cflags=cflags@entry=-16777216) at ../accel/tcg/translate-all.c:358 +#9 0x0000000000aa135b in cpu_exec_loop (cpu=cpu@entry=0x7933fac3be40, + sc=sc@entry=0x7933fa5d3e80) at ../accel/tcg/cpu-exec.c:993 +#10 0x0000000000aa1788 in cpu_exec_setjmp (cpu=cpu@entry=0x7933fac3be40, + sc=sc@entry=0x7933fa5d3e80) at ../accel/tcg/cpu-exec.c:1039 +#11 0x0000000000aa1f8d in cpu_exec (cpu=cpu@entry=0x7933fac3be40) + at ../accel/tcg/cpu-exec.c:1065 +#12 0x0000000000abb53d in tcg_cpu_exec (cpu=cpu@entry=0x7933fac3be40) + at ../accel/tcg/tcg-accel-ops.c:78 +#13 0x0000000000abb6ae in mttcg_cpu_thread_fn (arg=arg@entry=0x7933fac3be40) + at ../accel/tcg/tcg-accel-ops-mttcg.c:95 +#14 0x0000000000c7f750 in qemu_thread_start (args=0x79343aef7520) + at ../util/qemu-thread-posix.c:541 +#15 0x000079343d98c145 in pthread__create_tramp (cookie=0x79343c583000) + at /home/martin/current/src/lib/libpthread/pthread.c:595 +#16 0x000079343d5d1310 in ?? () from /usr/lib/libc.so.12 +``` diff --git a/results/classifier/gemma3:27b/instruction/2802 b/results/classifier/gemma3:27b/instruction/2802 new file mode 100644 index 000000000..e174b9b20 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2802 @@ -0,0 +1,29 @@ + + + +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/gemma3:27b/instruction/2865 b/results/classifier/gemma3:27b/instruction/2865 new file mode 100644 index 000000000..91400a862 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2865 @@ -0,0 +1,55 @@ + + + +loongarch64: wrong implementation of `xvldi` instruction +Description of problem: +Consider this sample program. + +```c++ +#include <cstdio> +#include <cstdint> +#include <lsxintrin.h> +#include <lasxintrin.h> + +void dump_u32(__m256i x) { + uint32_t tmp[32/4]; + __lasx_xvst(x, tmp, 0); + putchar('['); + for (int i=0; i < 32/4; i++) { + if (i > 0) { + putchar(' '); + } + + printf("%08x", tmp[i]); + } + puts("]"); +} + +int main() { + __m256i const1 = __lasx_xvldi(-3832); + dump_u32(const1); +} +``` + +The magic constants here means: replicate in 32-bit words a byte (0x4) shifted left by 8. We should have a vector of words 0x800, and indeed, the program run on a real hardware prints expected: + +``` +[00000800 00000800 00000800 00000800 00000800 00000800 00000800 00000800] +``` + +The same program run under Qemu prints: + +``` +[08000800 00000000 08000800 00000000 08000800 00000000 08000800 00000000] +``` +Additional information: +I grabbed the latest sources, it seems there's bug in `target/loongarch/tcg/insn_trans/trans_vec.c.inc`, in function `vldi_get_value`. + +```c + case 1: + /* data: {2{16'0, imm[7:0], 8'0}} */ + data = (t << 24) | (t << 8); + break; +``` + +There should be `(t << (8+32)) | t << 8`. diff --git a/results/classifier/gemma3:27b/instruction/2878 b/results/classifier/gemma3:27b/instruction/2878 new file mode 100644 index 000000000..0cf0f9d8c --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2878 @@ -0,0 +1,4 @@ + + + +Support for avx512 in qemu user space emulation. diff --git a/results/classifier/gemma3:27b/instruction/2971 b/results/classifier/gemma3:27b/instruction/2971 new file mode 100644 index 000000000..706ee9d06 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/2971 @@ -0,0 +1,47 @@ + + + +loongarch64 crashes caused by lenient instruction decoding of vldi and xvldi +Description of problem: +Lenient instruction decoding of `vldi` and `xvldi` leads to Qemu crashes. + +The decoding of `vldi` and `xvldi` instruction allows for instructions with illegal immediates. + +`target/loongarch/insns.decode`: + +``` +vldi 0111 00111110 00 ............. ..... @v_i13 +xvldi 0111 01111110 00 ............. ..... @v_i13 +``` + +This is considered in `target/loongarch/tcg/insn_trans/trans_vec.c.inc`: + +```C + /* + * imm bit [11:8] is mode, mode value is 0-12. + * other values are invalid. + */ +``` + +However, an assertion error is raised when this condition is violated and qemu crashes: + +``` +** +ERROR:target/loongarch/insn_trans/trans_vec.c.inc:3574:vldi_get_value: code should not be reached +Bail out! ERROR:target/loongarch/insn_trans/trans_vec.c.inc:3574:vldi_get_value: code should not be reached +``` + +On hardware (Loongson 3A5000), these instructions cause a SIGILL. +Steps to reproduce: +1. compile the `test_inv_vldi` test program for loongarch64 (see additional information) +2. run `qemu-loongarch64-static ./test_inv_vldi` +Additional information: +I will post a patch for this issue to the mailing list soon. + +`test_inv_vldi` source code: + +```C +int main(int argc, char** argv) { + asm volatile(".4byte 0x73e3a000"); +} +``` diff --git a/results/classifier/gemma3:27b/instruction/312 b/results/classifier/gemma3:27b/instruction/312 new file mode 100644 index 000000000..eeba93125 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/312 @@ -0,0 +1,4 @@ + + + +QEMU emulation of fmadds instruction on powerpc64le is buggy diff --git a/results/classifier/gemma3:27b/instruction/361 b/results/classifier/gemma3:27b/instruction/361 new file mode 100644 index 000000000..afcbbb584 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/361 @@ -0,0 +1,4 @@ + + + +-cpu host results in unsupported AVX512 instructions diff --git a/results/classifier/gemma3:27b/instruction/364 b/results/classifier/gemma3:27b/instruction/364 new file mode 100644 index 000000000..19a9fae8c --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/364 @@ -0,0 +1,4 @@ + + + +qemu-aarch64: incorrect signed comparison in ldsmax instructions diff --git a/results/classifier/gemma3:27b/instruction/381 b/results/classifier/gemma3:27b/instruction/381 new file mode 100644 index 000000000..459d6c328 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/381 @@ -0,0 +1,4 @@ + + + +ERROR:target/arm/translate-a64.c:13229:disas_simd_two_reg_misc_fp16: code should not be reached diff --git a/results/classifier/gemma3:27b/instruction/385 b/results/classifier/gemma3:27b/instruction/385 new file mode 100644 index 000000000..1b07af179 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/385 @@ -0,0 +1,4 @@ + + + +ARM user regression since 87b74e8b6edd287ea2160caa0ebea725fa8f1ca1 diff --git a/results/classifier/gemma3:27b/instruction/390 b/results/classifier/gemma3:27b/instruction/390 new file mode 100644 index 000000000..28313d0fb --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/390 @@ -0,0 +1,4 @@ + + + +target/ppc: atomic path of Load Quadword instruction require address with write permission diff --git a/results/classifier/gemma3:27b/instruction/422 b/results/classifier/gemma3:27b/instruction/422 new file mode 100644 index 000000000..d637043bf --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/422 @@ -0,0 +1,4 @@ + + + +Unable to execute MIPS MSA code due to illegal instruction diff --git a/results/classifier/gemma3:27b/instruction/427 b/results/classifier/gemma3:27b/instruction/427 new file mode 100644 index 000000000..87592bc9b --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/427 @@ -0,0 +1,4 @@ + + + +TCG: QEMU incorrectly raises exception on SSE4.2 CRC32 instruction diff --git a/results/classifier/gemma3:27b/instruction/449 b/results/classifier/gemma3:27b/instruction/449 new file mode 100644 index 000000000..7b194c316 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/449 @@ -0,0 +1,71 @@ + + + +s390x linux-user assertion fires in vector asm on master +Description of problem: +Seeing a assert being fired when running this go program that executes vector instructions: + +[ecdsaexample.go](/uploads/f5162a12747f93f060cfcabaea786d92/ecdsaexample.go) + +``` +qemu-s390x-static: ../qemu/target/s390x/translate.c:1063: get_field1: Assertion `have_field1(s, o)' failed. +SIGABRT: abort +PC=0x5b660 m=0 sigcode=4294967290 + +goroutine 1 [running]: +runtime.sigpanic() + /home/jalbrecht/s390x/15/go/src/runtime/signal_unix.go:723 fp=0xc000198998 sp=0xc000198998 pc=0x5b660 +crypto/elliptic.p256SqrInternalVMSL() + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_asm_s390x.s:1488 fp=0xc0001989a0 sp=0xc0001989a0 pc=0xda600 +p256SqrInternal() + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_asm_s390x.s:1695 +0x18 fp=0xc0001989d8 sp=0xc0001989a0 pc=0xd95b8 +crypto/elliptic.p256SqrAsm(0xc000198bc0, 0x20, 0x20, 0xc000198ce0, 0x20, 0x20, 0x0, 0xc, 0x30, 0x4000802560, ...) + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_asm_s390x.s:1849 +0x3c fp=0xc0001989e0 sp=0xc0001989d8 pc=0xdaa6c +crypto/elliptic.p256Sqr(...) + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_s390x.go:81 +crypto/elliptic.p256Inverse(0xc000198bc0, 0x20, 0x20, 0xc000198ce0, 0x20, 0x20) + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_s390x.go:324 +0x66 fp=0xc000198b28 sp=0xc0001989e0 pc=0xd7da6 +crypto/elliptic.initTable() + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_s390x.go:436 +0x192 fp=0xc000198d00 sp=0xc000198b28 pc=0xd87d2 +crypto/elliptic.initP256Arch(...) + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256_s390x.go:57 +crypto/elliptic.initP256() + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/p256.go:40 +0x2c0 fp=0xc000198d38 sp=0xc000198d00 pc=0xd2960 +crypto/elliptic.initAll() + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/elliptic.go:397 +0x24 fp=0xc000198d40 sp=0xc000198d38 pc=0xd1ab4 +sync.(*Once).doSlow(0x2168e8, 0x122be8) + /home/jalbrecht/s390x/15/go/src/sync/once.go:66 +0x12c fp=0xc000198d98 sp=0xc000198d40 pc=0x7ee5c +sync.(*Once).Do(...) + /home/jalbrecht/s390x/15/go/src/sync/once.go:57 +crypto/elliptic.P256(...) + /home/jalbrecht/s390x/15/go/src/crypto/elliptic/elliptic.go:433 +main.main() + /home/jalbrecht/s390x/ecdsaexample.go:17 +0x7de fp=0xc000198f80 sp=0xc000198d98 pc=0xe4a2e +runtime.main() + /home/jalbrecht/s390x/15/go/src/runtime/proc.go:204 +0x214 fp=0xc000198fd8 sp=0xc000198f80 pc=0x472e4 +runtime.goexit() + /home/jalbrecht/s390x/15/go/src/runtime/asm_s390x.s:779 +0x2 fp=0xc000198fd8 sp=0xc000198fd8 pc=0x77c52 + +r0 0x0 r1 0xc000198bc0 +r2 0xc000198ce0 r3 0xc000198ce0 +r4 0x1401a0 r5 0xc000198be0 +r6 0xc000198bc0 r7 0x1c00f0 +r8 0xda600 r9 0xc0001989a8 +r10 0x217810 r11 0x0 +r12 0x4000800378 r13 0xc000000180 +r14 0xda600 r15 0xc000198998 +pc 0x5b660 link 0xda600 +exit status 2 +``` +Steps to reproduce: +On an amd64 linux host: +1. Download attached ecdsaexample.go file +2. Download and untar an s390x go distro (1.15 and 1.16 both show this issue): https://golang.org/dl/go1.15.13.linux-s390x.tar.gz +3. Build a qemu-s390x-static from current master +4. qemu-s390x-static -E PATH=/path/to/s390x/15/go/bin -L /usr/s390x-linux-gnu /path/to/s390x/15/go/bin/go run ecdsaexample.go +Additional information: +@davidhildenbrand could you have a look? I tracked it down to this series of patches: https://lore.kernel.org/qemu-devel/20210608092337.12221-1-david@redhat.com/. I tried reverting just this series from current master and then the program runs with no issues. + +This crash is seen whenever eg. certificates are checked when connecting via https so it is likely to happen in real programs. + +cc: @ruixinbao diff --git a/results/classifier/gemma3:27b/instruction/494 b/results/classifier/gemma3:27b/instruction/494 new file mode 100644 index 000000000..041ca2b3d --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/494 @@ -0,0 +1,4 @@ + + + +cmake crashes on qemu-alpha-user with Illegal Instruction diff --git a/results/classifier/gemma3:27b/instruction/508 b/results/classifier/gemma3:27b/instruction/508 new file mode 100644 index 000000000..a5b701b3a --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/508 @@ -0,0 +1,4 @@ + + + +x86_64 cmpxchg behavior in qemu tcg does not match the real CPU diff --git a/results/classifier/gemma3:27b/instruction/514 b/results/classifier/gemma3:27b/instruction/514 new file mode 100644 index 000000000..76794e17a --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/514 @@ -0,0 +1,28 @@ + + + +MTE reports false positive for "str" instruction with the SP as the base register. +Description of problem: +When PE executes "sp"-based store instruction with offset I got tag check fault exception. But according to arm spec. load or store that uses "sp" register should generate Tag Unchecked access. +Steps to reproduce: +Clang version: clang version 12.0.1. +I compiled my code using "-target aarch64-linux -march=armv8+memtag -fsanitize=memtag" for Clang. Clang generates following code: +``` +0000000000000c14 <test_func>: + c14: a9bc7bfd stp x29, x30, [sp, #-64]! + c18: f9000bf7 str x23, [sp, #16] + ... +``` +Whole stack was mapped in translation tables as Tagged memory."SCTLR" register was configured to trigger synchronous exception on tag mismatch. +When cpu executes firs instruction "stp x29, x30, [sp, #-64]!" I got tag check fault exception: "0b010001 When FEAT_MTE is implemented Synchronous Tag Check Fault": +ESR_EL1=0x96000051. + +According to ARM specification load or store that uses "sp" register should generate Tag Unchecked access: +``` +A Tag Unchecked access will be generated for a load or store that uses either of the following: +• A base register only, with the SP as the base register. +• A base register plus immediate offset addressing form, with the SP as the base register. +``` +Looks like qemu erroneously generates tag mismatch exceptions for SP-based loads and stores with immediate offset. +Additional information: + diff --git a/results/classifier/gemma3:27b/instruction/616 b/results/classifier/gemma3:27b/instruction/616 new file mode 100644 index 000000000..3aa0af141 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/616 @@ -0,0 +1,110 @@ + + + +overflow condition code determined incorrectly after addition on s390x +Description of problem: +The following program foo.c +[foo.c](/uploads/78f5f799af6e3c400a6a42634f3f0e63/foo.c) + +``` +#include <stdio.h> + +int overflow_32 (int x, int y) +{ + int sum; + return ! __builtin_add_overflow (x, y, &sum); +} + +int overflow_64 (long long x, long long y) +{ + long sum; + return ! __builtin_add_overflow (x, y, &sum); +} + +int a1 = -2147483648; +int b1 = -2147483648; +long long a2 = -9223372036854775808L; +long long b2 = -9223372036854775808L; + +int main () +{ + { + int a = a1; + int b = b1; + printf ("a = 0x%x, b = 0x%x\n", a, b); + printf ("no_overflow = %d\n", overflow_32 (a, b)); + } + { + long long a = a2; + long long b = b2; + printf ("a = 0x%llx, b = 0x%llx\n", a, b); + printf ("no_overflow = %d\n", overflow_64 (a, b)); + } +} +``` + +should print + +``` +a = 0x80000000, b = 0x80000000 +no_overflow = 0 +a = 0x8000000000000000, b = 0x8000000000000000 +no_overflow = 0 +``` + +However, when compiled as an s390x program and executed through +qemu 6.1.0 (Linux user-mode), it prints 'no_overflow = 1' twice. + +``` +$ s390x-linux-gnu-gcc-10 --version +s390x-linux-gnu-gcc-10 (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0 +``` + +``` +$ s390x-linux-gnu-gcc-10 -static foo.c +$ ~/inst-qemu/6.1.0/bin/qemu-s390x a.out +a = 0x80000000, b = 0x80000000 +no_overflow = 1 +a = 0x8000000000000000, b = 0x8000000000000000 +no_overflow = 1 +``` + +``` +$ s390x-linux-gnu-gcc-10 -O2 -static foo.c +$ ~/inst-qemu/6.1.0/bin/qemu-s390x a.out +a = 0x80000000, b = 0x80000000 +no_overflow = 1 +a = 0x8000000000000000, b = 0x8000000000000000 +no_overflow = 1 +``` + +The code generated by 's390x-linux-gnu-gcc-10 -O2' makes use of the +'o' (overflow / ones) condition code: + +``` +overflow_64: + lgr %r1,%r2 ;; copy a into %r1 + lghi %r2,0 + agr %r1,%r3 ;; add a and b + bnor %r14 ;; if no overflow, return %r2 = 0 + lghi %r2,1 + br %r14 ;; otherwise, return %r2 = 1 +``` + +Either the bug is in GCC, that is, GCC produces code that uses the CPU's +overflow condition code when it shouldn't. + +Or the bug is in QEMU, that is, QEMU does not set the overflow condition +code correctly. + +This can be decided by running the above program on real Linux/s390x hardware +(to which I don't have access). +Steps to reproduce: +[foo.static.s390x](/uploads/ac41abf4c54baf9ca96ba82d75a24ad6/foo.static.s390x) +(foo.static.s390x is attached, the result of "s390x-linux-gnu-gcc-10 -static -O2 foo.c -o foo.static.s390x") + +1. `qemu-s390x foo.static.s390x` +Additional information: +If the bug is really in QEMU, the attached patch fixes it. + +[0001-s390x-Fix-determination-of-overflow-condition-code-a.patch](/uploads/552917079ccd25f1861d682fc9dee3e8/0001-s390x-Fix-determination-of-overflow-condition-code-a.patch) diff --git a/results/classifier/gemma3:27b/instruction/618 b/results/classifier/gemma3:27b/instruction/618 new file mode 100644 index 000000000..eaab679ff --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/618 @@ -0,0 +1,98 @@ + + + +overflow condition code determined incorrectly after subtraction on s390x +Description of problem: +Paul Eggert found this bug, just by taking a look at the file `qemu/target/s390x/tcg/cc_helper.c`. + +The following program +[foo.c](/uploads/c1f425684fd661c4437950d7d8ddf31d/foo.c) +``` +#include <stdio.h> + +int overflow_32 (int x, int y) +{ + int sum; + return __builtin_sub_overflow (x, y, &sum); +} + +int overflow_64 (long long x, long long y) +{ + long sum; + return __builtin_sub_overflow (x, y, &sum); +} + +int a1 = 0; +int b1 = -2147483648; +long long a2 = 0L; +long long b2 = -9223372036854775808L; + +int main () +{ + { + int a = a1; + int b = b1; + printf ("a = 0x%x, b = 0x%x\n", a, b); + printf ("no_overflow = %d\n", ! overflow_32 (a, b)); + } + { + long long a = a2; + long long b = b2; + printf ("a = 0x%llx, b = 0x%llx\n", a, b); + printf ("no_overflow = %d\n", ! overflow_64 (a, b)); + } +} +``` +should print +``` +a = 0x0, b = 0x80000000 +no_overflow = 0 +a = 0x0, b = 0x8000000000000000 +no_overflow = 0 +``` +However, when compiled as an s390x program and executed through qemu 6.1.0 (Linux user-mode), it prints 'no_overflow = 1' twice. +``` +$ s390x-linux-gnu-gcc-10 --version +s390x-linux-gnu-gcc-10 (Ubuntu 10.3.0-1ubuntu1~20.04) 10.3.0 +``` + +``` +$ s390x-linux-gnu-gcc-10 -static foo.c +$ ~/inst-qemu/6.1.0/bin/qemu-s390x a.out +a = 0x0, b = 0x80000000 +no_overflow = 1 +a = 0x0, b = 0x8000000000000000 +no_overflow = 1 +``` + +``` +$ s390x-linux-gnu-gcc-10 -O2 -static foo.c +$ ~/inst-qemu/6.1.0/bin/qemu-s390x a.out +a = 0x0, b = 0x80000000 +no_overflow = 1 +a = 0x0, b = 0x8000000000000000 +no_overflow = 1 +``` + +The code generated by 's390x-linux-gnu-gcc-10 -O2' makes use of the 'o' (overflow / ones) condition code: +``` +overflow_64: + lgr %r1,%r2 ;; copy a into %r1 + lghi %r2,0 + sgr %r1,%r3 ;; subtract b from a + bnor %r14 ;; if no overflow, return %r2 = 0 + lghi %r2,1 + br %r14 ;; otherwise, return %r2 = 1 +``` + +The condition code and the overflow bit are defined in the z/Architecture Principles of Operation (POP) http://publibfi.boulder.ibm.com/epubs/pdf/dz9zr011.pdf page 7-5 / 7-6 / 7-388 : "In mathematical terms, signed addition and subtraction produce a fixed-point overflow when the result is outside the range of representation for signed binary integers." + +I conclude that the bug is in QEMU: QEMU does not set the overflow condition code correctly. +Steps to reproduce: +[foo.static.s390x](/uploads/e4b79b019db590f3a4b13cac41e57ba6/foo.static.s390x) +(the result of "s390x-linux-gnu-gcc-10 -static -O2 foo.c -o foo.static.s390x") + +1. `qemu-s390x foo.static.s390x` +Additional information: +The attached patch fixes it. +[0002-s390x-Fix-determination-of-overflow-condition-code-a.patch](/uploads/8d414f84fe0ed36bf07bd28f5e7836ab/0002-s390x-Fix-determination-of-overflow-condition-code-a.patch) diff --git a/results/classifier/gemma3:27b/instruction/754 b/results/classifier/gemma3:27b/instruction/754 new file mode 100644 index 000000000..1b78c2d09 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/754 @@ -0,0 +1,210 @@ + + + +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/gemma3:27b/instruction/796480 b/results/classifier/gemma3:27b/instruction/796480 new file mode 100644 index 000000000..3fe14f69e --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/796480 @@ -0,0 +1,48 @@ + + + +Addresses with 4GB differences are consider as one single address in QEMU + +THIS IS THE ISSUE OF USER MODE EMULATION +Information about guest and host +********************************** +guest: 64 bit x86 user mode binary +host: 32 bit Linux OS +uname -a :Linux KICS-HPCNL-32blue 2.6.33.3-85.fc13.i686.PAE #1 SMP +architecture: intel64 +Bug Description +**************** +for memory reference instructions, suppose I have two addresses in guest address space(64 bit) +0x220000000 +0x320000000 +as lower 32 bit part of both addresses are same, when particular instructions are translated into host code(32 bit) +in both above cases the value is loaded from same memory and we get same value. where actual behaviour was to get two different values. +here is the program which i used to test: +#include <stdio.h> +#include <stdlib.h> +#include <limits.h> +#define SIZE 4294967298 /* 4Gib*/ + +int main() { + char *array; + unsigned int i; + + array = malloc(sizeof(char) * SIZE); + if(array == NULL) { + fprintf(stderr, "Could not allocate that much memory"); + return 1; } + array[0] = 'a'; + array[SIZE-2] = 'z'; + printf("array[SIZE-2] = %c array[0] = %c\n",array[SIZE-2], array[0]); + return 0; +} +I have 8 gib RAM +I compiled this program on 64 bit linux and run this on 32 bit linux with qemu +QEMU command line and output +********************************** +$x86_64-linux-user/qemu-x86_64 ~/ar_x86 +output: array[SIZE-1] = z,array[0] = z +Release information +******************** +x86_64 binary is tested with latest release : qemu-0.14.1 +and with current development tree as well( live code of QEMU using git) \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/799 b/results/classifier/gemma3:27b/instruction/799 new file mode 100644 index 000000000..2a038a0be --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/799 @@ -0,0 +1,50 @@ + + + +TCG Optimizer crashes on AArch64 SVE2 instruction +Description of problem: +QEMU crashes due to an assertion in the TCG optimizer when optimizing an SVE2 instruction: +``` +Unrecognized operation 145 in do_constant_folding. +../tcg/optimize.c:458: tcg fatal error +``` +Steps to reproduce: +1. Compile the following minimized reproducer: (a pre-compiled image is provided for convenience - [reproducer.img](/uploads/0bddbfac55306a297fee59dd2f6923cf/reproducer.img)) +```asm +.org 0x0 +entry: + mrs x1, cptr_el3 + orr x9, x1, #0x100 + msr cptr_el3, x9 + + msr cptr_el2, xzr + + mov x1, #0x3 + mrs x9, cpacr_el1 + bfi x9, x1, #16, #2 + bfi x9, x1, #20, #2 + msr cpacr_el1, x9 + + mov x9, 512 + mov x0, x9 + asr x0, x0, 7 + sub x9, x0, #1 + msr zcr_el1, x9 + + mov x9, 512 + mov x0, x9 + asr x0, x0, 7 + sub x9, x0, #1 + msr zcr_el2, x9 + + mov x9, 512 + mov x0, x9 + asr x0, x0, 7 + sub x9, x0, #1 + msr zcr_el3, x9 + + uqxtnt z11.s, z22.d +``` +2. Execute it using the command line given above. +Additional information: +I tested latest master as well, and the problem persists. diff --git a/results/classifier/gemma3:27b/instruction/824 b/results/classifier/gemma3:27b/instruction/824 new file mode 100644 index 000000000..a93e2e869 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/824 @@ -0,0 +1,15 @@ + + + +x86_64 Translation Block error (cmp eax, 0x6; jnle 0x524) +Description of problem: +`Qemu` produces a Translation block of 4 instructions: +``` +0x0000558a53039ffc: 83f806 (cmp eax, 0x6) +0x0000558a53039fff: 0f (nothing) +0x0000558a53039ffc: 83f806 (cmp eax, 0x6) +0x0000558a53039fff: 0f8f1e050000 (jnle 0x524) +``` +This problem occurs several time with different addresses but the same pattern: +- 1st and 3th instructions are the same (both addresses and opcodes); +- 2nd is the prefix of the 4th (same addresses). diff --git a/results/classifier/gemma3:27b/instruction/826 b/results/classifier/gemma3:27b/instruction/826 new file mode 100644 index 000000000..d79f7cf28 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/826 @@ -0,0 +1,19 @@ + + + +AArch64 SVE2 LDNT1SB (vector plus scalar) load address incorrectly calculated +Description of problem: +During execution of the following SVE2 instruction: +`ldnt1sb {z6.d}, p3/z, [z14.d, x9]` +with the following register state: +``` +(gdb) p $p3 +$1 = {0x7, 0x0, 0x74, 0x0, 0x43, 0x0, 0x29, 0x0, 0x47, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x47, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x66, 0xe4, 0x64, 0x0, 0x0, 0x0, 0x0, 0x0, 0x20, 0x11, 0x31, 0x1, 0x0, 0x0, 0x0, 0x0, 0x20, 0x11, 0x31, 0x1, 0x0, 0x0, 0x0, 0x0, 0xb0, 0x8b, 0x49, 0x34, 0xfc, 0x7f, 0x0, 0x0, 0xe0, 0x71, 0x30, 0x1, 0x0, 0x0, 0x0, 0x0} +(gdb) p $z14.d.u +$2 = {0x3bdeaa30, 0x3bdeaa33, 0x3bdeaa36, 0x3bdeaa39, 0x3bdeaa3c, 0x3bdeaa3f, 0x3bdeaa42, 0x3bdeaa45} +(gdb) p $x9 +$3 = 0x0 +``` +QEMU produces a data abort due to an address fault on address `0x5EE45E4E`, which it clearly should not have tried to load. +Additional information: +A quick look at the implementation of the LDNT1SB instruction in QEMU points to the following commit: https://gitlab.com/qemu-project/qemu/-/commit/cf327449816d5643106445420a0b06b0f38d4f01 which simply redirects to SVE's LD1SB handler. As these instructions use a new flavor of SVE scatter/gather loads (vector plus scalar) which SVE LD1SB does not support, I wonder if the LD1SB handler simply decodes it as the wrong instruction and treats it as a (scalar plus vector) instruction, which LD1SB does support, but whose address calculation is completely different. diff --git a/results/classifier/gemma3:27b/instruction/837 b/results/classifier/gemma3:27b/instruction/837 new file mode 100644 index 000000000..3f61a028a --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/837 @@ -0,0 +1,33 @@ + + + +x86 user: icebp/int1 raises wrong signal +Description of problem: +This is a relatively minor inaccuracy. When `icebp` (`F1`) is executed, it raises `SIGILL` in QEMU, where the behavior on baremetal Linux (on an old Intel Core i5-430m) is to raise `SIGTRAP`. + +Specifically, on the architectural level, `icebp` raises `#DB` without affecting `dr6`. + +This also happens on an AArch64 host. +``` +$ ./icebp +Trace/breakpoint trap +$ qemu-x86_64 ./icebp +qemu: uncaught target signal 4 (Illegal instruction) - core dumped +Illegal instruction +``` +Steps to reproduce: +1. Compile this file using `gcc -nostdlib -static icebp.S -o icebp`, optionally with `-m32` to test i386 +``` + .globl _start +_start: + .byte 0xF1 // gas doesn't assemble this instruction opcode but it disassembles it +#ifdef __x86_64__ + mov $60, %eax + syscall +#else + mov $1, %eax + int $0x80 +#endif +``` +2. Run on baremetal. Notice how it raises `SIGTRAP` according to the shell job control message +3. Run on qemu-user. Notice how it raises `SIGILL`. diff --git a/results/classifier/gemma3:27b/instruction/890 b/results/classifier/gemma3:27b/instruction/890 new file mode 100644 index 000000000..26d32f2ea --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/890 @@ -0,0 +1,4 @@ + + + +Misinterpretation of arm neon invalid insn diff --git a/results/classifier/gemma3:27b/instruction/904308 b/results/classifier/gemma3:27b/instruction/904308 new file mode 100644 index 000000000..93fdd56b6 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/904308 @@ -0,0 +1,101 @@ + + + +x86: BT/BTS/BTR/BTC: ZF flag is unaffected + +Hello! + +Bug was found in qemu.git. +See target-i386/translate.c: + + case 0x1ba: /* bt/bts/btr/btc Gv, im */ + ot = dflag + OT_WORD; + modrm = ldub_code(s->pc++); + op = (modrm >> 3) & 7; + mod = (modrm >> 6) & 3; + rm = (modrm & 7) | REX_B(s); + if (mod != 3) { + s->rip_offset = 1; + gen_lea_modrm(s, modrm, ®_addr, &offset_addr); + gen_op_ld_T0_A0(ot + s->mem_index); + } else { + gen_op_mov_TN_reg(ot, 0, rm); + } + /* load shift */ + val = ldub_code(s->pc++); + gen_op_movl_T1_im(val); + if (op < 4) + goto illegal_op; + op -= 4; + goto bt_op; + case 0x1a3: /* bt Gv, Ev */ + op = 0; + goto do_btx; + case 0x1ab: /* bts */ + op = 1; + goto do_btx; + case 0x1b3: /* btr */ + op = 2; + goto do_btx; + case 0x1bb: /* btc */ + op = 3; + do_btx: + ot = dflag + OT_WORD; + modrm = ldub_code(s->pc++); + reg = ((modrm >> 3) & 7) | rex_r; + mod = (modrm >> 6) & 3; + rm = (modrm & 7) | REX_B(s); + gen_op_mov_TN_reg(OT_LONG, 1, reg); + if (mod != 3) { + gen_lea_modrm(s, modrm, ®_addr, &offset_addr); + /* specific case: we need to add a displacement */ + gen_exts(ot, cpu_T[1]); + tcg_gen_sari_tl(cpu_tmp0, cpu_T[1], 3 + ot); + tcg_gen_shli_tl(cpu_tmp0, cpu_tmp0, ot); + tcg_gen_add_tl(cpu_A0, cpu_A0, cpu_tmp0); + gen_op_ld_T0_A0(ot + s->mem_index); + } else { + gen_op_mov_TN_reg(ot, 0, rm); + } + bt_op: + tcg_gen_andi_tl(cpu_T[1], cpu_T[1], (1 << (3 + ot)) - 1); + switch(op) { + case 0: + tcg_gen_shr_tl(cpu_cc_src, cpu_T[0], cpu_T[1]); + tcg_gen_movi_tl(cpu_cc_dst, 0); <<<<<<<<<<<<<<<<<<<<<< always set zf + break; + case 1: + tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]); + tcg_gen_movi_tl(cpu_tmp0, 1); + tcg_gen_shl_tl(cpu_tmp0, cpu_tmp0, cpu_T[1]); + tcg_gen_or_tl(cpu_T[0], cpu_T[0], cpu_tmp0); + break; + case 2: + tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]); + tcg_gen_movi_tl(cpu_tmp0, 1); + tcg_gen_shl_tl(cpu_tmp0, cpu_tmp0, cpu_T[1]); + tcg_gen_not_tl(cpu_tmp0, cpu_tmp0); + tcg_gen_and_tl(cpu_T[0], cpu_T[0], cpu_tmp0); + break; + default: + case 3: + tcg_gen_shr_tl(cpu_tmp4, cpu_T[0], cpu_T[1]); + tcg_gen_movi_tl(cpu_tmp0, 1); + tcg_gen_shl_tl(cpu_tmp0, cpu_tmp0, cpu_T[1]); + tcg_gen_xor_tl(cpu_T[0], cpu_T[0], cpu_tmp0); + break; + } + s->cc_op = CC_OP_SARB + ot; + if (op != 0) { + if (mod != 3) + gen_op_st_T0_A0(ot + s->mem_index); + else + gen_op_mov_reg_T0(ot, rm); + tcg_gen_mov_tl(cpu_cc_src, cpu_tmp4); + tcg_gen_movi_tl(cpu_cc_dst, 0); <<<<<<<<<<<<<<<<<<<<<< always set zf + } + break; + +always set zf... + +There is fixed patch. \ No newline at end of file diff --git a/results/classifier/gemma3:27b/instruction/947 b/results/classifier/gemma3:27b/instruction/947 new file mode 100644 index 000000000..74f0d403d --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/947 @@ -0,0 +1,16 @@ + + + +TCG AARCH64 Segmentation fault when helper function is called +Description of problem: +Segmentation fault in the TCG thread. +The issue occurs in the generated code when branching to (helper)lookup_tb_ptr (see op longs). +It seems that the generated instruction don't load the upper32 of the address of lookup_tb_ptr in the register before branching to it. According to LLDB, the program tries to access 0x1cffe060 while the right address 0x7ff71cffe060 (see debugger logs). +Additional information: +The issue seems to be located at https://gitlab.com/qemu-project/qemu/-/blob/master/tcg/aarch64/tcg-target.c.inc#L1091 +`t2 = t1 & ~(0xffffUL << s1);`. +The fix would be `t2 = t1 & ~(0xffffULL << s1);` + + +[lldb.log](/uploads/6a1d57eaecae4a375c6ada7384489876/lldb.log) +[qemu_segmentation.log](/uploads/e3c2d6d42291ff7d1ff8d37341e3da1d/qemu_segmentation.log) diff --git a/results/classifier/gemma3:27b/instruction/952 b/results/classifier/gemma3:27b/instruction/952 new file mode 100644 index 000000000..08f0cf817 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/952 @@ -0,0 +1,100 @@ + + + +qemu: uncaught target signal 5 (Trace/breakpoint trap) +Description of problem: +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 + +And I have check that the bug(https://bugs.launchpad.net/qemu/+bug/1873898) is fixed. + +But it's coredump. + +I found that bkpt instruction is not recognized, the bkpt is in 0x0000a608. + +host： +``` +$qemu-arm -g 12345 hello +``` +service: +``` +$gdb-multiarch hello +(gdb) target remote localhost:12345 +Remote debugging using localhost:12345 +0x0000a602 in _start () +(gdb) ni +0x0000a604 in _start () +(gdb) +0x0000a608 in _start () +(gdb) +0x0000a608 in _start () +``` +Another way to check: +``` +$gdb qemu-arm +(gdb) run hello +(gdb) bt +#0 0x00007ffff79474ba in __GI___sigsuspend (set=set@entry=0x7fffffffd9d8) at ../sysdeps/unix/sysv/linux/sigsuspend.c:26 +#1 0x000055555573bfff in dump_core_and_abort (target_sig=target_sig@entry=5) at ../linux-user/signal.c:772 +#2 0x000055555573c3c8 in handle_pending_signal (cpu_env=cpu_env@entry=0x555555da5940, sig=sig@entry=5, k=k@entry=0x555555e60e00) at ../linux-user/signal.c:1099 +#3 0x000055555573de8c in process_pending_signals (cpu_env=cpu_env@entry=0x555555da5940) at ../linux-user/signal.c:1175 +#4 0x0000555555622070 in cpu_loop (env=0x555555da5940) at ../linux-user/arm/cpu_loop.c:472 +#5 0x0000555555603cf4 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../linux-user/main.c:883 +(gdb) up +#1 0x000055555573bfff in dump_core_and_abort (target_sig=target_sig@entry=5) at ../linux-user/signal.c:772 +772 sigsuspend(&act.sa_mask); +(gdb) +#2 0x000055555573c3c8 in handle_pending_signal (cpu_env=cpu_env@entry=0x555555da5940, sig=sig@entry=5, k=k@entry=0x555555e60e00) at ../linux-user/signal.c:1099 +1099 dump_core_and_abort(sig); +(gdb) +#3 0x000055555573de8c in process_pending_signals (cpu_env=cpu_env@entry=0x555555da5940) at ../linux-user/signal.c:1175 +1175 handle_pending_signal(cpu_env, sig, &ts->sync_signal); +(gdb) +#4 0x0000555555622070 in cpu_loop (env=0x555555da5940) at ../linux-user/arm/cpu_loop.c:472 +472 process_pending_signals(env); +(gdb) l +467 default: +468 error: +469 EXCP_DUMP(env, "qemu: unhandled CPU exception 0x%x - aborting\n", trapnr); +470 abort(); +471 } +472 process_pending_signals(env); +473 } +474 } +475 +476 void target_cpu_copy_regs(CPUArchState *env, struct target_pt_regs *regs) +(gdb) p cpu_exec(cs) +$2 = 7 +``` +Here process_pending_signals(env) gives SIGTRAP?? + +Here is my binary: +[hello](/uploads/7225e1f1c5a61ace40f90d5d2401a758/hello) diff --git a/results/classifier/gemma3:27b/instruction/979 b/results/classifier/gemma3:27b/instruction/979 new file mode 100644 index 000000000..3c6e7967d --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/979 @@ -0,0 +1,10 @@ + + + +s390x floating point conversion functions broken +Description of problem: +While collecting additional reference files for float_convs (and float_convd) I noticed that the s390x handling of some cases is broken. See diff for details: + +``` + diff -y tests/tcg/s390x-linux-user/float_convs.out ../../tests/tcg/s390x/float_convs.ref +# diff --git a/results/classifier/gemma3:27b/instruction/984 b/results/classifier/gemma3:27b/instruction/984 new file mode 100644 index 000000000..ec5ada195 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/984 @@ -0,0 +1,26 @@ + + + +QEMU i386 fldl instruction is affected by the precision control bits of the FPU control word +Description of problem: +~~The QEMU softfloat float64_to_floatx80 implementation is broken and does not produce correct results.~~ QEMU i386 fldl instruction is affected by the precision control bits of the FPU control word. + +``` +IN = 1234.567890 (0x40934a4584f4c6e7) +OUT = 1234.567871 (0x40099a522c0000000000) +``` + +This bug was introduced in the QEMU commit qemu/qemu@8ae5719 as part of the switchover to FloatParts, and is still present in the latest tag (v7.0.0-rc4 as of now). + +Prior to the offending commit: + +``` +IN = 1234.567890 (0x40934a4584f4c6e7) +OUT = 1234.567890 (0x40099a522c27a6373800) +``` + +This breaks the i386 emulation of `fldl st(0)` (`helper_fldl_ST0`). +Steps to reproduce: +Call `float64_to_floatx80` with the input value of `1234.567890 (0x40934a4584f4c6e7)` and see the returned result. +Additional information: +See https://github.com/zephyrproject-rtos/sdk-ng/issues/461 diff --git a/results/classifier/gemma3:27b/instruction/993 b/results/classifier/gemma3:27b/instruction/993 new file mode 100644 index 000000000..2486b5077 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/993 @@ -0,0 +1,84 @@ + + + +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) +``` diff --git a/results/classifier/gemma3:27b/instruction/998 b/results/classifier/gemma3:27b/instruction/998 new file mode 100644 index 000000000..b66ece524 --- /dev/null +++ b/results/classifier/gemma3:27b/instruction/998 @@ -0,0 +1,63 @@ + + + +AArch64: SCTLR_EL1.BT0 set incorrectly in user mode +Description of problem: +PACIASP normally acts as a BTI landing pad, but not in every situation. When SCTLR_EL1.BT is set, PACIASP checks that the indirect branch originates from X16 or X17 when the indirect branch is taken from a BTI guarded area. Linux sets this bit, ideally QEMU-user should too. This sample program should crash with a SIGILL if QEMU is working correctly, otherwise it will crash with a SIGSEGV. + + #include <stdint.h> + #include <stdlib.h> + #include <unistd.h> + #include <string.h> + #include <stdio.h> + #include <sys/mman.h> + + // PACIASP is a valid BTI landing pad, but there are some conditions + // under Linux which sets SCTLR_ELx.BT0 = 1. In this mode, a branch + // onto a PACIASP landing pad is only valid if it originates from + // x16 or x17 (i.e. br x17 is OK, br x3 is not). + // More info on page D5-4851 of the Arm Architecture Reference Manual (ARM DDI 0487H.a). + + // Sample function which starts with a paciasp instruction + // (comes from -mbranch-protection=pac-ret+leaf) + void indirect_fn(int i) { + // paciasp instruction inserted here - should crash with SIGILL here if everything's operating OK. + i = i+1; + // Can't access this function from the copied location, so will segfault. + fprintf(stderr, "reachable\n"); + } + + int main(int argc, char **argv) { + // It's difficult to get a whole binary BTI compatible without the appropriate crtbegin etc + // so instead map a page and copy the sample function there. + void *e = mmap(0, getpagesize(), PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); + if (e == MAP_FAILED) { + return 1; + } + memcpy(e, (void*)indirect_fn, 64); + mprotect(e, getpagesize(), PROT_READ | PROT_EXEC | PROT_BTI); + + // paciasp is a valid landing pad if the branch comes from an unprotected area, + // so to ensure that we're protected - assemble an intermediate shim that's also PROT_BTI. + void *f = mmap(0, getpagesize(), PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); + if (f == MAP_FAILED) { + return 1; + } + uint32_t *x = (uint32_t*)f; + x[0] = 0xd503245fuL; // bti c + x[1] = 0xd61f0060uL; // br x1 - n.b. must be BR + mprotect(f, getpagesize(), PROT_READ | PROT_EXEC | PROT_BTI); + + // Jump to the shim + asm volatile ( + "mov x3, %0\n" + "mov x2, %1\n" + "blr x2\n" + : : "p"(e), "p"(f) : "x2", "x3"); + + // Execution should not reach here + return 1; + } +Steps to reproduce: +1. Compile with `clang-12 -g --sysroot=/work/home/fedora-rootfs/fedora_aarch64 -o sample --target=aarch64-linux-gnu -mbranch-protection=pac-ret+leaf -march=armv8-a -O1 -g sample.c` or similar. +2. Run with `../qemu/build/qemu-aarch64 --cpu max -L ~/fedora-rootfs/fedora_aarch64 sample` |