diff options
Diffstat (limited to 'results/classifier/deepseek-r1:14b/output/debug')
98 files changed, 1770 insertions, 0 deletions
diff --git a/results/classifier/deepseek-r1:14b/output/debug/100 b/results/classifier/deepseek-r1:14b/output/debug/100 new file mode 100644 index 000000000..7899fddcf --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/100 @@ -0,0 +1,2 @@ + +GDB context is inconsistent after "monitor system_reset" diff --git a/results/classifier/deepseek-r1:14b/output/debug/1030666 b/results/classifier/deepseek-r1:14b/output/debug/1030666 new file mode 100644 index 000000000..8eaf6bf14 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1030666 @@ -0,0 +1,31 @@ + +gdb can't proceed after a breakpoint + +Using qemu-1.0.1-windows.zip package from http://lassauge.free.fr/qemu/ +Host: Windows 7 Ultimate 64-bit +Guest: i386 system running MS-DOS 6.22 +Launch command line: + qemu-system-i386.exe -L Bios -fda "DOS.vfd" -fdb "Data.vfd" -gdb tcp:127.0.0.1:1234 +Debbugers tried: + gdb 7.3.50.20111026-cvs running on Cygwin 1.7.16 + gdb 7.4 on MinGW + +Short description: +I use gdb to attach to a running Qemu session, set a breakpoint and resume execution. When the breakpoint is hit, gdb gains control as expected. However, trying to single-step or continue at this point just causes the same breakpoint to be hit immediately again. Deleting the breakpoint allows single-stepping or continue to work. + +Steps to reproduce: +DOS.vfd is a floppy image containing an MS-DOS 6.22 startup disk. +Data.vfd is a floppy image containing a single program (hello.com). +The aim is to debug the execution of hello.com with gdb. +Launch Qemu. +Launch gdb, an attach to qemu: + "target remote localhost:1234" +I know the address at which hello.com will be loaded, so set a breakpoint there and resume execution: + "break *0xf730" + "continue" +In Qemu, start hello.com. The breakpoint is immediately hit, execution stops and gdb gains control. +Examining the program gives expected results (such as "info reg" or "disassemble"). +At this point, try to proceed either with single-stepping ("si" or "ni") or with "continue", and the same breakpoint is immediately hit again. Subsequent attempts to single-step or continue just keep hitting the same breakpoint. +The only way to proceed at this point is to delete the breakpoint, after which both single-stepping and continue work. + +Note that single-stepping and continue works as expected if it is done after interrupting execution with Ctrl-C. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/105 b/results/classifier/deepseek-r1:14b/output/debug/105 new file mode 100644 index 000000000..050bd18fe --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/105 @@ -0,0 +1,2 @@ + +Gdb hangs when trying to single-step after an invalid instruction diff --git a/results/classifier/deepseek-r1:14b/output/debug/1050694 b/results/classifier/deepseek-r1:14b/output/debug/1050694 new file mode 100644 index 000000000..ef46d088e --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1050694 @@ -0,0 +1,76 @@ + +Interrupt 0xffffffff when debug is turned on + +Hi, + +I have been getting a GPF when I enable interrupts, working on implementing processes and a scheduler. When I comment out the scheduler code, I still get the GPF. I used the following QEMU command line to capture a log: + +qemu-system-i386 -smp 4 -monitor stdio -cpu core2duo -D /home/adam/century/util/qemu.log -d int,in_asm -s -hda "$harddisk_image" -m 3.5G + +Rather than posting the entire log, I need some help interpreting the following section (notice "INT=0xffffffff" on the top line): +Servicing hardware INT=0xffffffff +1: v=ffffffff e=0000 i=0 cpl=0 IP=0008:0010b63f pc=0010b63f SP=0010:0012b768 EAX=00000000 +EAX=00000000 EBX=00002000 ECX=00000018 EDX=05a00780 +ESI=00112faa EDI=000b8fa0 EBP=0012b780 ESP=0012b768 +EIP=0010b63f EFL=00207202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-] +SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +LDT=0000 00000000 00000000 00008200 DPL=0 LDT +TR =0008 00000580 00000067 00008900 DPL=0 TSS32-avl +GDT= 00127760 00000027 +IDT= 00122f40 000007ff +CR0=80000011 CR2=00000000 CR3=0014a000 CR4=00000000 +DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 +DR6=ffff0ff0 DR7=00000400 +CCS=00000024 CCD=0012b75c CCO=ADDL +EFER=0000000000000000 +check_exception old: 0xffffffff new 0xd +2: v=0d e=fffffffa i=0 cpl=0 IP=0008:0010b63f pc=0010b63f SP=0010:0012b768 EAX=00000000 +EAX=00000000 EBX=00002000 ECX=00000018 EDX=05a00780 +ESI=00112faa EDI=000b8fa0 EBP=0012b780 ESP=0012b768 +EIP=0010b63f EFL=00207202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 +ES =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +CS =0008 00000000 ffffffff 00cf9a00 DPL=0 CS32 [-R-] +SS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +DS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +FS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +GS =0010 00000000 ffffffff 00cf9300 DPL=0 DS [-WA] +LDT=0000 00000000 00000000 00008200 DPL=0 LDT +TR =0008 00000580 00000067 00008900 DPL=0 TSS32-avl +GDT= 00127760 00000027 +IDT= 00122f40 000007ff +CR0=80000011 CR2=00000000 CR3=0014a000 CR4=00000000 +DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 +DR6=ffff0ff0 DR7=00000400 +CCS=00000024 CCD=0012b75c CCO=ADDL +EFER=0000000000000000 + +To the best of my ability to interpret, I an getting an undefined interrupt, which is then triggering a GPF, which is caught. However, do not know where it might be coming from. + +Some additional information: + + +This command works: + +qemu-system-i386 -smp 4 -monitor stdio -cpu core2duo -s -hda "$harddisk_image" -m 3.5G + + +This command works: + +qemu-system-i386 -monitor stdio -cpu core2duo -D /home/adam/century/util/qemu.log -d int,in_asm -s -hda "$harddisk_image" -m 3.5G + + +And, as above, this does not: + +qemu-system-i386 -smp 4 -monitor stdio -cpu core2duo -D /home/adam/century/util/qemu.log -d int,in_asm -s -hda "$harddisk_image" -m 3.5G + + +[adam@os-development ~]$ qemu-system-i386 -version +QEMU emulator version 1.2.0, Copyright (c) 2003-2008 Fabrice Bellard + + +Attached is an image as a test case. Please let me know if you need any additional information. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/1105 b/results/classifier/deepseek-r1:14b/output/debug/1105 new file mode 100644 index 000000000..6f1027463 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1105 @@ -0,0 +1,4 @@ + +QEMU gdbstub should support PAC for aarch64 +Additional information: +The fix should probably be in gdbstub.c diff --git a/results/classifier/deepseek-r1:14b/output/debug/114 b/results/classifier/deepseek-r1:14b/output/debug/114 new file mode 100644 index 000000000..9ccdbd1bb --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/114 @@ -0,0 +1,2 @@ + +the help message of the set_password subcommand of the qemu monitor isn't usable diff --git a/results/classifier/deepseek-r1:14b/output/debug/1145 b/results/classifier/deepseek-r1:14b/output/debug/1145 new file mode 100644 index 000000000..d8d5916fc --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1145 @@ -0,0 +1,28 @@ + +Support register name resolution in debugger part of monitor for `x` commands for ARM platforms +Additional information: +From the looks of `get_monitor_def()` function from `monitor/misc.c` it seems to be cross-target but somehow still doesn't work for some targets anyway. + +Then grepping for the actual target implementation, it seems only i386, PPC, SPARC, and M68K support it, but nor ARM, MIPS, RISC V, etc: +``` +[i] ℤ rg monitor_defs +target/sparc/monitor.c +59:const MonitorDef monitor_defs[] = { +162:const MonitorDef *target_monitor_defs(void) +164: return monitor_defs; + +target/ppc/monitor.c +86:const MonitorDef monitor_defs[] = { +102:const MonitorDef *target_monitor_defs(void) +104: return monitor_defs; + +target/i386/monitor.c +611:const MonitorDef monitor_defs[] = { +647:const MonitorDef *target_monitor_defs(void) +649: return monitor_defs; + +target/m68k/monitor.c +25:static const MonitorDef monitor_defs[] = { +59:const MonitorDef *target_monitor_defs(void) +61: return monitor_defs; +``` diff --git a/results/classifier/deepseek-r1:14b/output/debug/1184 b/results/classifier/deepseek-r1:14b/output/debug/1184 new file mode 100644 index 000000000..a65834372 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1184 @@ -0,0 +1,70 @@ + +Extra SIGTRAP when breakpoint + watchpoint occur on same instruction +Description of problem: +If a breakpoint and watchpoint occur on the same instruction in TCG, gdb receives a breakpoint notification, a watchpoint notification, and then a SIGTRAP not corresponding to any set breakpoint/watchpoint. +Steps to reproduce: +Start QEMU via: + +``` +./qemu-system-i386 -display none -accel tcg -kernel kernel.elf -s -S +``` + +Here's the gdb session: + +``` +(gdb) file kernel.elf +Reading symbols from kernel.elf...done. +(gdb) tar rem :1234 +Remote debugging using :1234 +0x0000fff0 in ?? () +(gdb) b _start +Breakpoint 1 at 0x10000c: file kernel.s, line 17. +(gdb) c +Continuing. + +Breakpoint 1, _start () at kernel.s:17 +17 mov eax, 3 +(gdb) b bp +Breakpoint 2 at 0x100011: file kernel.s, line 20. +(gdb) watch *(int*)&value +Hardware watchpoint 3: *(int*)&value +(gdb) c +Continuing. + +Breakpoint 2, bp () at kernel.s:20 +20 mov dword ptr value, eax +(gdb) c +Continuing. + +Hardware watchpoint 3: *(int*)&value + +Old value = 0 +New value = 3 +done () at kernel.s:23 +23 jmp done +(gdb) c +Continuing. + +Program received signal SIGTRAP, Trace/breakpoint trap. +done () at kernel.s:23 +23 jmp done +``` +Additional information: +This patch fixes it by disabling the extra debug interrupt if the CPU is already singlestepping, but I'm not certain it's the 'correct' fix? + +```patch +--- a/softmmu/physmem.c ++++ b/softmmu/physmem.c +@@ -894,7 +894,9 @@ void cpu_check_watchpoint(CPUState *cpu, vaddr addr, vaddr len, + * trigger after the current instruction. + */ + qemu_mutex_lock_iothread(); +- cpu_interrupt(cpu, CPU_INTERRUPT_DEBUG); ++ if ((cpu->singlestep_enabled & SSTEP_NOIRQ) == 0) { ++ cpu_interrupt(cpu, CPU_INTERRUPT_DEBUG); ++ } + qemu_mutex_unlock_iothread(); + return; + } + +``` diff --git a/results/classifier/deepseek-r1:14b/output/debug/1184616 b/results/classifier/deepseek-r1:14b/output/debug/1184616 new file mode 100644 index 000000000..becdbfe01 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1184616 @@ -0,0 +1,16 @@ + + undefined reference to `trace_qemu_anon_ram_alloc' + +The latest git version (commit 6a4e17711442849bf2cc731ccddef5a2a2d92d29) fails to compile: + +... + LINK qemu-ga +libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_alloc': +oslib-posix.c:(.text+0x154): undefined reference to `trace_qemu_anon_ram_alloc' +libqemuutil.a(oslib-posix.o): In function `qemu_anon_ram_free': +oslib-posix.c:(.text+0x1e7): undefined reference to `trace_qemu_anon_ram_free' +collect2: error: ld returned 1 exit status +make: *** [qemu-ga] Error 1 + +This is on Ubuntu 13.04, gcc 4.7.3, configure flags: +'./configure' '--enable-linux-aio' '--enable-kvm' '--enable-vhost-net' \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/1212 b/results/classifier/deepseek-r1:14b/output/debug/1212 new file mode 100644 index 000000000..3d5c6105d --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1212 @@ -0,0 +1,10 @@ + +A NULL pointer dereference issue in elf2dmp +Description of problem: +SIGSEGV in get_pml4e for it didn't handle NULL result properly. +Steps to reproduce: +1.launch qemu and running "gab attach -p $QEMU_PID", run "gcore" inside gdb to generate coredump +2../elf2dmp ./core.111 ./out.dmp +3.get segemantation fault +Additional information: + diff --git a/results/classifier/deepseek-r1:14b/output/debug/1216845 b/results/classifier/deepseek-r1:14b/output/debug/1216845 new file mode 100644 index 000000000..fbca2656b --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1216845 @@ -0,0 +1,46 @@ + +qemu-system-arm semihosting always calls exit(0) + +In my embedded ARM project I have a bunch of unit tests that I run in a POSIX synthetic environment, and, as usual for POSIX processes, these tests return 0 for success and !=0 for error. + +Now I expanded the testing environment to run some of these tests compiled for ARM, under QEMU, with the tracing messages forwarded via the semihosting API. + +Up to now everything is fine with the emulation. + +However I have a problem with passing the failure code back to the operating system, to drive the continuous integration framework. + +I checked the arm-semi.c code and for SYS_EXIT and I discovered that the parameter passed is ignored and it always calls exit(0): + + case SYS_EXIT: + gdb_exit(env, 0); + exit(0); + +To solve my problem I temporarily made a patch, and for cases that should return non zero codes, I call an unsupported BKPT instruction, which makes QEMU abort, and pass an non zero code (1) back to the operating system. + + qemu: Unsupported SemiHosting SWI 0xf1 + +This kludge is more or less functional, but is quite inconvenient. + +After checking the ARM manuals, I discovered that SYS_EXIT is not standard, and the 0x18 code used for it originally was used for angel_SWIreason_ReportException, which has a slightly different purpose. + +Now the question: + +Would it be possible to no longer ignore the code passed to 0x18, and if it is non zero, to call exit() with a different value? + +The suggested rule would be: + +if (code ==0 || code == 0x20026) + exit(0); +elif (code < 256) + exit(code); +else + exit(1); + +The value 0x20026 means ADP_Stopped_ApplicationExit, and, if I understood it right, it means that the program terminated successfully. If this is not true, it can be removed from the first conditional statement. + +What do you think? Can this be added to arm-semi.c? + + +Regards, + +Liviu \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/1231 b/results/classifier/deepseek-r1:14b/output/debug/1231 new file mode 100644 index 000000000..e152bc1ec --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1231 @@ -0,0 +1,14 @@ + +Loading migration of VM in debug state fails (with potential solution) +Description of problem: +``` +qemu-system-x86_64: invalid runstate transition: 'inmigrate' -> 'debug' +Aborted (core dumped) +``` +Steps to reproduce: +1. Start VM with gdbstub +2. Pause VM via gdbstub +3. Save migration snapshot via HMP: `migrate "exec: gzip -c > foo.gz"` +4. Start new QEMU instance from snapshot by adding these args to whatever you used to launch QEMU: `-incoming "exec: gzip -c -d foo.gz"` +Additional information: +This can be fixed by adding `{ RUN_STATE_INMIGRATE, RUN_STATE_DEBUG },` to `runstate_transitions_def` in `softmmu/runstate.c`. It's not clear if there are any negative ramifications of this, but it seems to work for me? diff --git a/results/classifier/deepseek-r1:14b/output/debug/1241 b/results/classifier/deepseek-r1:14b/output/debug/1241 new file mode 100644 index 000000000..519b5a10f --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1241 @@ -0,0 +1,14 @@ + +About showing the information of the csr +Description of problem: +cannot print the inforamtion after pulling the newest version of qemu +E.g info r csr +only fcsr frm fflags are shown. However , it should print out all the csrs such as mideleg mhartid etc in preivous version +info r mip +(GDB) Invalid register `mip' +Steps to reproduce: +1.running riscv64-unknown-elf-gdb kernel +2.target remote to the port i set in the xv6 makefile +3.type info r mip it shows the the probklem i mentioned above. I could use the print CSR in previous version of QEMU. +Additional information: + diff --git a/results/classifier/deepseek-r1:14b/output/debug/1260 b/results/classifier/deepseek-r1:14b/output/debug/1260 new file mode 100644 index 000000000..6e3f254bb --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1260 @@ -0,0 +1,2 @@ + +RISC-V sstatus register is missing in qemu console / gdb diff --git a/results/classifier/deepseek-r1:14b/output/debug/1265 b/results/classifier/deepseek-r1:14b/output/debug/1265 new file mode 100644 index 000000000..895a3afe7 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1265 @@ -0,0 +1,2 @@ + +avocado should log all the guest console output until QEMU exits, not disconnect early diff --git a/results/classifier/deepseek-r1:14b/output/debug/1273 b/results/classifier/deepseek-r1:14b/output/debug/1273 new file mode 100644 index 000000000..629fd0210 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1273 @@ -0,0 +1,2 @@ + +QEMU log problem diff --git a/results/classifier/deepseek-r1:14b/output/debug/1289 b/results/classifier/deepseek-r1:14b/output/debug/1289 new file mode 100644 index 000000000..81bf02321 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1289 @@ -0,0 +1,2 @@ + +plugin get registers diff --git a/results/classifier/deepseek-r1:14b/output/debug/1358 b/results/classifier/deepseek-r1:14b/output/debug/1358 new file mode 100644 index 000000000..e7a4e9ff8 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1358 @@ -0,0 +1,2 @@ + +Remove CPUState::trace_dstate diff --git a/results/classifier/deepseek-r1:14b/output/debug/1364501 b/results/classifier/deepseek-r1:14b/output/debug/1364501 new file mode 100644 index 000000000..2b015b24d --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1364501 @@ -0,0 +1,21 @@ + +Gdb hangs when trying to single-step after an invalid instruction + +When using Gdb to remote-debug a program and manually setting its PC to point to an address containing an invalid instruction, then doing a single step Qemu will never return control to the remote Gdb. + +For instance, let's say address 0x114 contains an invalid instruction. On the remote Gdb, we'd do: + +(gdb) set $pc = 0x114 +(gdb) stepi + +After doing that we won't get the (gdb) prompt unless we do a Ctrl-C. If we do so we'll be left at 0x114 instead of going towards the exception handler as we should. This happens with stepi, step and next. If instead of single-stepping we used continue, the program will proceed into the exception handler as it should. + +The reason this is happening is that when Qemu realizes it's about to translate an instruction it doesn't recognize it'll generate a call to helper_exception_with_syndrome(), which will register the exception and then call cpu_loop_exit(). At the same time, because we're doing a single-step, Qemu will also generate a call to helper_exception_internal() passing it an EXCP_DEBUG, which lets the system know it'll give control back to the remote debugger, and it also ends with a call to cpu_loop_exit(). However, because the syndrome exception calls cpu_loop_exit() first, the call to the internal exception won't be reached and Qemu will be stuck in a loop without returning control to the remote debugger. + +What makes this a bit tricky to fix is that we must call cpu_loop_exit() at the end of helper_exception_with_syndrome(), otherwise the target exception will go undetected and its handler won't be excecuted. + +Tested on latest head by emulating a Stellaris lm3s6965 board and running RTEMS 4.11: + +$ qemu-system-arm -nographic -s -S -M lm3s6965evb -kernel my_rtems_app + +Commit hash in qemu.git: 30eaca3acdf17d7bcbd1213eb149c02037edfb0b \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/1379 b/results/classifier/deepseek-r1:14b/output/debug/1379 new file mode 100644 index 000000000..77fde7a5f --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1379 @@ -0,0 +1,2 @@ + +dump memory read write operations diff --git a/results/classifier/deepseek-r1:14b/output/debug/1397 b/results/classifier/deepseek-r1:14b/output/debug/1397 new file mode 100644 index 000000000..f5325f13a --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1397 @@ -0,0 +1,2 @@ + +riscv: break, hbreak does not set a breakpoint on the correct address when providing symbols diff --git a/results/classifier/deepseek-r1:14b/output/debug/1421 b/results/classifier/deepseek-r1:14b/output/debug/1421 new file mode 100644 index 000000000..8a32a2e82 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1421 @@ -0,0 +1,20 @@ + +GDB memory reads fail on Cortex-M33 +Description of problem: +GDB fails to read memory from the guest. There appear to be at least two problems: + +1. In `arm_cpu_get_phys_page_attrs_debug`, `arm_is_secure(env)` returns false, because the implementation doesn't seem to know about Armv7-M or Armv8-M secure states. However, `arm_mmu_idx(env)` does know how to check `env->v7m.secure`, so it returns `ARMMMUIdx_MSPriv` (the S stands for secure). The mismatch between an apparently non-secure access to a secure MMU seems to cause the read to fail laster. +2. With the MPU enabled (not the case in this repro, but I can provide one), `cpu_memory_rw_debug` computes `page = addr & TARGET_PAGE_MASK`, and uses the page to compute permissions. However, TARGET_PAGE_MASK is based on 4K pages on this platform, but the MPU granularity is 32 bytes. So the wrong page is used for checking. +Steps to reproduce: +``` +# Sorry for the large clone. It's mostly unused files in CMSIS. +git clone --recursive -b qemu-repro-1 https://github.com/dreiss/mpu_experiments +cd mpu_experiments +git checkout origin/qemu-repro-1 +cmake -S . -B build -DBOARD=qemu-mps2-an505 -DAPP=mpu_stacktrace -DCMAKE_BUILD_TYPE=Debug +cmake --build build +/path/to/qemu-system-arm -machine mps2-an505 -nographic -kernel build/kernel.elf -s -S -d int +# Open a separate terminal and cd into mpu_experiments +gdb build/kernel.elf -ex 'target remote :1234' -ex 'break base_case' -ex continue -ex backtrace -ex quit +# Note the memory read failures in the backtrace. +``` diff --git a/results/classifier/deepseek-r1:14b/output/debug/1488 b/results/classifier/deepseek-r1:14b/output/debug/1488 new file mode 100644 index 000000000..888319984 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1488 @@ -0,0 +1,36 @@ + +Memory not accessible from GDB when using mps3-an547 +Description of problem: +Memory (including variables) is not accessible when connecting to the emulated machine via GDB +Steps to reproduce: +1. Create minimal program `main.c`: + ```c + int main(void) { + int myvar = 42; + for(;;) + } + ``` +2. Compile + ```bash + arm-none-eabi-gcc -c -o build/main.o -c -mcpu=cortex-m55 -mfloat-abi=hard -mthumb -funsigned-char -mlittle-endian -O0 -g -std=c11 main.c + ``` + (ARM startup files and include directories omitted for brevity) +3. Link + ```bash + arm-none-eabi-g++ -o build/test.elf build/main.o -mcpu=cortex-m55 -mfloat-abi=hard -mthumb -funsigned-char -mlittle-endian --entry=Reset_Handler -static -T./platform.ld -O0 -g + ``` + (ARM startup files omitted for brevity) +4. Run binary in QEMU: + ```bash + qemu-system-arm --machine mps3-an547 -serial mon:stdio -kernel test.elf -gdb tcp::1234 -S + ``` +5. Attach using GDB `arm-none-eabi-gdb build/test.elf` and set break point to infinite loop + ```gdb + target remote :1234 + break main.c:18 + continue + print myvar + ``` + +Expected Output: 42 +Actual Output: `Cannot access memory at address 0x11fffe4` diff --git a/results/classifier/deepseek-r1:14b/output/debug/1489 b/results/classifier/deepseek-r1:14b/output/debug/1489 new file mode 100644 index 000000000..15b5dc76d --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1489 @@ -0,0 +1,95 @@ + +Breakpoints set at wrong addresses in `test-gdbstub.py` for some Linux kernels guest images +Description of problem: +The script `tests/guest-debug/test-gdbstub.py` for testing QEMU's GDB +stub on Linux kernel guests sets breakpoints on `kernel_init()` and +`wait_for_completion()`. As the script is coded, breakpoints are set +(implicitly) not at the functions' start addresses, but at the end of +the functions' prologues. + +For some Linux kernel builds in which `kernel_init()` and +`wait_for_completion()` get compiled with a function prologue, the +script fails to detect breakpoint hits in `check_hbreak()` and +`check_break()` because it compares the stopped address (i.e. the end of +the function's prologue) with the function's start address, and they +differ. To observe the difference in GDB: + +```sh +$ gdb -q --nx vmlinux +Reading symbols from vmlinux... +(gdb) b kernel_init +Breakpoint 1 at 0xffff800008fbeb28: file init/main.c, line 1497. # <- prologue start +(gdb) b *kernel_init +Breakpoint 2 at 0xffff800008fbeb18: file init/main.c, line 1491. # <- function start +``` + +In my tests, the issue doesn't occur with standard Linux kernels builds +(e.g. compiled on Linux hosts with GCC) because typically both +`kernel_init()` and `wait_for_completion()` seem to be without +prologues. +Steps to reproduce: +The issue has so far been encountered only with arm64 Linux kernel +guests compiled on macOS arm64 with +[mac-linux-kdk](https://github.com/GayPizzaSpecifications/mac-linux-kdk). + +1. Compile a recent arm64 Linux kernel on macOS arm64 with debugging + information (first `make defconfig`, then `make menuconfig` and set + `Kernel hacking / Compile-time checks and compiler options / Debug + information / Rely on toolchain's implicit default DWARF version`) + + ```sh + $ file /tmp/linux-5.19/arch/arm64/boot/Image + /tmp/linux-5.19/arch/arm64/boot/Image: Linux kernel ARM64 boot executable Image, little-endian, 4K pages + $ file /tmp/linux-5.19/vmlinux + /tmp/linux-5.19/vmlinux: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), statically linked, BuildID[sha1]=bf9e422d48e0aded5859fe34d6de2c174ef3a20b, with debug_info, not stripped + ``` + +2. Start QEMU waiting for GDB to connect: + + ```sh + $ ./qemu-system-aarch64 -smp 1 -M virt -cpu cortex-a57 -kernel /tmp/linux-5.19/arch/arm64/boot/Image -append nokaslr -s -S + ``` + +3. Execute the `test-gdbstub.py` script (as described in the script file + itself): + + ```sh + $ gdb /tmp/linux-5.19/vmlinux -x tests/guest-debug/test-gdbstub.py + ``` + + The script then hangs. + +Tested both on a macOS host and a Linux host. +Additional information: +The proposed fix is to explicitly disable GDB's prologue decoder and set +the two breakpoints at the functions' start addresses [by adding an +asterisk before the function +name](https://stackoverflow.com/a/31451340): + +```diff +diff --git a/tests/guest-debug/test-gdbstub.py b/tests/guest-debug/test-gdbstub.py +index 98a5df4d4..6202d17c3 100644 +--- a/tests/guest-debug/test-gdbstub.py ++++ b/tests/guest-debug/test-gdbstub.py +@@ -31,7 +31,7 @@ def check_step(): + def check_break(sym_name): + "Setup breakpoint, continue and check we stopped." + sym, ok = gdb.lookup_symbol(sym_name) +- bp = gdb.Breakpoint(sym_name) ++ bp = gdb.Breakpoint("*%s" % (sym_name)) + + gdb.execute("c") + +@@ -48,7 +48,7 @@ def check_break(sym_name): + def check_hbreak(sym_name): + "Setup hardware breakpoint, continue and check we stopped." + sym, ok = gdb.lookup_symbol(sym_name) +- gdb.execute("hbreak %s" % (sym_name)) ++ gdb.execute("hbreak *%s" % (sym_name)) + gdb.execute("c") + + # hopefully we came back +``` + +This change shouldn't impact the Linux kernel guests for which the +script is already working as intended. diff --git a/results/classifier/deepseek-r1:14b/output/debug/1528239 b/results/classifier/deepseek-r1:14b/output/debug/1528239 new file mode 100644 index 000000000..5ddd76d86 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1528239 @@ -0,0 +1,46 @@ + +Unable to debug PIE binaries with QEMU gdb stub. + +The issue occurs on current trunk: + +max@max:~/build/qemu$ cat test.c +#include <stdio.h> + +int main() { + printf("Hello, world!\n"); + return 0; +} + +max@max:~/build/qemu$ gcc test.c -fPIC -pie -o bad.x +max@max:~/build/qemu$ ./x86_64-linux-user/qemu-x86_64 -g 1234 bad.x +............................. + + +max@max:~/build/qemu$ gdb +GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1 +........................................................................................ +(gdb) file bad.x +Reading symbols from bad.x...(no debugging symbols found)...done. +(gdb) b main +Breakpoint 1 at 0x779 +(gdb) target remote localhost:1234 +Remote debugging using localhost:1234 +Reading symbols from /lib64/ld-linux-x86-64.so.2...warning: the debug information found in "/lib64/ld-2.19.so" does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch). + +Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/ld-2.19.so...done. +done. +Loaded symbols for /lib64/ld-linux-x86-64.so.2 +Error in re-setting breakpoint 1: Cannot access memory at address 0x775 +Error in re-setting breakpoint 1: Cannot access memory at address 0x775 +0x0000004000a042d0 in _start () from /lib64/ld-linux-x86-64.so.2 +(gdb) c +Continuing. +[Inferior 1 (Remote target) exited normally] +(gdb) + + +max@max:~/build/qemu$ cat config.log +# Configured with: '/home/max/src/qemu/configure' '--prefix=/home/max/install/qemu' '--target-list=arm-linux-user,aarch64-linux-user,x86_64-linux-user' '--static' + + +W/O QEMU or -pie flag breakpoint on main works fine. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/1552 b/results/classifier/deepseek-r1:14b/output/debug/1552 new file mode 100644 index 000000000..9ece41d8f --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1552 @@ -0,0 +1,16 @@ + +newer version(>=5.2.0) of qemu-system-aarch64 cannot debug arm64 linux kernel +Description of problem: + +Steps to reproduce: +1. Run QEMU in on teminal. +2. Run gdb-multiarch in another terminal, for example: gdb-multiarch ./linux-5.10.4/vmlinux +3. In gdb-multiarch, enter three commands in sequence："target remote localhost:1234"、"b do_sys_open"、"continue" +4. GDB breakpoint cannot take effect +5. If using qemu-system-aarch64 5.0.0(manually compiled)，GDB breakpoint can take effect. +Additional information: +I tested this problem using different combinations： +Host Os：Ubuntu18/Ubuntu20/Ubuntu22 +ARM64 Linux Kernel: 5.4.50/5.10.4 +QEMU：qemu 2.11/qemu 4.2/qemu 5.0/qemu 5.2/qemu 6.2/qemu 7 +Finally, I found out that arm64 linux kernel cannot be debugged since qemu-system-aarch64 5.2.0. diff --git a/results/classifier/deepseek-r1:14b/output/debug/1603580 b/results/classifier/deepseek-r1:14b/output/debug/1603580 new file mode 100644 index 000000000..da7669346 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1603580 @@ -0,0 +1,35 @@ + +[gdbstub] qemu is killed when using remote debugger with qemu -S -s + +Hello, + +REPRODUCE + +$ qemu-system-x86_64 -s -S -nographic +<wait> +QEMU: Terminated via GDBStub + +$ gdb +(gdb) target remote :1234 +(gdb) load /bin/ls +(gdb) target exec +A program is being debugged already. Kill it? (y or no) y +No executable file now. + +EXPECTED + +Enable program to be executed without terminating QEMU. + +DISCUSSION + +This was already discussed in [1], reverted in [2], however, no solution is provided. + +It worked perfectly in the past, I guess because of [1] and before [3]. + +Opening bug for this as discussion in mailing list did not attract anyone and functionality is required. If there is other gdb sequence to achieve same result it would be great to get it documented. + +Thanks, + +[1] http://git.qemu.org/?p=qemu.git;a=commitdiff;h=00e94dbc7fd0110b0555d59592b004333adfb4b8 +[2] http://git.qemu.org/?p=qemu.git;a=commitdiff;h=ce0274f730eacbd24c706523ddbbabb6b95d0659 +[3] http://git.qemu.org/?p=qemu.git;a=commitdiff;h=7d03f82f81e0e6c106ca0d2445a0fc49dc9ddc7b \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/1647683 b/results/classifier/deepseek-r1:14b/output/debug/1647683 new file mode 100644 index 000000000..818951409 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1647683 @@ -0,0 +1,35 @@ + +Bad interaction between tb flushing & gdb stub + +I have been working on a series of patches for ARM big-endian system mode support, using QEMU as a bare-metal simulator for the GDB test suite. At some point I realised that these tests were not running reliably on the QEMU master branch, even without my patches applied. (I.e., in little-endian mode.) + +Running QEMU under GDB in the test harness via Valgrind, using something akin to: + +(gdb) target remote | valgrind --tool=memcheck qemu-arm-system [...] + +leads to intermittent (and quite hard-to-reproduce) segfaults in QEMU of the form: + +==52333== Process terminating with default action of signal 11 (SIGSEGV) +==52333== Access not within mapped region at address 0x24 +==52333== at 0x1D55F2: tb_page_remove (translate-all.c:1026) +==52333== by 0x1D58B4: tb_phys_invalidate (translate-all.c:1119) +==52333== by 0x1D63AA: tb_invalidate_phys_page_range (translate-all.c:1519) +==52333== by 0x1D66D7: tb_invalidate_phys_addr (translate-all.c:1714) +==52333== by 0x1CBA7F: breakpoint_invalidate (exec.c:704) +==52333== by 0x1CC01F: cpu_breakpoint_remove_by_ref (exec.c:869) +==52333== by 0x1CBF97: cpu_breakpoint_remove (exec.c:857) +==52333== by 0x218FAA: gdb_breakpoint_remove (gdbstub.c:717) +==52333== by 0x219E35: gdb_handle_packet (gdbstub.c:1035) +==52333== by 0x21AF62: gdb_read_byte (gdbstub.c:1459) +==52333== by 0x21B096: gdb_chr_receive (gdbstub.c:1672) +==52333== by 0x3AF2BC: qemu_chr_be_write_impl (qemu-char.c:419) + +These crashes didn't happen on a 2.6-era QEMU, so I bisected and discovered the commit 3359baad36889b83df40b637ed993a4b816c4906 ("tcg: Make tb_flush() thread safe") appears to be the thing that triggers this intermittent failure. Reverting the patch on the branch tip makes the crashes go away. + +Unfortunately I don't currently have a way to trigger the segfaults outside of Mentor Graphics's test infrastructure, which I can't share. + +Does anyone know a reason that this might be happening, or suggestions of how I might further debug this? Maybe a missed tb flush in the gdb stub code, somewhere? + +Thanks! + +Julian \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/1672383 b/results/classifier/deepseek-r1:14b/output/debug/1672383 new file mode 100644 index 000000000..0a281d808 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1672383 @@ -0,0 +1,21 @@ + +Slow Windows XP load after commit a9353fe897ca2687e5b3385ed39e3db3927a90e0 + +I've recently discovered, that in QEMU 2.8+ my Windows XP loading time has significantly worsened. In 2.7 it took 30-40 second to boot, but in 2.8 it became 2-2,5 minutes. + +I've used Git bisect, and found out that the change happened after commit a9353fe897ca2687e5b3385ed39e3db3927a90e0, which, as far as I can tell from the commit message, handled race condition when invalidating breakpoint. + +I've set a breakpoint in static void breakpoint_invalidate(CPUState *cpu, target_ulong pc), and here's a backtrace: +#0 cpu_breakpoint_insert (cpu=cpu@entry=0x555556a73be0, pc=144, + flags=flags@entry=32, breakpoint=breakpoint@entry=0x555556a7c670) + at /media/sdd2/qemu-work/exec.c:830 +#1 0x00005555558746ac in hw_breakpoint_insert (env=env@entry=0x555556a7be60, + index=index@entry=0) at /media/sdd2/qemu-work/target-i386/bpt_helper.c:64 +#2 0x00005555558748ed in cpu_x86_update_dr7 (env=0x555556a7be60, + new_dr7=<optimised out>) + at /media/sdd2/qemu-work/target-i386/bpt_helper.c:160 +#3 0x00007fffa17421f6 in code_gen_buffer () +#4 0x000055555577fcb4 in cpu_tb_exec (itb=<optimised out>, + itb=<optimised out>, cpu=0x7fff8b7763b0) + at /media/sdd2/qemu-work/cpu-exec.c:164 +It seems that XP sets some breakpoints during it's load, and it leads to frequent TB flushes and slow execution. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/171 b/results/classifier/deepseek-r1:14b/output/debug/171 new file mode 100644 index 000000000..dd7fecee5 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/171 @@ -0,0 +1,2 @@ + +[RFE] option to suppress gemu_log() output diff --git a/results/classifier/deepseek-r1:14b/output/debug/1725 b/results/classifier/deepseek-r1:14b/output/debug/1725 new file mode 100644 index 000000000..8679a786e --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1725 @@ -0,0 +1,22 @@ + +qemu-system-x86_64 reports wrong thread to GDB on SIGINT +Description of problem: +Upon interruption of a thread by GDB, QEMU in some circumstances will send a stop reply with the ID of a thread that had not been resumed. + +This happens for the following reasons: +1. GDB uses `vCont` exclusively to resume and step through threads. +2. When a thread is interrupted by GDB, QEMU runs `vm_stop(RUN_STATE_PAUSED)`, which triggers `gdb_vm_state_change`, which, in turn, uses whatever CPU is pointed to by `gdbserver_state.c_cpu` at that time to construct the stop reply. +3. The `vCont` handler in QEMU doesn't set `gdbserver_state.c_cpu` before resuming any CPUs. + +Important to note is that stepping is not affected by this issue because the `EXCP_DEBUG` handler sets `gdbserver_state.c_cpu` to the CPU the exception happened in before `gdb_vm_state_change` runs. Which also means single stepping before continuing is an effective way to work around this bug. +Steps to reproduce: +1. Run QEMU with at least two threads and the GDB stub enabled. +2. Run `gdb --nx --ex 'target remote :1234' --ex 'set scheduler-locking on'` +3. Switch to Thread 1.2 in GDB with `thr 2` +4. Resume Thread 1.2 in GDB with `c` +5. Press Ctrl+C to interrupt the VM +6. Notice that the event is reported as having happened in Thread 1.1, which has not been resumed. +Additional information: +Note that, while this bug happens no matter the state of `scheduler-locking`, it only becomes a problem when it is enabled. This is because, when it is disabled, GDB will always resume all threads on `continue`, so it doesn't matter what thread ID QEMU says the interrupt happened in, as it is guaranteed to have been resumed anyway. That, however, is not the case when `scheduler-locking` is enabled. + +Regardless, I don't think it makes sense for QEMU to be reporting events happening in threads that weren't resumed through either `s/S/c/C` or `vCont`, which is what it's doing here. diff --git a/results/classifier/deepseek-r1:14b/output/debug/1738202 b/results/classifier/deepseek-r1:14b/output/debug/1738202 new file mode 100644 index 000000000..14f7d7f17 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1738202 @@ -0,0 +1,32 @@ + +qemu 2.11 segfaults on elf file that worked with qemu2.7 + +running on cygwin in Windows 7 + +QEMU 2.10.93 segfaults: +$ /opt/qemu2.11/qemu-system-arm -M integratorcp -cpu cortex-m4 -semihosting -nographic -monitor null -serial null -no-reboot -kernel MFWso_Cycle_f1uP2_CUNIT_0.elf +Segmentation fault + +where QEMU 2.7.0 worked: +$ /opt/qemu2.7/qemu-system-arm -M integratorcp -cpu cortex-m4 -semihosting -nographic -monitor null -serial null -no-reboot -kernel MFWso_Cycle_f1uP2_CUNIT_0.elf +------------ CUnit_MFWso_Cycle_f1 ------------ + + + CUnit - A Unit testing framework for C - Version 2.1-0 + http://cunit.sourceforge.net/ + + +Suite: Suite_MFWso_Cycle_f1 + Test: MFWso_Cycle_f1() ... passed + Test: MFWso_GetPhysicalStateData() ... passed + Test: MFWso_GetOutputData() ... passed + Test: MFWso_GetSafeChannelOK() ... passed + +--Run Summary: Type Total Ran Passed Failed + suites 1 1 n/a 0 + tests 4 4 4 0 + asserts 54 54 54 0 + +---------------------------------------- + +Omitting the -cpu parameter results (for both versions) to hang of qemu (no output, no end, full cpu load). \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/1749 b/results/classifier/deepseek-r1:14b/output/debug/1749 new file mode 100644 index 000000000..70904da02 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1749 @@ -0,0 +1,21 @@ + +[Riscv-fu540] UEFI cannot be started with gdb on sifive fu540 platform？ +Description of problem: +Using qemu start UEFI on sifive fu540 platform with option： -S -s. +``` +qemu-system-riscv64 \ + -cpu sifive-u54 -machine sifive_u \ + -bios U540.fd \ + -m 2048 -nographic -smp cpus=2,maxcpus=2 \ + -S -s +``` +UEFI url is： https://github.com/tianocore/edk2.git +Steps to reproduce: +1. start qemu with -S -s param in one terminal +2. riscv64-unknown-linux-gnu-gdb in other terminal +3. in gdb terminal: +``` + target remove :1234 + c +``` +4. in qemu terminal, there has no any output ? diff --git a/results/classifier/deepseek-r1:14b/output/debug/1766 b/results/classifier/deepseek-r1:14b/output/debug/1766 new file mode 100644 index 000000000..369058673 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1766 @@ -0,0 +1,4 @@ + +-strace should print target program counter when SIGSEGV +Additional information: + diff --git a/results/classifier/deepseek-r1:14b/output/debug/1773743 b/results/classifier/deepseek-r1:14b/output/debug/1773743 new file mode 100644 index 000000000..a09b6f459 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1773743 @@ -0,0 +1,22 @@ + +qemu-user -g xxx -E LD_PROFILE=xxx segfault + +Here is two simple steps to reproduce the bug: + +$ qemu-x86_64 -E LD_PROFILE=libc.so.6 -E LD_PROFILE_OUTPUT=. -g 12345 -L / /bin/ls + +(libc.so and /bin/ls might change on your system, in this case we just need a binary with a profilable needed library) + +In a other window launch: + +$ gdb +(gdb) target remote :12345 +(gdb) c + +At this point qemu will segfault. + +It seems this problem is appends when sigprof passed to gdb. +One way I have found to bypass this: +patch gdbstub.c gdb_handlesig and ignore sig if +sig == TARGET_SIGPROF +(which means now I can't catch sigprof on gdb anymore) \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/1780814 b/results/classifier/deepseek-r1:14b/output/debug/1780814 new file mode 100644 index 000000000..dbc46bbb2 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1780814 @@ -0,0 +1,34 @@ + +lib/raid6/neon4.c:118:1: internal compiler error + +I am facing below issue when i am trying to cross compile kernel for raspberry pi 3. +please give solution . + + +Below is log + + + +CHK include/config/kernel.release + CHK include/generated/uapi/linux/version.h + CHK include/generated/utsrelease.h + CHK include/generated/bounds.h + CHK include/generated/timeconst.h + CHK include/generated/asm-offsets.h + CALL scripts/checksyscalls.sh + CHK scripts/mod/devicetable-offsets.h + CHK include/generated/compile.h + CHK kernel/config_data.h + CC [M] lib/raid6/neon4.o +lib/raid6/neon4.c: In function ‘raid6_neon4_gen_syndrome_real’: +lib/raid6/neon4.c:118:1: internal compiler error: in dwarf2out_frame_debug_adjust_cfa, at dwarf2cfi.c:1078 + } + ^ +Please submit a full bug report, +with preprocessed source if appropriate. +See <https://bugs.launchpad.net/gcc-linaro> for instructions. +scripts/Makefile.build:328: recipe for target 'lib/raid6/neon4.o' failed +make[2]: *** [lib/raid6/neon4.o] Error 1 +scripts/Makefile.build:587: recipe for target 'lib/raid6' failed +make[1]: *** [lib/raid6] Error 2 +Makefile:1034: recipe for target 'lib' failed \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/1792659 b/results/classifier/deepseek-r1:14b/output/debug/1792659 new file mode 100644 index 000000000..9fbcf84c1 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1792659 @@ -0,0 +1,35 @@ + +watchpoints might not properly stop execution at the right address + +This bug has been tested with the latest development tree (19b599f7664b2ebfd0f405fb79c14dd241557452). + +I am using qemu-system-i386 with the gdbserver stub. I set a watchpoint on some address. When the watchpoint is hit, it will be reported by gdb, but it might happen that eip points to the wrong address (execution has not properly stopped when the watchpoint was hit). + +The setup I used to reproduce it is quite complex, but I believe I have found the cause of the bug, so I will describe that. + +The check_watchpoint() function sets cflags_next_tb in order to force the execution of only one instruction, and then exits the current tb. It then expects to be called again after that one instruction is executed, the watchpoint is hit and it is reported to gdb. + +The problem is that another interrupt might have been generated around the same time as the watchpoint. If the interrupt changes eip and execution goes on in another address, the value of cflags_next_tb will be spoiled. When we come back from the interrupt to the address where the watchpoint is hit, it is possible that a tb with multiple instructions is been executed, and therefore eip points to the wrong address, ahead of where it should be. + +In my case, the order is as follows: +* i8259 generates an IRQ + - cpu->interrupt_request contains both CPU_INTERRUPT_TGT_EXT_1 and CPU_INTERRUPT_HARD +* cpu_handle_interrupt() -> x86_cpu_exec_interrupt() is called + - it deals with CPU_INTERRUPT_TGT_EXT_1 + - execution continues +* I am exactly at the instruction where the watchpoint is hit. + - check_watchpoint() is called and cflags_next_tb is set to force the execution of only one instruction. + - execution breaks out of the loop with siglongjmp() +* cpu_handle_interrupt() -> x86_cpu_exec_interrupt() is called + - it deals with the IRQ. eip is changed and cflags_next_tb is spoiled + - execution continues at the IRQ + +[...] +* The kernel finishes dealing with the IRQ + +* I am back at the instruction where the watchpoint is hit. + - A tb is created and executed with two instructions instead of one + - eip is now ahead of the instruction that hit the watchpoint +* cpu_handle_interrupt() is called + - it deals with CPU_INTERRUPT_DEBUG + - the watchpoint is reported by gdb, but with the wrong eip. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/1795 b/results/classifier/deepseek-r1:14b/output/debug/1795 new file mode 100644 index 000000000..730207dfc --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1795 @@ -0,0 +1,9 @@ + +PPC: not honouring single stepping through branches and skips a nip +Description of problem: +When debugging in MacsBug, tracing/stepping over any branches (e.g. blt, bgt) will land on the instruction immediately passed the expected address. It appears that branches will execute the target instruction then single step to the next instruction in one go, instead of single stepping to the target instruction. + +For example, if a blt should land on 13371234, stepping over the branch will land on 13371238. The instruction at 13371234 still executes, but this is not the behaviour on a baremetal Mac OS system. +Additional information: +A <a href="https://i.imgur.com/f6dguMt.png">screenshot</a> before the branch. +A <a href="https://imgur.com/WoVDtN7.png">screenshot<a/> after pressing 't' to step over the branch. Note that the PC is now 1E36CAB8 instead of the expected 1E36CAB4. diff --git a/results/classifier/deepseek-r1:14b/output/debug/1806243 b/results/classifier/deepseek-r1:14b/output/debug/1806243 new file mode 100644 index 000000000..15392f380 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1806243 @@ -0,0 +1,85 @@ + +ARM conditional branch after if-then instruction not working + +Hello + +There seems to be an issue with QEMU when debugging if-then condition blocks from the thumb2 instruction set. The following snippet runs fine during normal execution, but keeps hanging at the conditional branch when debugging. The jump at the branch should only be executed as long as $r0 is lower than $r1. Problem is that once both are equal, the execution is not continued past the branch and the program counter never gets popped. + +2000407a: push {lr} +2000407c: movs r0, r6 +2000407e: ldmia r7!, {r1, r6} +20004080: push {r0, r1} +20004082: str.w r6, [r7, #-4]! +20004086: ldr r6, [sp, #0] +20004088: pop {r0, r1} +2000408a: adds r0, #1 +2000408c: cmp r0, r1 +2000408e: itt lt +20004090: pushlt {r0, r1} +20004092: blt.w 0x20004082 ; unpredictable <IT:lt> // <-- GDB hangs here +20004096: pop {pc} + +I have tried to reproduce the problem with inline assembly but for some reason the following example just worked: + +void f() { + static uint8_t stack[256]{}; + stack[255] = 4; + + asm volatile("\n\t" + "push {lr}" + "\n\t" + + // pre-conditions + "movs r7, %[stack]" + "\n\t" + "movs r6, #1" + "\n\t" + + "movs r0, r6" + "\n\t" + "ldmia r7!, {r1, r6}" + "\n\t" + "push {r0, r1}" + "\n\t" + "1:" + "\n\t" + "str.w r6, [r7, #-4]!" + "\n\t" + "ldr r6, [sp, #0]" + "\n\t" + "pop {r0, r1}" + "\n\t" + "adds r0, #1" + "\n\t" + "cmp r0, r1" + "\n\t" + "itt lt" + "\n\t" + "pushlt {r0, r1}" + "\n\t" + + // Original instruction + //"blt.w 0x20004082" // ; unpredictable <IT:lt> + + // Trying to fake it + "blt.w 1b" + "\n\t" + + "pop {pc}" + "\n\t" + : + : [stack] "r"(&stack[255])); +} + +The only real major difference I see to the other code snipped is that the inline assembly is running from flash memory where as the original code runs in ram? Maybe that's a clue somehow? + +Quickly reading through already reported ARM bugs I think this might be related: +https://bugs.launchpad.net/qemu/+bug/1364501 +At least the symptoms sound identical. + + +The versions I'm running are: +QEMU 3.0.0 +arm-none-eabi-gdb 8.2 + +I've also captured some trace output for single stepping from the pushlt to the blt.w instruction with the trace arguments unimp, guest_errors, op, int, exec. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/1810590 b/results/classifier/deepseek-r1:14b/output/debug/1810590 new file mode 100644 index 000000000..4e3e40e1f --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1810590 @@ -0,0 +1,22 @@ + +Record/replay example does not work + +Trying the record part of the record/replay example at https://github.com/qemu/qemu/blob/master/docs/replay.txt qemu immediately hangs with no guest output displayed. This is with qemu from today's git (e59dbbac0364344a3ad84c3497a98c56003d3fb8). + +To reproduce: + + wget https://people.debian.org/~aurel32/qemu/i386/debian_squeeze_i386_standard.qcow2 + + mv debian_squeeze_i386_standard.qcow2 disk.qcow2 + + qemu-system-i386 \ + -icount shift=7,rr=record,rrfile=replay.bin \ + -drive file=disk.qcow2,if=none,id=img-direct \ + -drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay \ + -device ide-hd,drive=img-blkreplay \ + -netdev user,id=net1 -device rtl8139,netdev=net1 \ + -object filter-replay,id=replay,netdev=net1 + +The above qemu command line is exactly the same as in the example. + +Tested on a Debian 9 x86_64 host. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/1812091 b/results/classifier/deepseek-r1:14b/output/debug/1812091 new file mode 100644 index 000000000..2613a882b --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1812091 @@ -0,0 +1,21 @@ + +gdbstub memory accesses performed with wrong attributes + +Qemu-commit: b2f7c27f56bf1116ebb7848c75914aa7c5d6a040 + + +The ARMv8-M architecture (with security extensions) contains a SAU, the Security Attribution Unit. After booting the mps2-an505 and immediately halting (`-S`), I attempt to read the SAU_TYPE register, located at 0xE000EDD4, using gdb (x 0xE000EDD4). The returned value is 0, while the expected value is 8 (number of regions). + +On further investigation, it seems that `attrs.secure` is set to false (armv7m_nvic.c - nvic_readl, line 1167). Commenting out the check will return the correct value. + +As the CPU should be in 'secure' mode after reset, I think this behavior is wrong. + +Steps to reproduce: +Example code that loads an endless loop into the beginning of secure memory: https://github.com/ajblane/armv8m-hello + +Commandline: qemu-system-arm -machine mps2-an505 -cpu cortex-m33 \ + -m 4096 \ + -nographic -serial mon:stdio \ + -kernel $(IMAGE) -s -S + +Attach with arm-none-eabi-gdb, and run x 0xE000EDD4. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/1827 b/results/classifier/deepseek-r1:14b/output/debug/1827 new file mode 100644 index 000000000..649b4cac4 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1827 @@ -0,0 +1,2 @@ + +Turn DPRINTF macro use into tracepoints diff --git a/results/classifier/deepseek-r1:14b/output/debug/1828723 b/results/classifier/deepseek-r1:14b/output/debug/1828723 new file mode 100644 index 000000000..ca90501c8 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1828723 @@ -0,0 +1,6 @@ + +[RFE] option to suppress gemu_log() output + +With user mode emulation, messages from genu_log() are emitted unconditionally to stderr. I didn't find a way to suppress them. It would be nice to have options similar to the -D/-d options to be able to filter and/or redirect the output. + +My use case is chroot/container execution for different architectures via binfmt. In this case it will appear as if the binary in question had emitted messages like "Unsupported setsockopt ..." to stderr while in fact the message came from qemu-*-static. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/1844817 b/results/classifier/deepseek-r1:14b/output/debug/1844817 new file mode 100644 index 000000000..567d56ecd --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1844817 @@ -0,0 +1,25 @@ + +trace: dynamic width format syntax not validated + +The dtrace via stap backend cannot support the dynamic '*' width format. + +Eric noted in https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg04720.html: + + https://sourceware.org/systemtap/langref.pdf + + section 9.2 printf, states: + + "The printf formatting directives are similar to those of C, except that + they are fully checked for type by the translator." + + and does NOT list handling for '*' under precision or width. + +Some trace events have been merged without checking this: + +$ git ls-files|fgrep trace-event|xargs git grep '*\("\|x\)' +hw/block/trace-events:11:pflash_io_read(uint64_t offset, int width, int fmt_width, uint32_t value, uint8_t cmd, uint8_t wcycle) "offset:0x%04"PRIx64" width:%d value:0x%0*x cmd:0x%02x wcycle:%u" +hw/block/trace-events:12:pflash_io_write(uint64_t offset, int width, int fmt_width, uint32_t value, uint8_t wcycle) "offset:0x%04"PRIx64" width:%d value:0x%0*x wcycle:%u" +hw/block/trace-events:13:pflash_data_read(uint64_t offset, int width, uint32_t value) "data offset:0x%04"PRIx64" value:0x%0*x" +hw/block/trace-events:14:pflash_data_write(uint64_t offset, int width, uint32_t value, uint64_t counter) "data offset:0x%04"PRIx64" value:0x%0*x counter:0x%016"PRIx64 +hw/mips/trace-events:2:gt64120_read(const char *regname, int width, uint64_t value) "gt64120 read %s value:0x%0*" PRIx64 +hw/mips/trace-events:3:gt64120_write(const char *regname, int width, uint64_t value) "gt64120 write %s value:0x%0*" PRIx64 \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/1857640 b/results/classifier/deepseek-r1:14b/output/debug/1857640 new file mode 100644 index 000000000..4829cd729 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1857640 @@ -0,0 +1,132 @@ + +qemu-system-i386 registers clobbered after gdb set due to k_gs_base bug in gdbstub + +Due to a bug in /target/i386/gdbstub.c, setting registers in gdb causes the ones following k_gs_base to get clobbered. + +I'm using qemu version 4.2.50 on an msys64 and start qemu's i386 with a gdb server. + +$ qemu-system-i386 -version +QEMU emulator version 4.2.50 (v4.2.0-363-gdd5b0f9549-dirty) +Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers + +$ qemu-system-i386 -gdb tcp::29096 -S +C:\msys64\usr\local\qemu-system-i386.exe: invalid accelerator kvm +C:\msys64\usr\local\qemu-system-i386.exe: falling back to tcg + + +I start a gdb client, connect to the server, display the register state, set k_gs_base, display the register state again, and notice an issue. (Setting other registers also clobbers the ones after k_gs_base). + +$ gdb -q +(gdb) target remote :29096 +... +(gdb) info regs +... +gs_base 0x0 0 +k_gs_base 0x0 0 +cr0 0x60000010 [ CD NW ET ] +cr2 0x0 0 +... +(gdb) set $k_gs_base = 0x41414141 +(gdb) info regs +... +gs_base 0x0 0 +k_gs_base 0x0 0 +cr0 0x41414151 [ CD WP ET PE ] +cr2 0x60000010 1610612752 +... + + +In the gdbstub code, I notice that the read and write functions are not symmetric for IDX_SEG_REGS + 8, which corresponds to k_gs_base. + +$ cat /usr/local/src/qemu-4.2.0/target/i386/gdbstub.c +... +int x86_cpu_gdb_read_register(CPUState *cs, uint8_t *mem_buf, int n) +{ +... + case IDX_SEG_REGS + 8: +#ifdef TARGET_X86_64 + if ((env->hflags & HF_CS64_MASK) || GDB_FORCE_64) { + return gdb_get_reg64(mem_buf, env->kernelgsbase); + } + return gdb_get_reg32(mem_buf, env->kernelgsbase); +#else + return gdb_get_reg32(mem_buf, 0); +#endif +... +} +... +int x86_cpu_gdb_write_register(CPUState *cs, uint8_t *mem_buf, int n) +{ +... +#ifdef TARGET_X86_64 + case IDX_SEG_REGS + 8: + if (env->hflags & HF_CS64_MASK) { + env->kernelgsbase = ldq_p(mem_buf); + return 8; + } + env->kernelgsbase = ldl_p(mem_buf); + return 4; +#endif +... +} +... + + +I change the write function, rebuild, and verify that the issue is resolved. + +$ cat /usr/local/src/qemu-4.2.0/target/i386/gdbstub.c +int x86_cpu_gdb_write_register(CPUState *cs, uint8_t *mem_buf, int n) +{ +... + case IDX_SEG_REGS + 8: +#ifdef TARGET_X86_64 + if (env->hflags & HF_CS64_MASK) { + env->kernelgsbase = ldq_p(mem_buf); + return 8; + } + env->kernelgsbase = ldl_p(mem_buf); + return 4; +#else + return 4; +#endif +... +} +... + +$ make +... +$ make install +... + +$ qemu-system-i386 -gdb tcp::29096 -S + +$ gdb -q +(gdb) target remote :29096 +... +(gdb) info regs +... +gs_base 0x0 0 +k_gs_base 0x0 0 +cr0 0x60000010 [ CD NW ET ] +cr2 0x0 0 +... +(gdb) set $k_gs_base = 0x41414141 +(gdb) info regs +... +gs_base 0x0 0 +k_gs_base 0x0 0 +cr0 0x60000010 [ CD NW ET ] +cr2 0x0 0 +... + + +I'll submit the patch below. + +$ diff gdbstub.c gdbstub.c.bkp +353d352 +< case IDX_SEG_REGS + 8: +354a354 +> case IDX_SEG_REGS + 8: +362,363d361 +< #else +< return 4; \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/1869497 b/results/classifier/deepseek-r1:14b/output/debug/1869497 new file mode 100644 index 000000000..3d6e062fb --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1869497 @@ -0,0 +1,11 @@ + +x86_cpu_gdb_read_register segfaults when gdb requests registers + +When attempting to attach to the gdbstub, a segfault occurs. + +I traced this down to a problem in a call to gdb_get_reg16 where the mem_buf +was being treated like a uint8_t* instead of a GByteArray. The buffer passed +to gdb_get_reg16 ends up passing an invalid GByteArray pointer, which subsequently +causes a segfault in memcpy. + +I have a fix for this - just need to educate myself on how to submit a patch. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/1873898 b/results/classifier/deepseek-r1:14b/output/debug/1873898 new file mode 100644 index 000000000..81eadb9e3 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1873898 @@ -0,0 +1,39 @@ + +arm linux-user: bkpt insn doesn't cause SIGTRAP + +QEMU's 32-bit arm linux-user mode doesn't correctly turn guest BKPT insns into SIGTRAP signals. Test case: + +===begin bkpt.c=== +/* test bkpt insn */ + +#include <stdlib.h> +#include <stdio.h> + +int main(void) +{ + printf("breakpoint\n"); +#ifdef __aarch64__ + __asm__ volatile("brk 0x42\n"); +#else + __asm__ volatile("bkpt 0x42\n"); +#endif + printf("done\n"); + return 0; +} +===endit=== + +Compile with +$ arm-linux-gnueabihf-gcc -g -Wall -o bkpt-aa32 bkpt.c +$ aarch64-linux-gnu-gcc -g -Wall -o bkpt-aa64 bkpt.c + +Contrast aarch64 which delivers the SIGTRAP and arm which doesn't: + +$ qemu-aarch64 bkpt-aa64 +breakpoint +qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped +Trace/breakpoint trap (core dumped) +$ qemu-arm bkpt-aa32 +breakpoint +done + +This is because in linux-user/arm/cpu-loop.c we incorrectly treat EXCP_BKPT similarly to EXCP_SWI, which means that we actually perform a syscall (which one depends on what happens to be in r7...). This code has been like this (more or less) since commit 06c949e62a098f in 2006 which added BKPT in the first place. This is probably because at the time the same code path was used to handle both Linux syscalls and semihosting calls, and (on M profile) BKPT does imply a semihosting call. But these days we've moved handling of semihosting out to an entirely different codepath, so we can fix this bug by simply removing this handling of EXCP_BKPT and instead making it deliver a SIGTRAP like EXCP_DEBUG (as we do already on aarch64). \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/1879646 b/results/classifier/deepseek-r1:14b/output/debug/1879646 new file mode 100644 index 000000000..db8b0c117 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1879646 @@ -0,0 +1,31 @@ + +[Feature request] x86: dump MSR features in human form + +QEMU might fail because host/guest cpu features are not properly configured: + +qemu-system-x86_64: error: failed to set MSR 0x48f to 0x7fefff00036dfb +qemu-system-x86_64: /root/qemu-master/target/i386/kvm.c:2695: +kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed. + +To ease debugging, it the MSR features bit could be dumped. + +Example in this thread: + +https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg05593.html + + The high 32 bits are 0111 1111 1110 1111 1111 1111. + + The low 32 bits are 0000 0011 0110 1101 1111 1011. + + The features that are set are the xor, so 0111 1100 1000 0010 0000 0100: + + - bit 2, vmx-exit-nosave-debugctl + - bit 9, host address space size, is handled automatically by QEMU + - bit 15, vmx-exit-ack-intr + - bit 17, vmx-exit-save-pat + - bit 18, vmx-exit-load-pat + - bit 19, vmx-exit-save-efer + - bit 20, vmx-exit-load-efer + - bit 21, vmx-exit-save-preemption-timer + +This output ^^^ is easier to digest. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/1905 b/results/classifier/deepseek-r1:14b/output/debug/1905 new file mode 100644 index 000000000..f08638f87 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1905 @@ -0,0 +1,4 @@ + +Allow for copying text from serial output +Additional information: +In addition to the serial output, it would be beneficial if this copy feature could also be extended to the QEMU monitor and parallel output. diff --git a/results/classifier/deepseek-r1:14b/output/debug/1907210 b/results/classifier/deepseek-r1:14b/output/debug/1907210 new file mode 100644 index 000000000..1c9d989ef --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1907210 @@ -0,0 +1,19 @@ + +QEMU gdbstub command "?" issue + +I am using some third party GDB client, and I have noticed that every time "?" command is send from the client, QEMU gdbstub removes all break points. This behaviour is not expected since "?" command should only return stop reason. +Here is documentation from official gdb: +‘?’ Indicate the reason the target halted. The reply is the same as for step and +continue. This packet has a special interpretation when the target is in non-stop +mode; see Section E.10 [Remote Non-Stop], page 733. +Reply: See Section E.3 [Stop Reply Packets], page 693, for the reply specifications. + +With some help on the irc, we have been able to pin point the failure point(in attachement file gdbstub.c). +Function that handles "?" command has this comment in it: + /* + * Remove all the breakpoints when this query is issued, + * because gdb is doing an initial connect and the state + * should be cleaned up. + */ +From which it is clear that developer that wrote that code assumed, that because most popular gdb client only uses "?" command at initial connect, it is safe to also remove all BPs. +In my opinion initial connect should be detected in some other way, and not with "?" command. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/1910540 b/results/classifier/deepseek-r1:14b/output/debug/1910540 new file mode 100644 index 000000000..3ce9d8472 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1910540 @@ -0,0 +1,4 @@ + +where the trace file "trace-*" + +I compile qemu-system-aarch64 with --enable-trace-backends=simple option, then start qemu with -trace nvme* , qemu start successful but I cann't find the trace file "trace-*" at qemu started directory. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/1917661 b/results/classifier/deepseek-r1:14b/output/debug/1917661 new file mode 100644 index 000000000..7c1c34e73 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1917661 @@ -0,0 +1,16 @@ + +qemu gdb wrong registers group for riscv64 + +Step to reproduce: +1. run qemu-system-riscv64 in gdb mode +2. attach gdb +3. set a breakpoint and run +4. print register-groups using "maintenance print register-groups" command + +... + sbadaddr 4162 4162 1628 8 long all,general + msounteren 4163 4163 1636 8 long all,general + mbadaddr 4164 4164 1644 8 long all,general + htimedeltah 4165 4165 1652 8 long all,general + +These registers don't belong to general group, instead they belong to all, system and csr groups. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/1919021 b/results/classifier/deepseek-r1:14b/output/debug/1919021 new file mode 100644 index 000000000..9f0f748af --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1919021 @@ -0,0 +1,9 @@ + +Confuse error message in virtio_init_region_cache() + +The error message added in commit e45da653223 to virtio_init_region_cache() +are somehow confuse: + + qemu-system-i386: Cannot map used + +It would be helpful to more explicit string, including "virtio" prefix. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/1921092 b/results/classifier/deepseek-r1:14b/output/debug/1921092 new file mode 100644 index 000000000..3386cc17a --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1921092 @@ -0,0 +1,6 @@ + +gdbstub debug of multi-cluster machines is undocumented and confusing + +Working with Zephyr RTOS, running a multi core sample on mps2_an521 works fine. Both cpus start. +Trying to debug with options -s -S the second core fails to boot. +Posted with explanation also at: https://github.com/zephyrproject-rtos/zephyr/issues/33635 \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/1923693 b/results/classifier/deepseek-r1:14b/output/debug/1923693 new file mode 100644 index 000000000..9b1cfab76 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/1923693 @@ -0,0 +1,18 @@ + +Lack of architecture in gdbstub makes debugging confusing + +I spent some quality time debugging GEF and came to a conclusion here: +https://github.com/hugsy/gef/issues/598#issuecomment-819174169 + +tldr; + +* gdb_arch_name was undefined on riscv +* this bug was fixed recently via https://github.com/qemu/qemu/commit/edf647864bdab84ed4b1a4f47ea05be6bb075c69 + + +* An undefined gdb_arch_name results in qemu's gdbstub omitting the <architecture> xml. +* gdb translates a missing <architecture> as "auto" which breaks a lot of stuff. +* tracking down where "auto" comes from is a bit confusing and time consuming. + + +It might be better to report a missing / blank gdb_arch_name as "<architecture>unknown</architecture>" instead of omitting the block completely. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/2059 b/results/classifier/deepseek-r1:14b/output/debug/2059 new file mode 100644 index 000000000..6e425a557 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/2059 @@ -0,0 +1,24 @@ + +Solaris 2.6.5 panic when trying to debug a binary with Sun Workshop V5n1, or V6n1 debugger +Description of problem: +Following [this guide](https://www.gekk.info/articles/solaris26.htm), and similarly to issue #1166, the guest panics when one tries to debug a binary with the debugger provided in [Sun Workshop V5n1](https://archive.org/details/sunworkshopforsolaris2vol5num1_704546810revb), and in [Sun Workshop v6n1](https://archive.org/details/devpro_v6n1) as well. +The Sun Workshop is EOL, available at the archive, with free non-expiring demo licenses [made available](https://archive.org/details/suncomp-lic) by Sun before the Oracle acquisition. +The guest was patched with the latest available patches included [in this cluster](https://archive.org/details/sun26gnu). +The following information was collected when debugging bunzip2, but any binary panics the guest. +``` +panic: Non-parity synchronous error: ctx=54 va=ef7cbc44 pa=e0a8c44 +syncing filesystems... 15 done +NOTICE: zs3:ring buffer overflow +``` +Steps to reproduce: +1. Start the Sun Workshop (SUNWspro/bin/workshop), go to the Debugger in the menu +2. Debug/New Program, load any binary, place a breakpoint in main or wherever +3. Execute, guest kernel panic +Additional information: +This happens with the Fujitsu MB86904 specified as CPU, and without specifying a cpu, using the default for the SS-5. + + + +Explicitly setting the TI MicroSparc I and setting memory to 32M seems to start the debugger, the guest still panics, but a bit further down the line + + diff --git a/results/classifier/deepseek-r1:14b/output/debug/208 b/results/classifier/deepseek-r1:14b/output/debug/208 new file mode 100644 index 000000000..6e35ad30c --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/208 @@ -0,0 +1,2 @@ + +Write a new, asynchronous qmp-shell TUI diff --git a/results/classifier/deepseek-r1:14b/output/debug/2104 b/results/classifier/deepseek-r1:14b/output/debug/2104 new file mode 100644 index 000000000..837b4cc42 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/2104 @@ -0,0 +1,2 @@ + +source code of function trace_memory_region_ops_write() diff --git a/results/classifier/deepseek-r1:14b/output/debug/2105 b/results/classifier/deepseek-r1:14b/output/debug/2105 new file mode 100644 index 000000000..4e651707d --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/2105 @@ -0,0 +1,2 @@ + +memory trace not logging every memory write operation diff --git a/results/classifier/deepseek-r1:14b/output/debug/2119 b/results/classifier/deepseek-r1:14b/output/debug/2119 new file mode 100644 index 000000000..43eac92e6 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/2119 @@ -0,0 +1,2 @@ + +target/riscv/gdbstub.c：The V registers in gdb debugging mode can only be accessed when the single-letter V is enabled diff --git a/results/classifier/deepseek-r1:14b/output/debug/2130 b/results/classifier/deepseek-r1:14b/output/debug/2130 new file mode 100644 index 000000000..ad8386681 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/2130 @@ -0,0 +1,2 @@ + +latest code missing "singlestep" diff --git a/results/classifier/deepseek-r1:14b/output/debug/2147 b/results/classifier/deepseek-r1:14b/output/debug/2147 new file mode 100644 index 000000000..61420dfee --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/2147 @@ -0,0 +1,10 @@ + +The Windows version of QEMU runs the semihost project without printing +Description of problem: +In Linux, running this command to execute the Semihost project will print `Hello World` in the console, but running in Windows will not print anything. + +I'd like to know if it's the windows version of qemu that doesn't have perfect support for semihost, or if I need to adjust the input parameters. +Steps to reproduce: + +Additional information: + diff --git a/results/classifier/deepseek-r1:14b/output/debug/2152 b/results/classifier/deepseek-r1:14b/output/debug/2152 new file mode 100644 index 000000000..ed39bb236 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/2152 @@ -0,0 +1,2 @@ + +TCG plugin to keep track what byte is load/store into memory diff --git a/results/classifier/deepseek-r1:14b/output/debug/2214 b/results/classifier/deepseek-r1:14b/output/debug/2214 new file mode 100644 index 000000000..cd81dd92f --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/2214 @@ -0,0 +1,2 @@ + +QEMU gdbstub does not report SIGALRM diff --git a/results/classifier/deepseek-r1:14b/output/debug/2266 b/results/classifier/deepseek-r1:14b/output/debug/2266 new file mode 100644 index 000000000..e13840870 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/2266 @@ -0,0 +1,70 @@ + +qemu-system-x86_64: stuck on watchpoint hit +Description of problem: + +Steps to reproduce: +1. `gcc -O0 -g watch-bug.c -o watch-bug` +2. `gdb watch-bug` +3. gdb commands: +``` +b main +r +watch l1 +next [ correct stop on the next line ] +next [ qemu is stuck as watchpoint should be hit ] +``` +Additional information: +* NOTE: it works correctly, if 'continue' command is used instead of 'next' + + +`watch-bug.c` +```c +int i0; +long l1; + + +int main(int argc, char* argv[]) +{ + i0 = argc; + l1 = i0 * 7; + + return 0; +} + +``` + +Log: +```c +Log: +root@qemux86-64:~# gdb watch-bug +GNU gdb (GDB) 13.2 +Copyright (C) 2023 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "x86_64-poky-linux". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +<https://www.gnu.org/software/gdb/bugs/>. +Find the GDB manual and other documentation resources online at: + <http://www.gnu.org/software/gdb/documentation/>. + +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from watch-bug... +(gdb) b main +Breakpoint 1 at 0x1134: file watch-bug.c, line 8. +(gdb) r +Starting program: /home/root/watch-bug +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib/libthread_db.so.1". + +Breakpoint 1, main (argc=1, argv=0x7fffffffecd8) at watch-bug.c:8 +8 i0 = argc; +(gdb) watch l1 +Hardware watchpoint 2: l1 +(gdb) next +9 l1 = i0 * 7; +(gdb) next +``` diff --git a/results/classifier/deepseek-r1:14b/output/debug/2279 b/results/classifier/deepseek-r1:14b/output/debug/2279 new file mode 100644 index 000000000..0773153aa --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/2279 @@ -0,0 +1,26 @@ + +Debugging with Lauterbach Trace32 -> Cortex-A76, no SP register update +Description of problem: +We do not see changes in the SP_EL1 register value when debugging the QEMU application with Lauterbach Trace32. +Steps to reproduce: +1. Compile bare metal code that uses push and pop instructions (stack). +2. Run QEMU with bare metal code. +3. Connect via Lauterbach Trace32 and check the displayed SP register value. +Additional information: + +This is a screenshot from QEMU 8.0.0, but updating to QEMU 8.2.0 does not resolve the problem. + +I have discussed this with Lauterbach Trace32 support with these results: +- Trace32 uses RSP protocol `p` packets to read some registers, including SP_EL1. GDB seems to use `g` packet. +- QEMU responds to `p` packet with an invalid value, which causes Trace32 to display invalid value. + +Some related RSP protocol logs from Trace32. + + + +Different part of RSP protocol log: +``` +Sending packet: $p20#d2 ... +receiving packet: ec00004000000000 +``` +So it looks like Trace32 can receive different values that zero as response to `p` packet. diff --git a/results/classifier/deepseek-r1:14b/output/debug/230 b/results/classifier/deepseek-r1:14b/output/debug/230 new file mode 100644 index 000000000..9e2e73ea6 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/230 @@ -0,0 +1,2 @@ + +Confuse error message in virtio_init_region_cache() diff --git a/results/classifier/deepseek-r1:14b/output/debug/245 b/results/classifier/deepseek-r1:14b/output/debug/245 new file mode 100644 index 000000000..36c7c7e96 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/245 @@ -0,0 +1,2 @@ + +watchpoints might not properly stop execution at the right address diff --git a/results/classifier/deepseek-r1:14b/output/debug/2465 b/results/classifier/deepseek-r1:14b/output/debug/2465 new file mode 100644 index 000000000..5c8e7b5b2 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/2465 @@ -0,0 +1,2 @@ + +QEMU does not stop other threads when hitting a breakpoint diff --git a/results/classifier/deepseek-r1:14b/output/debug/2477 b/results/classifier/deepseek-r1:14b/output/debug/2477 new file mode 100644 index 000000000..21beaa42a --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/2477 @@ -0,0 +1,2 @@ + +GDB_HAS_MTE detection is incomplete diff --git a/results/classifier/deepseek-r1:14b/output/debug/2479 b/results/classifier/deepseek-r1:14b/output/debug/2479 new file mode 100644 index 000000000..3c5dc1964 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/2479 @@ -0,0 +1,31 @@ + +Unable to remotely debug with gdbserver on debian while using qemu-system-m68k emulator +Description of problem: +When I use gdb-multiarch to try to connect to the gdbserver running on the guest machine the error message below is displayed by the gdbserver: + +``` +/build/gdb-Lhte76/gdb-13.2/gdbserver/tdesc.cc:195: A problem internal to GDBserver has been detected. +tdesc_get_features_xml: Assertion `tdesc->xmltarget != NULL || (!tdesc->features.empty () && tdesc->arch != NULL)' failed. +``` + +and the program execution is terminated abruptly. +Steps to reproduce: +1. Download the Debian Motorola 680x0 Port and install it using QEmu. +2. Update to unstable version (optional). +3. Download and install gdbserver and also a compiler for the C language. +4. Write a hello world and compile. +5. Run gdbserver targeting the program from the previous step. +6. Try connecting using gdb-multiarch. +Additional information: +The error persists when I download the QEmu source code and compile it. + +If this procedure is done with an older version of gdbserver (such as 7.12) then I can connect normally. However, if a breakpoint is placed anywhere in the program and if it is reached at any point during execution and if after it is reached the 'continue' command is entered, then the error message below is displayed by the gdbserver: + +``` +linux-low.c:2627: A problem internal to GDBserver has been detected. +int maybe_hw_step(thread_info*): Assertion `has_reinsert_breakpoints (thread)' failed. +``` + +and the program execution is terminated abruptly. + +I think it's working on real hardware. diff --git a/results/classifier/deepseek-r1:14b/output/debug/2524 b/results/classifier/deepseek-r1:14b/output/debug/2524 new file mode 100644 index 000000000..d4b7f057f --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/2524 @@ -0,0 +1,4 @@ + +Reverse debugging is broken on release and stable branches +Description of problem: +Master branch has commit 94962ff00d09674047aed896e87ba09736cd6941, which reverts incorrect commit and fix reverse debugging. But this commit is missing in 9.0.x 9.1.x releases branches and in stable branches too. diff --git a/results/classifier/deepseek-r1:14b/output/debug/2544 b/results/classifier/deepseek-r1:14b/output/debug/2544 new file mode 100644 index 000000000..6f7e262ee --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/2544 @@ -0,0 +1,2 @@ + +Bug: qemu not properly flushing error messages related to bad arguments diff --git a/results/classifier/deepseek-r1:14b/output/debug/2546 b/results/classifier/deepseek-r1:14b/output/debug/2546 new file mode 100644 index 000000000..768429cce --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/2546 @@ -0,0 +1,2 @@ + +Troubleshooting Data Abort Error While Debugging U-Boot on mcimx6ul-evk in QEMU diff --git a/results/classifier/deepseek-r1:14b/output/debug/2580 b/results/classifier/deepseek-r1:14b/output/debug/2580 new file mode 100644 index 000000000..9ad5a96c4 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/2580 @@ -0,0 +1,13 @@ + +qemu-aarch64_be 9.1.0 fails to run any Linux programs due to unreachable in gdb_find_static_feature() +Description of problem: +``` +❯ cat empty.c +void _start() {} +❯ clang empty.c -target aarch64_be-linux -nostdlib -fuse-ld=lld +❯ qemu-aarch64_be ./a.out +** +ERROR:../gdbstub/gdbstub.c:493:gdb_find_static_feature: code should not be reached +Bail out! ERROR:../gdbstub/gdbstub.c:493:gdb_find_static_feature: code should not be reached +fish: Job 1, 'qemu-aarch64_be ./a.out' terminated by signal SIGABRT (Abort) +``` diff --git a/results/classifier/deepseek-r1:14b/output/debug/2590 b/results/classifier/deepseek-r1:14b/output/debug/2590 new file mode 100644 index 000000000..318050016 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/2590 @@ -0,0 +1,24 @@ + +qemu-x86_64: gdb doesn't read symbols from dynamically linked shared libraries. +Description of problem: +GDB fails to load dynamically linked shared libraries when connecting to qemu-x86_64, causing it to not recognize symbols from the shared libraries. As a result, breakpoints in shared library functions (e.g, `break printf`) do not work. +Steps to reproduce: +1. Start the debug server: `./qemu-x86_64 -g PORT ./x86_64-binary` +2. Connect GDB to the debug server: +``` +$ gdb-multiarch ./x86_64-binary +(gdb) set verbose on +(gdb) target remote :PORT +``` +3. GDB displays a warning and fails to load shared libraries: +``` +(gdb) target remote :PORT +Remote debugging using :PORT +warning: platform-specific solib_create_inferior_hook did not load initial shared libraries. +(gdb) info sharedlibrary +No shared libraries loaded at this time. +``` +Additional information: +This issue does not occur when using gdbserver on a native x86_64 machine and connecting to it from gdb-multiarch on an ARM64 machine, indicating the issue is likely related to QEMU rather than GDB. + +GDB correctly recognizes symbols from the target binary (e.g., the `main` function), and breakpoints at these symbols function as expected. diff --git a/results/classifier/deepseek-r1:14b/output/debug/2640 b/results/classifier/deepseek-r1:14b/output/debug/2640 new file mode 100644 index 000000000..80ca2d232 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/2640 @@ -0,0 +1,2 @@ + +QEMU twice logging when use SDL. diff --git a/results/classifier/deepseek-r1:14b/output/debug/2697 b/results/classifier/deepseek-r1:14b/output/debug/2697 new file mode 100644 index 000000000..65ba96a59 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/2697 @@ -0,0 +1,2 @@ + +system/physmem: gdb memory rw no access on armv7m MPU diff --git a/results/classifier/deepseek-r1:14b/output/debug/2751 b/results/classifier/deepseek-r1:14b/output/debug/2751 new file mode 100644 index 000000000..8812b65f8 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/2751 @@ -0,0 +1,2 @@ + +QEMU user emulation gdbstub emits incorrect file descriptor and errno values diff --git a/results/classifier/deepseek-r1:14b/output/debug/2760 b/results/classifier/deepseek-r1:14b/output/debug/2760 new file mode 100644 index 000000000..ba6ead57b --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/2760 @@ -0,0 +1,2 @@ + +Some Aarch64 system registers not available via the debugger diff --git a/results/classifier/deepseek-r1:14b/output/debug/2790 b/results/classifier/deepseek-r1:14b/output/debug/2790 new file mode 100644 index 000000000..2f3fa1e4a --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/2790 @@ -0,0 +1,11 @@ + +Can't switch to monitor with rr=record +Description of problem: +With the above args, while the guest is paused (either because I haven't attached GDB yet, or because I've halted execution in GDB), it's not possible to switch to the QEMU monitor. + +I don't reproduce this issue with `QEMU emulator version 8.2.4 (Debian 1:8.2.4+ds-1+build1)` but I do with 9.2 and master (built from source). + +AFAICT, the monitor is working - if I just set `-monitor stdio` instead of `-serial mon:stdio` I can use it, including when the VM is paused. But the multiplexing doesn't work. +Steps to reproduce: +1. Run the above +2. Ctrl-A, c diff --git a/results/classifier/deepseek-r1:14b/output/debug/454 b/results/classifier/deepseek-r1:14b/output/debug/454 new file mode 100644 index 000000000..4eeb6bcd3 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/454 @@ -0,0 +1,4 @@ + +edk2-aarch64-code.fd prints a lot of debug output +Additional information: +Currently running a QEMU version built from source with the last commit to pc-bios being 7a3d37a3f2335e18539e821d0c72abe0b22480bd (and I don't see any changes to edk2-aarch64-code since) diff --git a/results/classifier/deepseek-r1:14b/output/debug/458 b/results/classifier/deepseek-r1:14b/output/debug/458 new file mode 100644 index 000000000..154e322f8 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/458 @@ -0,0 +1,2 @@ + +Xfer:features:read truncating xml sent to gdb frontends diff --git a/results/classifier/deepseek-r1:14b/output/debug/505 b/results/classifier/deepseek-r1:14b/output/debug/505 new file mode 100644 index 000000000..c6e52f34d --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/505 @@ -0,0 +1,13 @@ + +QEMU crashes when reaching a hardware watchpoint +Description of problem: +When using hardware watchpoints, qemu crashes when it hits the watch point. +See https://github.com/zephyrproject-rtos/zephyr/issues/28613 for the same problem +Steps to reproduce: +1. Download https://download.qemu.org/qemu-6.1.0-rc0.tar.xz +2. Download debian-live-10.10.0-i386-standard.iso from https://cdimage.debian.org/debian-cd/current-live/i386/iso-hybrid/ +3. Build qemu with /configure --target-list=i386-softmmu +4. Run build/qemu-system-i386 -boot d -cdrom debian-live-10.10.0-i386-standard.iso -m 512 -icount auto -gdb tcp:localhost:1234 -S -display none +5. Run gdb and inside gdb run "target remote localhost:1234" +6. In gdb, run "watch *0x0000fff0" and "cont" +7. qemu will crash with ```qemu: fatal: Raised interrupt while not in I/O function``` diff --git a/results/classifier/deepseek-r1:14b/output/debug/581353 b/results/classifier/deepseek-r1:14b/output/debug/581353 new file mode 100644 index 000000000..3b37dbd55 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/581353 @@ -0,0 +1,6 @@ + +qemu doesn't stop execution upon hitting a breakpoint + +Using Qemu 0.12.3 and gdb 7.1 on Ubuntu Lucid. + +I'm trying to debug some bootloader code. Using qemu -s -S to run the bootloader and gdb to connect to qemu, I set the breakpoint at 0x7c00. Then I type continue in gdb. The breakpoint is hit and gdb shows debug information. However qemu apparently continues to execute the code of the bootloader as the text is printed on the screen etc. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/597362 b/results/classifier/deepseek-r1:14b/output/debug/597362 new file mode 100644 index 000000000..28677cbf3 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/597362 @@ -0,0 +1,71 @@ + +qemu-system-sparc singlestep not work in gdbstub + +Debugging with gdb-stub does not work with qemu-system-sparc target + +Qemu compiled from current git tree. + +execution string: qemu-system-sparc.exe -s -S -m 256 -L Bios -hda +sparc.img -boot c +connect with telnet localhost 1234 +enter '$s#73' (without quotes, this is single step command to gdb stub) +gdb stub reply '+' (without quotes, as it accept command) +After this qemu continuously execute instructions in single step mode +and does not exit to gdb stub after each executed instruction with +interrupt signal +("T%02xthread:%02x;" /gdb_vm_state_change in gdbstub.c/ ); + +If we look at target-sparc/translate.c, we can see that +gen_helper_debug() is not called in single step mode: + +======================== + if ((pc & TARGET_PAGE_MASK) == (tb->pc & TARGET_PAGE_MASK) && + (npc & TARGET_PAGE_MASK) == (tb->pc & TARGET_PAGE_MASK) && + !s->singlestep) { + /* jump to same page: we can use a direct jump */ + tcg_gen_goto_tb(tb_num); + tcg_gen_movi_tl(cpu_pc, pc); + tcg_gen_movi_tl(cpu_npc, npc); + tcg_gen_exit_tb((long)tb + tb_num); + } else { + /* jump to another page: currently not optimized */ + tcg_gen_movi_tl(cpu_pc, pc); + tcg_gen_movi_tl(cpu_npc, npc); + tcg_gen_exit_tb(0); + } +========================= + +======================== + /* if single step mode, we generate only one instruction and + generate an exception */ + if (dc->singlestep) { + break; + } +======================== + +If we look similar code at target-sh4/translate.c we can see that is +called in this cases: + +======================== + if ((tb->pc & TARGET_PAGE_MASK) == (dest & TARGET_PAGE_MASK) && + !ctx->singlestep_enabled) { + /* Use a direct jump if in same page and singlestep not enabled */ + tcg_gen_goto_tb(n); + tcg_gen_movi_i32(cpu_pc, dest); + tcg_gen_exit_tb((long) tb + n); + } else { + tcg_gen_movi_i32(cpu_pc, dest); + if (ctx->singlestep_enabled) + gen_helper_debug(); + tcg_gen_exit_tb(0); + } +======================== + +======================== + if (tb->cflags & CF_LAST_IO) + gen_io_end(); + if (env->singlestep_enabled) { + tcg_gen_movi_i32(cpu_pc, ctx.pc); + gen_helper_debug(); + } else { +========================== \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/612 b/results/classifier/deepseek-r1:14b/output/debug/612 new file mode 100644 index 000000000..498ab7036 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/612 @@ -0,0 +1,2 @@ + +Much larger traces with qemu-6.1 than qemu-6.0 diff --git a/results/classifier/deepseek-r1:14b/output/debug/620 b/results/classifier/deepseek-r1:14b/output/debug/620 new file mode 100644 index 000000000..157e1d068 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/620 @@ -0,0 +1,2 @@ + +QEMU gdbstub should add memtag support for aarch64 MTE diff --git a/results/classifier/deepseek-r1:14b/output/debug/640213 b/results/classifier/deepseek-r1:14b/output/debug/640213 new file mode 100644 index 000000000..804fe761c --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/640213 @@ -0,0 +1,24 @@ + +QEMU does not communicate properly with GDB with a 64 bit guest + +I have been trying to figure out why I cannot debug a 64 bit kernel of my own invention. + +I launch qemu-system-x86_64 with the -s -S flags, we also specify -cpu core2duo -vga std and a -hda with an ext2 FS holding our multiboot kernel and GRUB2. + +When I try to set breakpoints and "continue" in GDB (7.2) using the very latest HEAD (b6601141cd2a170dfe773987b06f716a190ea7e0) or 0.12.0 or 0.12.5 or 13.0.rc0 or 13.0.rc1, I get failures of the same nature: + +0x0000000000000000 in ?? () +(gdb) break main +Breakpoint 1 at 0x101730: file src/kernel/init.c, line 18. +(gdb) c + +Program received signal SIGTRAP, Trace/breakpoint trap. +0x0000000000000000 in ?? () +(gdb) + +Note that in this case, main lies in 64 bit mode. However, trying to break on _start yields virtually the same effect and _start is 32 bit code. + +By doing a git bisect, I managed to narrow the commit that introduced this bug to 5f30fa18ad043a841fe9f0c3917ac60f2519ebd1. Reverting this commit on HEAD seemingly fixed the problem for both the 32 bit and 64 bit cases. +I might be doing something incorrectly on my end but this seemed to fix the problem. + +Perhaps the pertinent thing to do would be to revert 5f30fa18ad043a841fe9f0c3917ac60f2519ebd1 as it seems to do nothing but break things unless, of course, this would only break something that I am not aware of further. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/654 b/results/classifier/deepseek-r1:14b/output/debug/654 new file mode 100644 index 000000000..f3d898460 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/654 @@ -0,0 +1,24 @@ + +Strace Log Output Mangled +Description of problem: +The syscall log entries from the strace logging capability can be interrupted by other log messages before the full syscall line is +complete. +This makes parsing the strace syscall lines from the log output difficult. +Steps to reproduce: +1. Run the supplied command with a simple dynamically linked binary, or a binary that performs mmaps +2. Notice that the strace 'mmap' syscall log entries in the trace file are interrupted by the page log output +Additional information: +I have attached an example log from a dynamically linked 'hello world' binary, which demonstrates the bug in the mmap syscall strace entries. [output.trace](/uploads/88c83273582d00241fbf95af735dcc61/output.trace) + + +I believe this bug caused by a couple of things: +Firstly, in the linux-user/syscall.c file: the strace syscall entry is not output atomically, but instead split across two calls: +The first half is at `print_syscall`: https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c#L13153 +And the return value (and new line) is printed in `print_syscall_ret`: https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/syscall.c#L13160 + +In the case of the mmap syscall, the function `log_page_dump` is called between these two functions resulting in the mangled log output: +https://gitlab.com/qemu-project/qemu/-/blob/master/linux-user/mmap.c#L633 +There may be other syscalls that behave similarly, but this was noticed due to the mmap behavior. + + +Internally to the `print_syscall` and `print_syscall_ret` functions, `qemu_log` is called multiple times to compose the full log entry, and it seems that it is inside `qemu_log` that the logfile lock is obtained and dropped - so theoretically another thread can output to the log during the printing of a single syscall entry between these `qemu_log` calls. I do not know if this actually happens in practice besides the mmap scenario described above. diff --git a/results/classifier/deepseek-r1:14b/output/debug/668 b/results/classifier/deepseek-r1:14b/output/debug/668 new file mode 100644 index 000000000..7bfedab27 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/668 @@ -0,0 +1,22 @@ + +No trace verbs +Description of problem: +I am trying to follow [this tutorial](https://github.com/ryanprescott/realtek-verb-tools/wiki/How-to-sniff-verbs-from-a-Windows-sound-driver) to get my sound working again, but I am stuck at the step where I have to analyse the verbs, because I get none. They say I should get things similar to this: +``` +CORB[1] = 0xf0000 (caddr:0x0 nid:0x0 control:0xf00 param:0x0) +CORB[2] = 0xf0002 (caddr:0x0 nid:0x0 control:0xf00 param:0x2) +CORB[3] = 0xf0004 (caddr:0x0 nid:0x0 control:0xf00 param:0x4) +RIRBWP advance to 3, last WP 0 +CORB caddr:0x0 nid:0x0 control:0xf00 param:0x0 response:0x10ec0245 (ex 0x0) +CORB caddr:0x0 nid:0x0 control:0xf00 param:0x2 response:0x100001 (ex 0x0) +CORB caddr:0x0 nid:0x0 control:0xf00 param:0x4 response:0x10001 (ex 0x0) +``` +in the `qemu-output.txt` file, but instead I am getting [this](https://github.com/ryanprescott/realtek-verb-tools/files/7331986/qemu-output.txt) in the console. + +How do I get verbs in the first format ? + +I tried compiling qemu from source with this: `./configure --enable-trace-backends=log --target-list=x86_64-softmmu`, but that produced the same result as using the `qemu-system-x86_64` command that I got by installing qemu with my package manager. +Steps to reproduce: +https://github.com/ryanprescott/realtek-verb-tools/wiki/How-to-sniff-verbs-from-a-Windows-sound-driver +Additional information: +I don't know, as me if I am missing something diff --git a/results/classifier/deepseek-r1:14b/output/debug/675 b/results/classifier/deepseek-r1:14b/output/debug/675 new file mode 100644 index 000000000..986a73000 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/675 @@ -0,0 +1,11 @@ + +Attaching WinDbg to a Windows guest on Windows host causes hang +Description of problem: +Attempting to attach WinDbg to a Windows guest on a Windows host causes qemu to lockup while using real serial ports. This has been an issue for some time (years if I'm remembering correctly) I just haven't reported it. +Steps to reproduce: +1. Enable debug in Windows guest +2. Create a DB9 between 2 COM ports +3. Power guest +4. Attach WinDbg to 2nd COM port not in use by the guest +Additional information: + diff --git a/results/classifier/deepseek-r1:14b/output/debug/690776 b/results/classifier/deepseek-r1:14b/output/debug/690776 new file mode 100644 index 000000000..0aa5abcc9 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/690776 @@ -0,0 +1,6 @@ + +Overwrite argv to set process title, eliminating 16-character prctl() limit. + +I've modified qemu to overwrite its arguments to set the process title, since its current prctl() method has a 16-character limit. + +I posted the original patch to qemu-devel, made the changes others suggested, then re-posted to qemu-devel. I flailed around a bit with the patch submission process and think I finally got it right, but haven't been able to gain the notice of a committer to have this pushed. Maybe this will get more attention when reported in the BTS. \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/700276 b/results/classifier/deepseek-r1:14b/output/debug/700276 new file mode 100644 index 000000000..e5af86c7c --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/700276 @@ -0,0 +1,32 @@ + +QEMU crashed when GDB request a big size variable information + +Hello, +My host is Fedora 13. My QEMU version is 0.13.0, I use QEMU with GDB to debug Linux kernel(Version 2.6.36.2). + +I use QEMU like this:"qemu -s -S -kernel build/arch/i386/boot/bzImage -hda /dev/zero" +When GDB connected with QEMU, and use gdb command print to look big size variable, the qemu is crash down. for example, when I look a task_struct variable 'init_task'(print init_task ), the qemu produce the below message and exit. + +*** stack smashing detected ***: qemu terminated +======= Backtrace: ========= +/lib/libc.so.6(__fortify_fail+0x4d)[0x78a31d] +/lib/libc.so.6[0x78a2ca] +qemu[0x8059e21] +qemu[0x805a0cf] +qemu[0x80d12a1] +qemu[0x8189cb8] +qemu[0x818c3b0] +/lib/libc.so.6(__libc_start_main+0xe6)[0x6a8cc6] +............... +adbf7000-adbf8000 rw-p 00000000 00:00 0 +adbf8000-ae3f8000 rw-p 00000000 00:00 0 +ae3f8000-ae742000 rw-p 00000000 00:00 0 +ae742000-ae762000 rw-p 00000000 00:00 0 +ae762000-ae764000 rw-p 00000000 00:00 0 +ae764000-ae784000 rw-p 00000000 00:00 0 +ae784000-ae786000 rw-p 00000000 00:00 0 +ae786000-b6786000 rw-p 00000000 00:00 0 +b6786000-b7894000 rw-p 00000000 00:00 0 +b78aa000-b78ab000 rw-p 00000000 00:00 0 +bfe95000-bfeaa000 rw-p 00000000 00:00 0 [stack] +已放弃 (core dumped) \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/730 b/results/classifier/deepseek-r1:14b/output/debug/730 new file mode 100644 index 000000000..6435fe51a --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/730 @@ -0,0 +1,2 @@ + +test-thread-breakpoint fails with some gdb version diff --git a/results/classifier/deepseek-r1:14b/output/debug/741115 b/results/classifier/deepseek-r1:14b/output/debug/741115 new file mode 100644 index 000000000..d683b89aa --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/741115 @@ -0,0 +1,9 @@ + +Add support of coprocessor cp15, cp14 registers exposion in the embedded gdb server + +Please add support of exposion of ARM coprocesor registers/logic at the embedded gdb server, + for example of cp15, cp14, etc registers. + +Related project http://jtagarmgdbsrvr.sourceforge.net/index.html + +Also filled bug in the GDB http://sourceware.org/bugzilla/show_bug.cgi?id=12602 \ No newline at end of file diff --git a/results/classifier/deepseek-r1:14b/output/debug/818 b/results/classifier/deepseek-r1:14b/output/debug/818 new file mode 100644 index 000000000..d3f950b3d --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/818 @@ -0,0 +1,6 @@ + +qemu with invalid arg will cause monitor error +Steps to reproduce: +``` +qemu-system-ppc.exe -m 1024M -monitor +``` diff --git a/results/classifier/deepseek-r1:14b/output/debug/85 b/results/classifier/deepseek-r1:14b/output/debug/85 new file mode 100644 index 000000000..72463c248 --- /dev/null +++ b/results/classifier/deepseek-r1:14b/output/debug/85 @@ -0,0 +1,2 @@ + +info registers' command leads to segfault with -M none |