I referred to setting-up-qemu-kernel-mode-debugging-using-exdi to debug the windows kernel. Windbg has been able to successfully face gdbsrv and the first breakpoint single-step test was successful, but once I executed g, the breakpoint single-step test failed again, and the system did not run normally after executing the command g.
Asking for help, need any suggestions. Thanks.
I found you had to have the "right" version of qemu to work well with exdi. Right is defined as works, and not right is defined as does not work. I could not give a specific value. I installed the x64 Windows qemu package, and it worked fine emulating an arm64 processor.
Were you setting a software breakpoint (patches the code) or a hardware breakpoint (program debug address match registers)?
Were you running qemu in hardware pass-thru mode or in emulated mode?
You should turn on the gdb protocol tracing feature in the exdi gdb interface library. The gdb protocol is a pretty simple text protocol so it's not very hard to figure out what's happening. The exdi gdb server is pretty picky about how it talks to the gdb stub. I've seen it work well for arm64 with qemu, and with the Lauterback debugger. It does not work well (not really usable) with openocd. The exdi server alters it's behavior depending on what gdb stub it's talking to and it uses gdb stub specific commands for things like physical memory read/write.
Jan
I am using the latest qemu version qemu-w64-setup-20240828, and the startup parameters are completely from the bat script example in the document. The system I try to run in qemu is win10, and it can be run through qemu under normal circumstances.