diff options
Diffstat (limited to 'results/classifier/deepseek-r1:14b/output/assembly')
75 files changed, 1550 insertions, 0 deletions
diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1028 b/results/classifier/deepseek-r1:14b/output/assembly/1028 new file mode 100644 index 000000000..4e70835cf --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1028 @@ -0,0 +1,35 @@ + +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/deepseek-r1:14b/output/assembly/1030807 b/results/classifier/deepseek-r1:14b/output/assembly/1030807 new file mode 100644 index 000000000..76cb50ec6 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1030807 @@ -0,0 +1,35 @@ + +PCI host bridge should ignore 1- and 2-byte I/O accesses + +In PCI there are two IO modes. Deprecated Mode2 that uses single byte IO and Mode1 that uses 4byte IO. +According to the spec a host bridge that supports Mode1 should ignore all IO that is not 4bytes. + +> Anytime a host bridge sees a full DWORD I/O write from the host to +> CONFIG_ADDRESS, the bridge must latch the data into its CONFIG_ADDRESS +> register. On full DWORD I/O reads to CONFIG_ADDRESS, the bridge must return the +> data in CONFIG_ADDRESS. Any other types of accesses to this address (non-DWORD) +> have no effect on CONFIG_ADDRESS and are executed as normal I/O transactions on +> the PCI bus. Therefore, the only I/O Space consumed by this register is a DWORD at the +> given address. I/O devices that share the same address but use BYTE or WORD registers +> are not affected because their transactions will pass through the host bridge unchanged. + +In qemu the host bridge will accept 1-, 2-, and 4-byte reads/writes. That breakes plan9 guests that do not use the bios to access the PCI config space. + +have a look at: +http://code.google.com/p/plan9front/source/browse/sys/src/9/pc/pci.c + +In Lines 960-967 the check for PCI Mode1 is done. This check assumes that the 4-byte write at line 961 succeeds and the single byte write at 962 is ignored. +On qemu line 962 will not be ignored and the test in line 963 will fail. +The plan9 kernel will fall back to Mode2 which does not work. +The result is that the guest will not see any PCI devices. + +I do not really have an image that you guys could quickly check this with, but i could prepare one if need be. +An easy way to reproduce this in linux would be to stick an outb between those two lines from pci_check_type1(void). + +> outl(0x80000000, 0xCF8); ++ outb0x01, 0xcfb); +> if (inl(0xCF8) == 0x80000000 && pci_sanity_check(&pci_direct_conf1)) { + +I did not try this but i guess on real hardware the linux kernel would still work while it would not work anymore on qemu. + +I tried to come up with a patch but did not find a quick solution. I found that in hw/piic_pci.c sysbus_add_io is used which will register read/write functions for 1, 2, and 4 bytes. This is done in ioport.c ioport_register. I guess if i provided a patch you guys might not like it :). So i figured i should report the bug, let me know if you need any additional information. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1093 b/results/classifier/deepseek-r1:14b/output/assembly/1093 new file mode 100644 index 000000000..723d5bc35 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1093 @@ -0,0 +1,34 @@ + +RISC-V: signal frame is misaligned in signal handlers +Description of problem: +`qemu-user` misaligns the signal frame (to 4 bytes rather than 16 bytes) on RISC-V 64, e.g causing pointer misalignment diagnostics to be triggered by UBSan. +Steps to reproduce: +1. Create a C file with the following contents: +```c +#include <signal.h> +#include <stdio.h> + +void handler(int sig, siginfo_t *info, void *context) { + printf("signal occurred, info: %p, context: %p\n", info, context); +} + +int main() { + struct sigaction act; + act.sa_flags = SA_SIGINFO; + act.sa_sigaction = handler; + sigaction(SIGINT, &act, NULL); + + // Deliberately misalign the stack + asm volatile ("addi sp, sp, -4"); + + while(1); + // Unreachable +} +``` +2. Compile with an appropriate RISC-V toolchain and run with `qemu-riscv64 ./a.out`. +3. Send a `SIGINT` (e.g by hitting Ctrl-C), and observe that the signal frame will be misaligned: +``` +signal occurred, info: 0x400080025c, context: 0x40008002dc +``` +Additional information: +This issue is alluded to in the source code, see https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/riscv/signal.c#L68-69. It should be sufficient to change that constant to 15. diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1093691 b/results/classifier/deepseek-r1:14b/output/assembly/1093691 new file mode 100644 index 000000000..f684f30ce --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1093691 @@ -0,0 +1,33 @@ + +QEMU build fails on OpenBSD/mips64 + +Building QEMU 1.2.1 on OpenBSD/mips64 fails as follows although I believe QEMU was also broken with 1.1.x as well.. + +cc -I/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/slirp -I. -I/usr/obj/ports/qemu-1.2.1/qemu-1.2.1 -I/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/fpu -I/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg - +I/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/mips -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmis +sing-prototypes -fno-strict-aliasing -I/usr/local/include -I/usr/X11R6/include -Wno-redundant-decls -DTIME_MAX=INT_MAX -Wendif-labels -Wmissing-include-dirs -Wnested-externs -Wf +ormat-security -Wformat-y2k -Winit-self -Wold-style-definition -I/usr/local/include/libpng -DHAS_AUDIO -DHAS_AUDIO_CHOICE -DTARGET_PHYS_ADDR_BITS=64 -I.. -I/usr/obj/ports/qemu-1 +.2.1/qemu-1.2.1/target-i386 -DNEED_CPU_H -I/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/include -I/usr/local/include/libpng -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/gli +b-2.0/include -I/usr/local/include -MMD -MP -MT tcg/tcg.o -MF tcg/tcg.d -O2 -pipe -c -o tcg/tcg.o /usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg.c +In file included from /usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg.c:50: +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h: In function 'tcg_gen_div_i64': +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1229: error: 'TCG_TARGET_HAS_div_i64' undeclared (first use in this function) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1229: error: (Each undeclared identifier is reported only once +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1229: error: for each function it appears in.) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1231: error: 'TCG_TARGET_HAS_div2_i64' undeclared (first use in this function) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h: In function 'tcg_gen_rem_i64': +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1248: error: 'TCG_TARGET_HAS_div_i64' undeclared (first use in this function) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1250: error: 'TCG_TARGET_HAS_div2_i64' undeclared (first use in this function) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h: In function 'tcg_gen_divu_i64': +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1267: error: 'TCG_TARGET_HAS_div_i64' undeclared (first use in this function) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1269: error: 'TCG_TARGET_HAS_div2_i64' undeclared (first use in this function) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h: In function 'tcg_gen_remu_i64': +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1286: error: 'TCG_TARGET_HAS_div_i64' undeclared (first use in this function) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1288: error: 'TCG_TARGET_HAS_div2_i64' undeclared (first use in this function) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h: In function 'tcg_gen_ext8s_i64': +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1526: error: 'TCG_TARGET_HAS_ext8s_i64' undeclared (first use in this function) +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h: In function 'tcg_gen_ext16s_i64': +/usr/obj/ports/qemu-1.2.1/qemu-1.2.1/tcg/tcg-op.h:1536: error: 'TCG_TARGET_HAS_ext16s_i64' undeclared (first use in this function) +... + +Attached is the full build log. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1118 b/results/classifier/deepseek-r1:14b/output/assembly/1118 new file mode 100644 index 000000000..737c7ed54 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1118 @@ -0,0 +1,76 @@ + +[AVR] Interrupt skips to incorrect handler when raised after skipping instruction +Description of problem: +If interrupt is raised after instruction that can skip following instruction (for example `CPSE`), and skip condition is active, instead of correct vector, one after it is executed. + +This can happen only if CPSE instruction is at the end of translation block. Usually it is somewhere inside block and very rare arrangement of code is required to get into that error. +Steps to reproduce: +Real world scenario is waiting in busy loop for `std::atomic<bool>` set by interrupt, in bigger application, with optimized code and rare chance of code arrangement. Effect usually is landing in `__bad_interrupt` and reset, but can also be executing other interrupt handler. + +Synthetic example is: + +1. There must be instruction that can skip following instruction (for example `CPSE`), with always-active condition for skip +2. It must be placed in way, that it will be at the end of translation block. + + Example (addresses matter): +``` + ff8: 81 e0 ldi r24, 0x01 ; 1 + ffa: 88 13 cpse r24, r24 + ffc: 01 c0 rjmp .+2 ; 0x1000 + ffe: 80 e0 ldi r24, 0x00 ; 0 + 1000: 00 00 nop +``` + +3. It should be busy-looped to raise chances of encountering that code +4. Any external interrupt should be generated + - the simplest is UART RX on stdin raised by key presses + +Fully working example attached, with ELF file, annotated C code, ASM dump, and Makefile that allows compiling and running this scenario (but I don't guarantee that self-compiling would always generate this error - it can move code a bit). + +(please adjust paths to GCC and QEMU in Makefile before using) + +[avr-irq-fail.zip](/uploads/b702104098a31754d544d6ae6e60e074/avr-irq-fail.zip) + +Running by command: + + ./qemu-system-avr -machine arduino-uno -nographic -monitor null -serial stdio -bios fail.elf + +And then press any key until error happens. + +It is largely machine independent, I originally encountered that on custom Atmega644 machine. +Additional information: +Annotated execution log output of `in_asm`, real-world example: + +``` +---------------- +IN: _ZNKSt6atomicIbEcvbEv +0x00000ff4: MOVW r31:r30, r25:r24 +0x00000ff6: LDDZ r25, Z+0 +0x00000ff8: LDI r24, 1 +0x00000ffa: CPSE r25, r1 // <-------------------- it must looks like that, with CPSE at the end + +---------------- +IN: _ZNKSt6atomicIbEcvbEv +0x00000ffc: RJMP .+2 + +---------------- +IN: _ZNKSt6atomicIbEcvbEv +0x00001000: RET +... +``` +and then: +``` +// <-------------------- INT 20 raised +... +---------------- +IN: +0x00000050: JMP 0x1002 // <-- correct vector loaded... + +---------------- +IN: +0x00000054: JMP 0x1012 // <-- ...but skipping to one after that... + +---------------- +IN: __vector_21 // <-- ...and executing incorrect handler +... +``` diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1131 b/results/classifier/deepseek-r1:14b/output/assembly/1131 new file mode 100644 index 000000000..71f4cc1f0 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1131 @@ -0,0 +1,21 @@ + +Multiboot: could not move values from provided mmap to another address directly. +Description of problem: +When using `-kernel` to load a Multiboot file which requires a memory map(MULTIBOOT_MEMORY_INFO flag) and trying to move the values in the provided mmap entries to another address directly, QEMU reboots. +```c +xxx = mmap->addr; +``` + +When moving with volatile, everything works well: +```c +volatile unsigned long long addr = mmap->addr; +xxx = addr; +``` +Steps to reproduce: +1. Source code here: [github/xtexChooser/toop/boot/multiboot/src/multiboot.c](https://github.com/xtexChooser/toop/blob/51153319d4f2320ae9a9277ffffad3f67a335fe9/boot/multiboot/src/multiboot.c#L32) +2. Minimized reproduce: [gist.github.com/xtexChooser/22017d662c8144b7abcb0b18c2afb09c](https://gist.github.com/xtexChooser/22017d662c8144b7abcb0b18c2afb09c) +3. I am sure that 0x00001210 is writable, it is empty in the memory map and QEMU works correctly when writing a zero value to here. +4. The reproducer is available without any module, when it works, it should keep running without any output, if QEMU reboots, the screen should flash as it clears and prints the BIOS information again. +5. If move with volatile(as the `multiboot_works.c` in reproducer), the reproducer works correctly. +Additional information: +# diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1173 b/results/classifier/deepseek-r1:14b/output/assembly/1173 new file mode 100644 index 000000000..e7c895004 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1173 @@ -0,0 +1,2 @@ + +is that `fsgnjn.s` will affect other bits except sign bit. diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1207896 b/results/classifier/deepseek-r1:14b/output/assembly/1207896 new file mode 100644 index 000000000..0b4d16196 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1207896 @@ -0,0 +1,4 @@ + +binfmt wrapper for argv[0] handling + +Please, add patch https://lists.gnu.org/archive/html/qemu-devel/2011-09/msg03841.html to upstream. 2 years have passed and this patch is not jet applied. Why? 99% GNU/Linux distribution uses qemu with this patch. It is 100% needed. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1258626 b/results/classifier/deepseek-r1:14b/output/assembly/1258626 new file mode 100644 index 000000000..649f87dd7 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1258626 @@ -0,0 +1,10 @@ + +Curses Keyboard Broken On OS X + +Whenever I run ``qemu-system-i386 -curses ...'' (with or without a ``-k en-gb'') on OS X 10.9, the keyboard does not work properly. For example, when attempting to switch to the QEMU console with Alt+2, I get: + +``Warning: no scancode found for keysym 226 +Warning: no scancode found for keysym 130 +Warning: no scancode found for keysym 172'' + +I have checked and these scancodes are not mentioned in ``share/qemu/keymaps/''. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1283519 b/results/classifier/deepseek-r1:14b/output/assembly/1283519 new file mode 100644 index 000000000..328389260 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1283519 @@ -0,0 +1,11 @@ + +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/deepseek-r1:14b/output/assembly/1285363 b/results/classifier/deepseek-r1:14b/output/assembly/1285363 new file mode 100644 index 000000000..a3eaad23e --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1285363 @@ -0,0 +1,46 @@ + +qemu-aarch64-static segfaults + +I've found a couple conditions that causes qemu-user-static to core dump fairly reliably - same with upstream git - while a binary built from suse's aarch64-1.6 branch seems to consistently work fine. + +Testing suggests they are resolved by the sigprocmask wrapper patches included in suse's tree. + + 1) dh_fixperms is a script that commonly runs at the end of a package build. + Its basically doing a `find | xargs chmod`. + 2) debootstrap --second-stage + This is used to configure an arm64 chroot that was built using + debootstrap on a non-native host. It is basically invoking a bunch of + shell scripts (postinst, etc). When it blows up, the stack consistently + looks like this: + +Core was generated by `/usr/bin/qemu-aarch64-static /bin/sh -e +/debootstrap/debootstrap --second-stage'. +Program terminated with signal SIGSEGV, Segmentation fault. +#0 0x0000000060058e55 in memcpy (__len=8, __src=0x7fff62ae34e0, +__dest=0x400082c330) at +/usr/include/x86_64-linux-gnu/bits/string3.h:51 +51 return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest)); +(gdb) bt +#0 0x0000000060058e55 in memcpy (__len=8, __src=0x7fff62ae34e0, +__dest=0x400082c330) at +/usr/include/x86_64-linux-gnu/bits/string3.h:51 +#1 stq_p (v=274886476624, ptr=0x400082c330) at +/mnt/qemu.upstream/include/qemu/bswap.h:280 +#2 stq_le_p (v=274886476624, ptr=0x400082c330) at +/mnt/qemu.upstream/include/qemu/bswap.h:315 +#3 target_setup_sigframe (set=0x7fff62ae3530, env=0x62d9c678, +sf=0x400082b0d0) at /mnt/qemu.upstream/linux-user/signal.c:1167 +#4 target_setup_frame (usig=usig@entry=17, ka=ka@entry=0x604ec1e0 +<sigact_table+512>, info=info@entry=0x0, set=set@entry=0x7fff62ae3530, +env=env@entry=0x62d9c678) + at /mnt/qemu.upstream/linux-user/signal.c:1286 +#5 0x0000000060059f46 in setup_frame (env=0x62d9c678, +set=0x7fff62ae3530, ka=0x604ec1e0 <sigact_table+512>, sig=17) at +/mnt/qemu.upstream/linux-user/signal.c:1322 +#6 process_pending_signals (cpu_env=cpu_env@entry=0x62d9c678) at +/mnt/qemu.upstream/linux-user/signal.c:5747 +#7 0x0000000060056e60 in cpu_loop (env=env@entry=0x62d9c678) at +/mnt/qemu.upstream/linux-user/main.c:1082 +#8 0x0000000060005079 in main (argc=<optimized out>, argv=<optimized +out>, envp=<optimized out>) at +/mnt/qemu.upstream/linux-user/main.c:4374 \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1308381 b/results/classifier/deepseek-r1:14b/output/assembly/1308381 new file mode 100644 index 000000000..54e2a538f --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1308381 @@ -0,0 +1,15 @@ + +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/deepseek-r1:14b/output/assembly/1422 b/results/classifier/deepseek-r1:14b/output/assembly/1422 new file mode 100644 index 000000000..7275f07bb --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1422 @@ -0,0 +1,16 @@ + +/wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0/tcg/ppc/tcg-target.c.inc:1882:9: error: couldn't allocate output register for constraint 'Q' +Description of problem: +Qemu 7.2.0 doesn't build on powerpc64le. +Steps to reproduce: +Build qemu. +Additional information: +``` +FAILED: libqemu-aarch64-softmmu.fa.p/tcg_tcg.c.o +cc -m64 -mlittle-endian -Ilibqemu-aarch64-softmmu.fa.p -I. -I.. -Itarget/arm -I../target/arm -Iqapi -Itrace -Iui -Iui/shader -I/usr/local/include/pixman-1 -I/usr/local/include -I/wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -fcolor-diagnostics -Wall -Winvalid-pch -std=gnu11 -O2 -g -iquote . -iquote /wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0 -iquote /wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0/include -iquote /wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0/tcg/ppc -pthread -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -Wno-psabi -Wno-gnu-variable-sized-type-not-at-end -fstack-protector-strong -O2 -pipe -fstack-protector-strong -fno-strict-aliasing '-DPREFIX=\""/usr/local\""' -fPIE -DNEED_CPU_H '-DCONFIG_TARGET="aarch64-softmmu-config-target.h"' '-DCONFIG_DEVICES="aarch64-softmmu-config-devices.h"' -MD -MQ libqemu-aarch64-softmmu.fa.p/tcg_tcg.c.o -MF libqemu-aarch64-softmmu.fa.p/tcg_tcg.c.o.d -o libqemu-aarch64-softmmu.fa.p/tcg_tcg.c.o -c ../tcg/tcg.c +In file included from ../tcg/tcg.c:432: +/wrkdirs/usr/ports/emulators/qemu/work-default/qemu-7.2.0/tcg/ppc/tcg-target.c.inc:1882:9: error: couldn't allocate output register for constraint 'Q' + asm("mr %%r6, %1\n\t" + ^ +1 error generated. +``` diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1435 b/results/classifier/deepseek-r1:14b/output/assembly/1435 new file mode 100644 index 000000000..e6f16b5dc --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1435 @@ -0,0 +1,17 @@ + +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/deepseek-r1:14b/output/assembly/1441 b/results/classifier/deepseek-r1:14b/output/assembly/1441 new file mode 100644 index 000000000..c373f48c8 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1441 @@ -0,0 +1,35 @@ + +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/deepseek-r1:14b/output/assembly/1452 b/results/classifier/deepseek-r1:14b/output/assembly/1452 new file mode 100644 index 000000000..c8ff664b9 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1452 @@ -0,0 +1,2 @@ + +Tricore: support for shuffle and syscall instruction diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1498 b/results/classifier/deepseek-r1:14b/output/assembly/1498 new file mode 100644 index 000000000..6755270f8 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1498 @@ -0,0 +1,6 @@ + +LDC, STC unimplemented in qemu-system-arm +Description of problem: +I used differential testing to compared the instruction consistency (ARMv7) between QEMU and raspberry pi 2B in system level and some inconsistency in LDC, SDC instruction was detected. + +The instructions run successfully in raspi2b, but cause undefined in QEMU. I found that LDC and SDC instructions remain unimplemented in QEMU. diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1527300 b/results/classifier/deepseek-r1:14b/output/assembly/1527300 new file mode 100644 index 000000000..4f7c34a40 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1527300 @@ -0,0 +1,10 @@ + +linux-user/elfload.c: byteswap function is not working when ELF is big endian + +I run qemu-mipsel for ELF with mips MSB(big endian), it always outputs error message: Invalid ELF image for this architecture. For the ELF I run: + +$file busybox + +ELF 32-bit MSB executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped + +The section header is not corrupted(MSB, corrputed section header table also outputs same error as above), when I run ELF with LSB, it works perfectly. I debugged with /linux-user/elfload.c, I am sure that the problem comes from byteswap function. But I don't know how to handle it. I really hope this can be fixed ASAP. Really appreciate your help. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1620 b/results/classifier/deepseek-r1:14b/output/assembly/1620 new file mode 100644 index 000000000..f603c8ec5 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1620 @@ -0,0 +1,95 @@ + +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/deepseek-r1:14b/output/assembly/1623 b/results/classifier/deepseek-r1:14b/output/assembly/1623 new file mode 100644 index 000000000..20cd6eba4 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1623 @@ -0,0 +1,10 @@ + +vec_lde and vec_expte semi-randomly produce the wrong results +Description of problem: +I found that while implementing the Altivec support for the rust [stdarch](https://github.com/rust-lang/stdarch). +Steps to reproduce: +1. Install rust nightly (e.g. using https://rustup.rs/) +2. `git clone https://github.com/rust-lang/stdarch` +3. You need to either cross compile or compile and run the tests for `crates/core_arch`. +Additional information: +Both `valgrind` and running on power9 produce the correct results diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1631625 b/results/classifier/deepseek-r1:14b/output/assembly/1631625 new file mode 100644 index 000000000..9987cd848 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1631625 @@ -0,0 +1,16 @@ + +target-mips/dsp_helper.c: two possible bad shifts + +target-mips/dsp_helper.c:3480:1: error: V629 Consider inspecting the '0x01 << (size + 1)' expression. Bit shifting of the 32-bit value with a subsequent expansion to the 64-bit type. + +Source code is + + temp = temp & ((0x01 << (size + 1)) - 1); + +If size >= 32, then better code might be + + temp = temp & ((0x01UL << (size + 1)) - 1); + +target-mips/dsp_helper.c:3509:1: error: V629 Consider inspecting the '0x01 << (size + 1)' expression. Bit shifting of the 32-bit value with a subsequent expansion to the 64-bit type. + +Duplicate \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1649 b/results/classifier/deepseek-r1:14b/output/assembly/1649 new file mode 100644 index 000000000..916d6fb9e --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1649 @@ -0,0 +1,18 @@ + +"slli" instruction before "la" and "csrw" sequence leads to failure in setting the cs register +Description of problem: +slli a0, a0, 8 (1) + la a0, mtimvec (2) + csrw mtvec, a0 (3) + mtimvec: (4) + +For the above assembly snippet, the mtvec could be successfully set to the value of a0 +without the presence of the line (1) or with the shift amount being zero. However, +the mtvec can never be set successfully with the presence of line (1). +Steps to reproduce: +1. Create a test.s file and put these 4 lines of assembly into the file +2. In terminal, run: "riscv64-unknown-elf-gcc -Ttext 0x80000000 -c test.s -o test", "riscv64-unknown-elf-objcopy test -S -O binary test", and "qemu-system-riscv64 test -s -S" +3. In another terminal window, run [riscv64-unknown-elf-gdb -ex "target remote localhost:1234" -ex "layout asm"]. Keep running si command in gdb until you are at 0x80000000 where you shall see the first instruction as shown in line (1). Then keep going till you have stepped over the instruction shown in line (3). Now, run "p $mtvec" in gdb, you shall see its value being 0. +4. Redo the above steps without line (1), you shall see mtvec loaded successfully with the correct value. +Additional information: + diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1650 b/results/classifier/deepseek-r1:14b/output/assembly/1650 new file mode 100644 index 000000000..fd369bb15 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1650 @@ -0,0 +1,15 @@ + +Consider doing runtime detection of MAP_FIXED_NOREPLACE +Description of problem: +``` +qemu-i386-static: Unable to reserve 0xfffff000 bytes of virtual address space at 0x1000 (Operation not supported) for use as guest address space (check your virtual memory ulimit setting, min_mmap_addr or reserve less using -R option) +``` +strace says +``` + mmap(0x1000, 4294963200, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE|MAP_FIXED_NOREPLACE, -1, 0) = -1 EOPNOTSUPP (Operation not supported) +``` +Steps to reproduce: +1. `apt install qemu-i386-static 32subsystem` +2. `strace qemu-i386-static /opt/32/bin/as` +Additional information: +Repeating the strace call in a minimal C program gives the same errno as expected -- the kernel is only 4.4. The problem here is that qemu only does `MAP_FIXED_NOREPLACE` feature detection at build-time via a `#ifndef` and even that behavior is poorly documented. Maybe do something at runtime? diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1693649 b/results/classifier/deepseek-r1:14b/output/assembly/1693649 new file mode 100644 index 000000000..9988e1ecc --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1693649 @@ -0,0 +1,12 @@ + +x86 pause misbehaves with -cpu haswell + +Using qemu-2.9.0 + +When booting NetBSD using '-cpu haswell -smp 4', the system fails to initialize the additional CPUs. It appears as though the "application processor" enters routine x86_pause() but never returns. + +x86_pause() is simply two assembler instructions: 'pause; ret;' + +Replacing the routine with 'nop; nop; ret;' allows the system to proceed, of course without the benefit of the pause instruction on spin-loops! + +Additionally, booting with '-cpu phenom -smp 4' also works, although the system does seem confused about the type of CPU being used. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1693667 b/results/classifier/deepseek-r1:14b/output/assembly/1693667 new file mode 100644 index 000000000..c1c7eb558 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1693667 @@ -0,0 +1,29 @@ + +-cpu haswell / broadwell have no MONITOR in features1 + +In qemu 2.9.0 if you run + + qemu-system-x86_64 -cpu Broadwell (or Haswell) + +then the CPU features1 flag include the SSE3 bit, but do NOT include the MONITOR/MWAIT bit. This is so even when the host includes the features. + + +Additionally, running qemu in this manner results in several error messages: + +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 + + +(Among possible other uses, the lack of the MONITOR feature bit causes NetBSD to fall-back on a +check-and-pause loop while an application CPU is waiting to be told to proceed by the boot CPU.) \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1727737 b/results/classifier/deepseek-r1:14b/output/assembly/1727737 new file mode 100644 index 000000000..cccb03cf4 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1727737 @@ -0,0 +1,26 @@ + +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/deepseek-r1:14b/output/assembly/1728325 b/results/classifier/deepseek-r1:14b/output/assembly/1728325 new file mode 100644 index 000000000..9caa818a5 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1728325 @@ -0,0 +1,61 @@ + +POWER8: Wrong behaviour with float-to-int punning + +Building a reduced test program with 'gcc -O2 -fno-inline -mcpu=power8' produces wrong results at runtime. I don't think gcc is at fault here. + +--- +#include <stdio.h> + +int getWord(const float x) +{ + return *(int*)&x; +} + +void main() +{ + int foo = getWord(+123.456f); + int bar = getWord(-123.456f); + + printf("%d\n", foo); + printf("%d\n", bar); + return; +} +--- + +This prints: +--- +0 +0 +--- + +Compiling with 'gcc -O2 -fno-inline -mcpu=power7' and you instead get the expected result: +--- +1123477881 +-1024005767 +--- + + +The different between the two programs is: + +--- power7.s ++++ power8.s +@@ -6,9 +6,9 @@ + .globl getWord + .type getWord, @function + getWord: +- stfs 1,-16(1) +- ori 2,2,0 +- lwa 3,-16(1) ++ xscvdpspn 0,1 ++ mfvsrwz 3,0 ++ extsw 3,3 + blr + .long 0 + .byte 0,0,0,0,0,0,0,0 + .size getWord,.-getWord + + +Seems like qemu doesn't handle xscvdpspn/mfvsrwz correctly. + +https://github.com/qemu/qemu/commit/7ee19fb9d682689d36c849576c808cf92e3bae40 +https://github.com/qemu/qemu/commit/f5c0f7f981333da59cc35c3210d05ec1775c97c1 \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1750 b/results/classifier/deepseek-r1:14b/output/assembly/1750 new file mode 100644 index 000000000..c2ed8d05b --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1750 @@ -0,0 +1,2 @@ + +target/ppc/translate.c - ppc_fixup_cpu and VSX - is still necessary? diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1751494 b/results/classifier/deepseek-r1:14b/output/assembly/1751494 new file mode 100644 index 000000000..aaac9ad89 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1751494 @@ -0,0 +1,17 @@ + +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. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1759264 b/results/classifier/deepseek-r1:14b/output/assembly/1759264 new file mode 100644 index 000000000..ddf635d2e --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1759264 @@ -0,0 +1,9 @@ + +fpu/softfloat: round_to_int_and_pack refactor broke TriCore ftoi insns + +After the refactor from ab52f973a504f8de0c5df64631ba4caea70a7d9e the bahaviour of int32_to_float32() was altered. + +helper_ftoi() in target/tricore/fpu_helper.c relied on int32_to_float32 to raise the invalid flag if the input was NaN to properly return 0. Likewise if the input is infinity. + +The obvious fix for softfloat would be to raise this flag in round_to_int_and_pack(). However, +I'm not sure if this breaks other targets and I have no easy way to test it. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1761401 b/results/classifier/deepseek-r1:14b/output/assembly/1761401 new file mode 100644 index 000000000..1fd3a60ab --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1761401 @@ -0,0 +1,11 @@ + +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/deepseek-r1:14b/output/assembly/1790 b/results/classifier/deepseek-r1:14b/output/assembly/1790 new file mode 100644 index 000000000..5645b063f --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1790 @@ -0,0 +1,30 @@ + +[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/deepseek-r1:14b/output/assembly/1824778 b/results/classifier/deepseek-r1:14b/output/assembly/1824778 new file mode 100644 index 000000000..aa50d5d8c --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1824778 @@ -0,0 +1,9 @@ + +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. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1834399 b/results/classifier/deepseek-r1:14b/output/assembly/1834399 new file mode 100644 index 000000000..a74be33c8 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1834399 @@ -0,0 +1,37 @@ + +Branch out of range on mips o32 building QEMU + +I build lib32-qemu which is a multilib variant for mips o32 on project Yocto with qemumips64. It finally runs command and fails: + + +mips-wrsmllib32-linux-gcc -meb -mabi=32 -mhard-float -fstack-protector-strong -Wformat -Wformat-security -Werror=format-security --sysroot=/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/lib32-recipe-sysroot +-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/lib32-recipe-sysroot/usr/include/pixman-1 -I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/qemu-4.0.0/dtc/libfdt -pthread -I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/lib32-recipe-sysroot/usr/include/glib-2.0 -I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/lib32-recipe-sysroot/usr/lib/glib-2.0/include +-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Og -g +-I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/qemu-4.0.0/capstone/include -I/mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/qemu-4.0.0/tests +-DCAPSTONE_USE_SYS_DYN_MEM -DCAPSTONE_HAS_ARM -DCAPSTONE_HAS_ARM64 -DCAPSTONE_HAS_POWERPC -DCAPSTONE_HAS_X86 +-c arch/AArch64/AArch64InstPrinter.c -o /mnt/docker/LIN1019-1459-ubuntu1604/tmp-glibc/work/mips-wrsmllib32-linux/lib32-qemu/4.0.0-r0/build/capstone/obj/arch/AArch64/AArch64InstPrinter.o + + + +And error messages: + +{standard input}: Assembler messages: +{standard input}:38045: Error: branch out of range +{standard input}:38269: Error: branch out of range +{standard input}:38493: Error: branch out of range +{standard input}:38717: Error: branch out of range +{standard input}:38941: Error: branch out of range +{standard input}:39165: Error: branch out of range +{standard input}:39389: Error: branch out of range +{standard input}:39613: Error: branch out of range +{standard input}:39728: Error: branch out of range +{standard input}:39990: Error: branch out of range +{standard input}:40252: Error: branch out of range +{standard input}:40514: Error: branch out of range +{standard input}:40776: Error: branch out of range +{standard input}:41038: Error: branch out of range + + +The gcc version is 9.1. I have verified that gcc 8.3 works. And there is no error when remove option '-Og' with gcc 9.1. + +I am not sure whether it is a defect of gcc 9.1 or capstone. Should it be fixed in capstone? Thanks. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1841592 b/results/classifier/deepseek-r1:14b/output/assembly/1841592 new file mode 100644 index 000000000..c3c8c0bc3 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1841592 @@ -0,0 +1,10 @@ + +ppc: softfloat float implementation issues + +Per bug #1841491, Richard Henderson (rth) said: +> The float test failure is part of a larger problem for target/powerpc in which all float +> routines are implemented incorrectly. They are all implemented as double operations with +> rounding to float as a second step. Which not only produces incorrect exceptions, as in +> this case, but incorrect > numerical results from the double rounding. +> +> This should probably be split to a separate bug... \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1847 b/results/classifier/deepseek-r1:14b/output/assembly/1847 new file mode 100644 index 000000000..f310c2535 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1847 @@ -0,0 +1,2 @@ + +TriCore missing ftoq31, ftoq31z, and q31tof instructions diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1856706 b/results/classifier/deepseek-r1:14b/output/assembly/1856706 new file mode 100644 index 000000000..6c7dd2c03 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1856706 @@ -0,0 +1,14 @@ + +target/mips/op_helper.c:971:duplicated branches ? + +qemu-4.2.0/target/mips/op_helper.c:971:8: warning: this condition has identical branches [-Wduplicated-branches] + +Source code is + + if (other_tc == other->current_tc) { + tccause = other->CP0_Cause; + } else { + tccause = other->CP0_Cause; + } + +Possible cut'n'paste error ? \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1859713 b/results/classifier/deepseek-r1:14b/output/assembly/1859713 new file mode 100644 index 000000000..302360357 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1859713 @@ -0,0 +1,26 @@ + +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/deepseek-r1:14b/output/assembly/1862986 b/results/classifier/deepseek-r1:14b/output/assembly/1862986 new file mode 100644 index 000000000..990b9e05a --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1862986 @@ -0,0 +1,65 @@ + +qemu-s390x segfaults + +All tested versions (2.11 and 4.2) qemu-s390x crashes with a segfault when run on an aarch64 odroid Ubuntu. + +Steps to reproduce: + +root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x "/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig" +Segmentation fault (core dumped) +root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-s390x --version +qemu-s390x version 4.2.0 +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers +root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x "/root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig" +Segmentation fault (core dumped) +root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-s390x --version +qemu-s390x version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.22) +Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers + + +qemu-arm does work on the same machine: + +root@odroid:~/workspace/bitcoin-core# /usr/bin/qemu-arm bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests +Running 4 test cases... + +*** No errors detected +root@odroid:~/workspace/bitcoin-core# /usr/local/bin/qemu-arm bitcoin-0.19.0.1-armhf/bin/test_bitcoin -t amount_tests +Running 4 test cases... + +*** No errors detected + + +What kind of debug information would be helpful for this issue report? + + +GDB for the self-compiled latest release is not particularly helpful: + +(gdb) run +Starting program: /usr/local/bin/qemu-s390x /root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1". +[New Thread 0x7fb7a2a140 (LWP 28264)] + +Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault. +0x000000555596b218 in __bss_start__ () +(gdb) bt +#0 0x000000555596b218 in __bss_start__ () +#1 0x00000055556120a8 in ?? () +#2 0x00000055579904b0 in ?? () +Backtrace stopped: previous frame inner to this frame (corrupt stack?) + +A bit more information is available in the version shipped by Ubuntu: + +(gdb) run +Starting program: /usr/bin/qemu-s390x /root/workspace/bitcoin-core/build/bitcoin-s390x-linux-gnu/src/test/test_bitcoin_orig +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1". +[New Thread 0x7fb7a01180 (LWP 28271)] + +Thread 1 "qemu-s390x" received signal SIGSEGV, Segmentation fault. +0x0000005555738f98 in code_gen_buffer () +(gdb) bt +#0 0x0000005555738f98 in code_gen_buffer () +#1 0x00000055555e96c8 in cpu_exec () +#2 0x00000055555ee430 in cpu_loop () +#3 0x00000055555c3328 in main () \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1881450 b/results/classifier/deepseek-r1:14b/output/assembly/1881450 new file mode 100644 index 000000000..f72c0c21d --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1881450 @@ -0,0 +1,24 @@ + +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/deepseek-r1:14b/output/assembly/1885350 b/results/classifier/deepseek-r1:14b/output/assembly/1885350 new file mode 100644 index 000000000..324817489 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1885350 @@ -0,0 +1,24 @@ + +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/deepseek-r1:14b/output/assembly/1888165 b/results/classifier/deepseek-r1:14b/output/assembly/1888165 new file mode 100644 index 000000000..d8759ff6c --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1888165 @@ -0,0 +1,15 @@ + +loopz/loopnz clearing previous instruction's modified flags on cx -> 0 + +If you run QBasic in qemu, printing a double-type single-digit number will print an extra decimal point (e.g. PRINT CDBL(3) prints "3.") that does not appear when running on a real CPU (or on qemu with -enable-kvm). I tracked this down to the state of the status flags after a loopnz instruction. + +After executing a sequence like this in qemu: + + mov bx,1 + mov cx,1 + dec bx ; sets Z bit in flags +A: loopnz A ; should not modify flags + +Z is incorrectly clear afterwards. loopz does the same thing (but not plain loop). Interestingly, inserting pushf+popf after dec results in Z set, so loopnz/loopz does not always clear Z itself but is rather interfering with the previous instruction's flag setting. + +Version 5.1.0-rc0, x86-64 host. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1901359 b/results/classifier/deepseek-r1:14b/output/assembly/1901359 new file mode 100644 index 000000000..88507e9e3 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1901359 @@ -0,0 +1,23 @@ + +ignore bit 0 in pci CONFIG_ADDRESS register write for Type 1 access + +I'v recently stumbled upon a bug in the Plan9 PCI config space access routines for config mode #1. + +The code used to set bit 0 in the CONFIG_ADDRESS register for a Type 1 access. + +This was most likely a misreading of the PCI local bus specification on our side. + +However, in the PCI local bus specification 3.0, it states the following: + +> 3.2.2.3.2 Software Generation of Configuration Transactions +> ... +> For Type 1 translations, the host bridge directly copies the contents of the +> CONFIG_ADDRESS register (excluding bits 31 and 0) onto the PCI AD lines during the +> address phase of a configuration transaction making sure that AD[1::0] is "01". + +note the: "excluding bits 31 and 0" + +What happens in qemu instead is that it uses bit 0 of the CONFIG_ADDRESS +register as part of the register offset (when it probably should ignore it) +when translating from Type 1 to Type 0 address. So once it reaches the device +behind the bridge the register address is off by one. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1904259 b/results/classifier/deepseek-r1:14b/output/assembly/1904259 new file mode 100644 index 000000000..016a538e2 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1904259 @@ -0,0 +1,30 @@ + +include/qemu/atomic.h:495:5: error: misaligned atomic operation may incur significant performance penalty (Clang 11; Ubuntu 16 i686) + +Hello. +I haven't found any "official" executables, for emulating RISC-V (32bit; 64bit) so I had to compile those myself. + +I found that auto-generated build scripts, for Ninja, contained some warnings interpreted as errors: + + +oceanfish81@gollvm:~/Desktop/qemu/build$ ninja -j 1 +[2/1977] Compiling C object libqemuutil.a.p/util_qsp.c.o +FAILED: libqemuutil.a.p/util_qsp.c.o +clang-11 -Ilibqemuutil.a.p -I. -I.. -Iqapi -Itrace -Iui -Iui/shader -I/usr/include/glib-2.0 -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/include/gio-unix-2.0/ -Xclang -fcolor-diagnostics -pipe -Wall -Winvalid-pch -Werror -std=gnu99 -O2 -g -m32 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -Wno-psabi -fstack-protector-strong -isystem /home/oceanfish81/Desktop/qemu/linux-headers -isystem linux-headers -iquote /home/oceanfish81/Desktop/qemu/tcg/i386 -iquote . -iquote /home/oceanfish81/Desktop/qemu -iquote /home/oceanfish81/Desktop/qemu/accel/tcg -iquote /home/oceanfish81/Desktop/qemu/include -iquote /home/oceanfish81/Desktop/qemu/disas/libvixl -pthread -Wno-unused-function -fPIC -MD -MQ libqemuutil.a.p/util_qsp.c.o -MF libqemuutil.a.p/util_qsp.c.o.d -o libqemuutil.a.p/util_qsp.c.o -c ../util/qsp.c +In file included from ../util/qsp.c:62: +In file included from /home/oceanfish81/Desktop/qemu/include/qemu/thread.h:4: +In file included from /home/oceanfish81/Desktop/qemu/include/qemu/processor.h:10: +/home/oceanfish81/Desktop/qemu/include/qemu/atomic.h:495:5: error: misaligned atomic operation may incur significant performance penalty [-Werror,-Watomic-alignment] + qatomic_set__nocheck(ptr, val); + ^ +/home/oceanfish81/Desktop/qemu/include/qemu/atomic.h:138:5: note: expanded from macro 'qatomic_set__nocheck' + __atomic_store_n(ptr, i, __ATOMIC_RELAXED) + ^ +/home/oceanfish81/Desktop/qemu/include/qemu/atomic.h:485:12: error: misaligned atomic operation may incur significant performance penalty [-Werror,-Watomic-alignment] + return qatomic_read__nocheck(ptr); + ^ +/home/oceanfish81/Desktop/qemu/include/qemu/atomic.h:129:5: note: expanded from macro 'qatomic_read__nocheck' + __atomic_load_n(ptr, __ATOMIC_RELAXED) + ^ +2 errors generated. +ninja: build stopped: subcommand failed. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1907137 b/results/classifier/deepseek-r1:14b/output/assembly/1907137 new file mode 100644 index 000000000..f9a17107b --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1907137 @@ -0,0 +1,37 @@ + +LDTR not properly emulated when MTE tag checks enabled at EL0 + +I am trying to boot Android (just the non-GUI parts for now) under QEMU with MTE enabled. This can be done by following the instructions here to build the fvp-eng target with MTE support: + +https://cs.android.com/android/platform/superproject/+/master:device/generic/goldfish/fvpbase/ + +and launching QEMU with the following command: + +qemu-system-aarch64 -kernel $ANDROID_PRODUCT_OUT/kernel -initrd $ANDROID_PRODUCT_OUT/combined-ramdisk.img -machine virt,mte=on -cpu max -drive driver=raw,file=$ANDROID_PRODUCT_OUT/system-qemu.img,if=none,id=system -device virtio-blk-device,drive=system -append "console=ttyAMA0 earlyprintk=ttyAMA0 androidboot.hardware=fvpbase androidboot.boot_devices=a003e00.virtio_mmio loglevel=9 printk.devkmsg=on buildvariant=eng" -m 512 -nographic -no-reboot + +If I do this then QEMU crashes like so: + +** +ERROR:../target/arm/mte_helper.c:558:mte_check_fail: code should not be reached +Bail out! ERROR:../target/arm/mte_helper.c:558:mte_check_fail: code should not be reached + +The error is caused by an MTE tag check fault from an LDTR instruction in __arch_copy_from_user. At this point TCF=0 and TCF0=2. + +I have this patch that gets me past the error but it is unclear whether this is the correct fix since there may be other confusion between TCF and TCF0 elsewhere. + +diff --git a/target/arm/mte_helper.c b/target/arm/mte_helper.c +index 153bd1e9df..aa5db4eac4 100644 +--- a/target/arm/mte_helper.c ++++ b/target/arm/mte_helper.c +@@ -552,10 +552,8 @@ static void mte_check_fail(CPUARMState *env, uint32_t desc, + case 0: + /* + * Tag check fail does not affect the PE. +- * We eliminate this case by not setting MTE_ACTIVE +- * in tb_flags, so that we never make this runtime call. + */ +- g_assert_not_reached(); ++ break; + + case 2: + /* Tag check fail causes asynchronous flag set. */ \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1934 b/results/classifier/deepseek-r1:14b/output/assembly/1934 new file mode 100644 index 000000000..1201b892e --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1934 @@ -0,0 +1,25 @@ + +Build failure on s390x with Clang 17 due to int128 alignment used in `__sync_` operations +Description of problem: +We experienced this downstream, but filing this here since the code still seems to be the same in git. + +https://reviews.llvm.org/D143813 introduced this warning since, according to the description, `__int128` +needs to be 8-byte aligned on s390 but the code in `host/include/generic/host/atomic128-ldst.h` unconditionally uses 16-byte alignment. + +The output is: + +``` +In file included from ../accel/tcg/cputlb.c:32: +In file included from /builddir/build/BUILD/qemu-8.1.0/include/exec/helper-proto-common.h:10: +In file included from /builddir/build/BUILD/qemu-8.1.0/include/qemu/atomic128.h:62: +/builddir/build/BUILD/qemu-8.1.0/host/include/generic/host/atomic128-ldst.h:68:15: error: __sync builtin operation MUST have natural alignment (consider using __atomic). [-Werror,-Wsync-alignment] + 68 | } while (!__sync_bool_compare_and_swap_16(ptr_align, old, new.i)); + | ^ +In file included from ../accel/tcg/cputlb.c:32: +In file included from /builddir/build/BUILD/qemu-8.1.0/include/exec/helper-proto-common.h:10: +In file included from /builddir/build/BUILD/qemu-8.1.0/include/qemu/atomic128.h:61: +/builddir/build/BUILD/qemu-8.1.0/host/include/generic/host/atomic128-cas.h:36:11: error: __sync builtin operation MUST have natural alignment (consider using __atomic). [-Werror,-Wsync-alignment] + 36 | r.i = __sync_val_compare_and_swap_16(ptr_align, c.i, n.i); + | ^ +2 errors generated. +``` diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1942 b/results/classifier/deepseek-r1:14b/output/assembly/1942 new file mode 100644 index 000000000..d488eadf1 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1942 @@ -0,0 +1,10 @@ + +GCC segfault (ICE) while building in qemu-user sparc64 +Steps to reproduce: +1. Follow Qemu-user [documentation](https://wiki.gentoo.org/wiki/Embedded_Handbook/General/Compiling_with_qemu_user_chroot) for Sparc64 +2. Attempt to build libpaper: `emerge -v app-text/libpaper-2.1.0:0/2` + +Resulting compilation will fail with an internal compilation error. +Additional information: +This can be tested by trying to [compile](/uploads/ba4585ea75fa157a34bf8f3ffb64bded/H1NM.i) with `gcc -mcpu=ultrasparc -O2 -c` instead of building the entire libpaper package. +Here is the [output.](/uploads/30a154eb602caa5a8b1bd82a6271d6d8/output.txt) diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1950 b/results/classifier/deepseek-r1:14b/output/assembly/1950 new file mode 100644 index 000000000..4762d0dcb --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1950 @@ -0,0 +1,10 @@ + +[AARCH64] GP bit (BTI) lost during two stages translation +Description of problem: +I noticed that the BTI faults were not reported. +That's because the GP (guarded page) information is lost during the two stages translation in get_phys_addr_twostage(). +The "guarded" information is correctly retrieved by the first call to get_phys_addr_nogpc() but overwritten by the the second call to get_phys_addr_nogpc(). +The call to combine_cacheattrs() copies cacheattrs1.guarded but this field is never modified. + +The attached patch fixes the issue for me. +[get_phys_addr_twostage_bti_gp_bit_lost_master.patch](/uploads/2fbe8090f92c43a63e39ee66ab2daf47/get_phys_addr_twostage_bti_gp_bit_lost_master.patch) diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1955 b/results/classifier/deepseek-r1:14b/output/assembly/1955 new file mode 100644 index 000000000..046b55659 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1955 @@ -0,0 +1,27 @@ + +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/deepseek-r1:14b/output/assembly/1965 b/results/classifier/deepseek-r1:14b/output/assembly/1965 new file mode 100644 index 000000000..716572f29 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1965 @@ -0,0 +1,2 @@ + +riscv64 semihosting not working diff --git a/results/classifier/deepseek-r1:14b/output/assembly/1985 b/results/classifier/deepseek-r1:14b/output/assembly/1985 new file mode 100644 index 000000000..80c2024d8 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/1985 @@ -0,0 +1,2 @@ + +Possible infinite loop in target/arm/sme_helper.c: helper_sme_fmopa_h diff --git a/results/classifier/deepseek-r1:14b/output/assembly/2064 b/results/classifier/deepseek-r1:14b/output/assembly/2064 new file mode 100644 index 000000000..a277056fe --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/2064 @@ -0,0 +1,13 @@ + +QEMU v8.2.0-rc4 and above will not take SMI +Description of problem: +Starting from v8.2.0-rc4, the x86 QEMU system will take SMI from an incorrect starting address. Without any firmware relocation, sending an SMI will move the RIP to 0x8000, instead of the traditional 0x38000. This caused the existing UEFI drivers not functional during SMI relocation step. + +After some investigation, the issue was caused by this commit: https://github.com/qemu/qemu/commit/b5e0d5d22fbffc3d8f7d3e86d7a2d05a1a974e27. There seems to be 2 issues with this change: + +1. This code section https://github.com/qemu/qemu/blob/7425b6277f12e82952cede1f531bfc689bf77fb1/target/i386/tcg/translate.c#L568C1-L572C6 was updated from calculating `cpu_eip` based on `s->pc` to `s->base.pc_next`. This will cause undetermined behavior. +2. This code section https://github.com/qemu/qemu/blob/7425b6277f12e82952cede1f531bfc689bf77fb1/target/i386/tcg/translate.c#L2848C1-L2869C67 added the routine of updating `new_pc`, which is later used `tcg_gen_addi_tl`. This will cause the `new_pc` to be populated with undesirable value and thus cause faulting behaviors. +Steps to reproduce: +1. Launch once booting UEFI firmware, and the system will get stuck at the SMM base relocation logic. +Additional information: +I verified that after fixing the 2 issues mentioned above, the SMI can be correctly invoked at desired location. diff --git a/results/classifier/deepseek-r1:14b/output/assembly/2072 b/results/classifier/deepseek-r1:14b/output/assembly/2072 new file mode 100644 index 000000000..de779e869 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/2072 @@ -0,0 +1,2 @@ + +Regression in 8.2: Synchronous Exception when running a VM on AArch64 diff --git a/results/classifier/deepseek-r1:14b/output/assembly/2318 b/results/classifier/deepseek-r1:14b/output/assembly/2318 new file mode 100644 index 000000000..d451d250d --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/2318 @@ -0,0 +1,35 @@ + +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/deepseek-r1:14b/output/assembly/2319 b/results/classifier/deepseek-r1:14b/output/assembly/2319 new file mode 100644 index 000000000..a2700a1ce --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/2319 @@ -0,0 +1,18 @@ + +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/deepseek-r1:14b/output/assembly/235 b/results/classifier/deepseek-r1:14b/output/assembly/235 new file mode 100644 index 000000000..a7e391b98 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/235 @@ -0,0 +1,2 @@ + +atomic failure linking with --enable-sanitizers on 32-bit Linux hosts diff --git a/results/classifier/deepseek-r1:14b/output/assembly/2422 b/results/classifier/deepseek-r1:14b/output/assembly/2422 new file mode 100644 index 000000000..b8141c734 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/2422 @@ -0,0 +1,70 @@ + +`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/deepseek-r1:14b/output/assembly/2498 b/results/classifier/deepseek-r1:14b/output/assembly/2498 new file mode 100644 index 000000000..e8f38e046 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/2498 @@ -0,0 +1,52 @@ + +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/deepseek-r1:14b/output/assembly/265 b/results/classifier/deepseek-r1:14b/output/assembly/265 new file mode 100644 index 000000000..46147fd82 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/265 @@ -0,0 +1,2 @@ + +x86: retf or iret pagefault sets wrong error code diff --git a/results/classifier/deepseek-r1:14b/output/assembly/2662 b/results/classifier/deepseek-r1:14b/output/assembly/2662 new file mode 100644 index 000000000..c925cdaa5 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/2662 @@ -0,0 +1,12 @@ + +powerpc: MSR_ILE bit must not be restored in rfi +Description of problem: +On processors that implement the MSR_ILE bit (that is, G4 and prior), the MSR_ILE bit is not restored by the `rfi` instruction. + +qemu, however, does restore this bit from `srr1`. + +Some ppcel operating systems rely on MSR_ILE not being restored by `rfi`, for example, Windows NT when taking a syscall. +Additional information: +Patch provided: [rfi_msr_ile.patch](/uploads/aa661fc8bcbb47585ff63f8e4ebb38ba/rfi_msr_ile.patch) + +The correct behaviour for G4 and prior is performed for later processors too. Given PPC970 and later have that bit documented as reserved, this should not be a problem. diff --git a/results/classifier/deepseek-r1:14b/output/assembly/267 b/results/classifier/deepseek-r1:14b/output/assembly/267 new file mode 100644 index 000000000..b1fa4a5d4 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/267 @@ -0,0 +1,2 @@ + +qemu-x86_64 segment prefixes error diff --git a/results/classifier/deepseek-r1:14b/output/assembly/2802 b/results/classifier/deepseek-r1:14b/output/assembly/2802 new file mode 100644 index 000000000..d6f7e3981 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/2802 @@ -0,0 +1,27 @@ + +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/deepseek-r1:14b/output/assembly/2871 b/results/classifier/deepseek-r1:14b/output/assembly/2871 new file mode 100644 index 000000000..3ab2800a0 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/2871 @@ -0,0 +1,2 @@ + +loongarch64: unknown register name 'f0' in asm diff --git a/results/classifier/deepseek-r1:14b/output/assembly/2891 b/results/classifier/deepseek-r1:14b/output/assembly/2891 new file mode 100644 index 000000000..ed1e07011 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/2891 @@ -0,0 +1,2 @@ + +qemu-system-x86_64 segfaults when executing ipxe selftests diff --git a/results/classifier/deepseek-r1:14b/output/assembly/2899 b/results/classifier/deepseek-r1:14b/output/assembly/2899 new file mode 100644 index 000000000..24733665d --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/2899 @@ -0,0 +1,37 @@ + +Regression 10.0.0rc1: Segmentation fault on executing QEMU advent calendar 2014, day 4 +Description of problem: +On executing QEMU, a segmentation fault occurs +Steps to reproduce: +1. Download https://www.qemu-advent-calendar.org/2014/download/stxmas.tar.xz +2. Execute with QEMU command line +Additional information: +git bisect finishes with: + +``` +456709db50f424d112bc5f07260fdc51555f3a24 is the first bad commit +commit 456709db50f424d112bc5f07260fdc51555f3a24 +Author: Paolo Bonzini <pbonzini@redhat.com> +Date: Sun Dec 15 10:06:10 2024 +0100 + + target/i386: execute multiple REP/REPZ iterations without leaving TB + + Use a TCG loop so that it is not necessary to go through the setup steps + of REP and through the I/O check on every iteration. Interestingly, this + is not a particularly effective optimization on its own, though it avoids + the cost of correct RF emulation that was added in the previous patch. + The main benefit lies in allowing the hoisting of loop invariants outside + the loop, which will happen separately. + + The loop exits when the low 16 bits of CX/ECX/RCX are zero (so generally + speaking the string operation runs in 65536 iteration batches) to give + the main loop an opportunity to pick up interrupts. + + Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> + Reviewed-by: Richard Henderson <richard.henderson@linaro.org> + Link: https://lore.kernel.org/r/20241215090613.89588-12-pbonzini@redhat.com + Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> + + target/i386/tcg/translate.c | 55 ++++++++++++++++++++++++++++++++++++++++----- + 1 file changed, 49 insertions(+), 6 deletions(-) +``` diff --git a/results/classifier/deepseek-r1:14b/output/assembly/2916 b/results/classifier/deepseek-r1:14b/output/assembly/2916 new file mode 100644 index 000000000..32ee3ffa4 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/2916 @@ -0,0 +1,27 @@ + +qemu-system-arm hangs when attempting to enable MMU on Cortex-A7 +Description of problem: +QEMU 9.x.x+ hangs when attempting to do enable the MMU from SCTLRL - M bit: https://developer.arm.com/documentation/ddi0601/2025-03/AArch32-Registers/SCTLR--System-Control-Register + +The instruction that hangs is the writing of the SCTLR register: + +``` +mrc p15, 0, r0, c1, c0, 0 +orr r0, r0, 1 +mcr p15, 0, r0, c1, c0, 0 +``` + +I am attempting to enable unaligned accesses and SCTLR-A bit doesn't seem to have any effect if the SCTLR-M is not enabled. Doing an unaligned access on cortex-a7 should be supported but it always trigger a Fault. +Steps to reproduce: +1. add the mrc/orr/mcr instruction sequence in the ResetHandler +2. link the elf +3. attempt to execute it +Additional information: +The unaligned access looked like it was working in QEMU 8.x.x but it might not have been emulated(?). I also am facing the same issues with MCR hanging and unaligned access not supported with latest 10.0.0-RC2. + +When it hangs, QEMU has to be killed and terminal reset. + +There might be two separate issues here: + +1. writing SCTLR register +2. emulated cortex-a7 not supporting unaligned access (hardware supports it) diff --git a/results/classifier/deepseek-r1:14b/output/assembly/364 b/results/classifier/deepseek-r1:14b/output/assembly/364 new file mode 100644 index 000000000..ef2b733f6 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/364 @@ -0,0 +1,2 @@ + +qemu-aarch64: incorrect signed comparison in ldsmax instructions diff --git a/results/classifier/deepseek-r1:14b/output/assembly/373 b/results/classifier/deepseek-r1:14b/output/assembly/373 new file mode 100644 index 000000000..834726639 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/373 @@ -0,0 +1,2 @@ + +Indentation should be done with spaces, not with TABs, in the ARM subsystem diff --git a/results/classifier/deepseek-r1:14b/output/assembly/381 b/results/classifier/deepseek-r1:14b/output/assembly/381 new file mode 100644 index 000000000..0a99876bb --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/381 @@ -0,0 +1,2 @@ + +ERROR:target/arm/translate-a64.c:13229:disas_simd_two_reg_misc_fp16: code should not be reached diff --git a/results/classifier/deepseek-r1:14b/output/assembly/457 b/results/classifier/deepseek-r1:14b/output/assembly/457 new file mode 100644 index 000000000..278c20591 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/457 @@ -0,0 +1,2 @@ + +qemu-system-s390x segfaults in do_tb_phys_invalidate at ../accel/tcg/translate-all.c:1482 diff --git a/results/classifier/deepseek-r1:14b/output/assembly/67 b/results/classifier/deepseek-r1:14b/output/assembly/67 new file mode 100644 index 000000000..07240fbdd --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/67 @@ -0,0 +1,2 @@ + +incomplete emulation of fstenv under TCG diff --git a/results/classifier/deepseek-r1:14b/output/assembly/737 b/results/classifier/deepseek-r1:14b/output/assembly/737 new file mode 100644 index 000000000..6e3089a01 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/737 @@ -0,0 +1,4 @@ + +s390x/tcg: Implement Miscellaneous-Instruction-Extensions Facility 3 for the s390x +Additional information: +http://publibfp.dhe.ibm.com/epubs/pdf/a227832c.pdf diff --git a/results/classifier/deepseek-r1:14b/output/assembly/739785 b/results/classifier/deepseek-r1:14b/output/assembly/739785 new file mode 100644 index 000000000..e1999c8a2 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/739785 @@ -0,0 +1,35 @@ + +qemu-i386 user mode can't fork (bash: fork: Invalid argument) + +Good time of day everybody, + +I have been trying to make usermode qemu on ARM with plugapps (archlinux) with archlinux i386 chroot to work. + +1. I installed arch linux in a virtuabox and created a chroot for it with mkarchroot. Transferred it to my pogo plug into /i386/ +2. I comiled qemu-i386 static and put it into /i386/usr/bin/ +./configure --static --disable-blobs --disable-system --target-list=i386-linux-user +make + +3. I also compiled linux kernel 2.6.38 with CONFIG_BINFMT_MISC=y and installed it. +uname -a +Linux Plugbox 2.6.38 #4 PREEMPT Fri Mar 18 22:19:10 CDT 2011 armv5tel Feroceon 88FR131 rev 1 (v5l) Marvell SheevaPlug Reference Board GNU/Linux + +4. Added the following options into /etc/rc.local +/sbin/modprobe binfmt_misc +/bin/mount binfmt_misc -t binfmt_misc /proc/sys/fs/binfmt_misc +echo ':qemu-i386:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00:\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfb\xff\xff\xff:/usr/bin/qemu-i386:' >/proc/sys/fs/binfmt_misc/register + +5. Also copied ld-linux.so.3 (actually ld-2.13.so because ld-linux.so.3 is a link to that file) from /lib/ to /i386/lib/ + +6.Now i chroot into /i386 and I get this: +[root@Plugbox i386]# chroot . +[II aI hnve ao n@P /]# pacman -Suy +bash: fork: Invalid argument + +7.I also downloaded linux-user-test-0.3 from qemu website and ran the test: +[root@Plugbox linux-user-test-0.3]# make +./qemu-linux-user.sh +[qemu-i386] +../qemu-0.14.0/i386-linux-user/qemu-i386 -L ./gnemul/qemu-i386 i386/ls -l dummyfile +BUG IN DYNAMIC LINKER ld.so: dl-version.c: 210: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed! +make: *** [test] Error 127 \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/assembly/881637 b/results/classifier/deepseek-r1:14b/output/assembly/881637 new file mode 100644 index 000000000..c85651bee --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/881637 @@ -0,0 +1,15 @@ + +QEMU fails to build on OpenBSD/hppa + +Trying to build previous QEMU releases as well as git code fails on OpenBSD/hppa... + +cc -I/home/hack/jasper/qemu/slirp -I. -I/home/hack/jasper/qemu -I/home/hack/jasper/qemu/fpu -I/home/hack/jasper/qemu/tcg -I/home/hack/jasper/qemu/tcg/hppa -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -Wno-redundant-decls -I/usr/local/include -I/usr/X11R6/include -Wendif-labels -Wmissing-include-dirs -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wold-style-definition -I/usr/local/include/libpng -DHAS_AUDIO -DHAS_AUDIO_CHOICE -DTARGET_PHYS_ADDR_BITS=64 -I.. -I/home/hack/jasper/qemu/target-i386 -DNEED_CPU_H -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/libpng -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -MMD -MP -MT translate.o -MF ./translate.d -O2 -g -c -o translate.o /home/hack/jasper/qemu/target-i386/translate.c +/tmp//ccvNbj1U.s: Assembler messages: +/tmp//ccvNbj1U.s:258792: Error: Field out of range [-262144..262143] (-262776). +/tmp//ccvNbj1U.s:261989: Error: Field out of range [-262144..262143] (-267096). +/tmp//ccvNbj1U.s:262006: Error: Field out of range [-262144..262143] (-267136). +/tmp//ccvNbj1U.s:264184: Error: Field out of range [-262144..262143] (-270612). +/tmp//ccvNbj1U.s:271893: Error: Field out of range [-262144..262143] (-281260). +/tmp//ccvNbj1U.s:276623: Error: Field out of range [-262144..262143] (-288784). +/tmp//ccvNbj1U.s:276906: Error: Field out of range [-262144..262143] (-289636). +/tmp//ccvNbj1U.s:277122: Error: Field out of range [-262144..262143] (-290280). \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/assembly/942659 b/results/classifier/deepseek-r1:14b/output/assembly/942659 new file mode 100644 index 000000000..d299cdeea --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/assembly/942659 @@ -0,0 +1,32 @@ + +ARM: CORTEX M, PRIMASK does not disable interrupts + +qemu version 0.15.1 +but the same code is in qemu 1.0 + +"CPSID I" does not disable interrupts for CORTEX M3 + + +if (interrupt_request & CPU_INTERRUPT_HARD + && ((IS_M(env) && env->regs[15] < 0xfffffff0) + || !(env->uncached_cpsr & CPSR_I))) { + env->exception_index = EXCP_IRQ; + do_interrupt(env); + next_tb = 0; + } + + +do_interrupt() will be executed even if (env->uncached_cpsr & CPSR_I) == 1 , disable interrupt bit set. + + +then changed to: + +if (interrupt_request & CPU_INTERRUPT_HARD + && !(env->uncached_cpsr & CPSR_I) + && (IS_M(env) ? env->regs[15] < 0xfffffff0: 1) ) { + env->exception_index = EXCP_IRQ; + do_interrupt(env); + next_tb = 0; + } + +works \ No newline at end of file |