Ladi Prosek писал 2017-11-29 11:23:
On Tue, Nov 21, 2017 at 3:07 PM, Mihail Abakumov
<mikhail.abaku...@ispras.ru> wrote:
An update of:
v1:
https://lists.nongnu.org/archive/html/qemu-devel/2017-09/msg07092.html
We made the debugger module WinDbg (like GDB) for QEMU. This is the
replacement of the remote stub in Windows kernel. Used for remote
Windows kernel debugging without debugging mode.
WinDbg is a multipurpose debugger for the Microsoft Windows computer
operating system, distributed by Microsoft. Recent versions of WinDbg
have been and are being distributed as part of the free Debugging
Tools for Windows suite.
How to start debugging QEMU using WinDbg:
Run QEMU with next option:
-windbg pipe:<name>
QEMU will start and pause for waiting WinDbg connection.
Run WinDbg with next options:
-b -k com:pipe,baud=115200,port=\\.\pipe\<name>,resets=0
Wait for debugger connect to kernel.
Note: You can add Symbol Search Path in WinDbg such as
srv*c:\tmp*http://msdl.microsoft.com/download/symbols.
How it works:
The WinDbg debugger has the possibility of connecting to a remote
debug service (Kdsrv.exe) in the Windows kernel. Therefore, it is
possible to connect to the guest system running in the QEMU emulator.
Kernel debugging is possible only with the enabled debugging mode, may
change at the same time. Our module of WinDbg debugger for QEMU is an
alternative of the remote debugging service in the kernel. Thus, the
debugger connects to the debugging module, not to the kernel of the
operating system. The module obtains all the necessary information
answering debugger requests from the QEMU emulator. At the same time
for debugging there is no need to enable debugging mode in the kernel.
This leads to hidden debugging. Our module supports all features of
WinDbg regarding remote debugging, besides interception of events and
exceptions. Only i386 is supported now.
Changed in v3:
- Add a support of the new api functions from the WinDbg v10.
Changed in v2:
- Move target specific code in the 'target/' directory. (Alistair
Francis)
- Change 'kd_api_fill_memory'. Made a fill of memory by line
segments. Before that, a full array was immediately collected and
written in RAM. (Ladi Prosek)
- Change 'kd_api_search_memory'. Made a search for memory by line
segments. (Ladi Prosek)
- Change ld* to st* where it needs. (Ladi Prosek)
- Add a additional check of input arguments in 'windbg_read_context'
and 'windbg_read_ks_regs'. (Ladi Prosek)
- Fix typos. (Ladi Prosek)
- Add a fliping back 'windbg_state->is_loaded' after reset VM.
- Add a check to disabled kvm. It is supported yet. (Ladi Prosek)
- Add a check to device in windbg option. Only pipe is supporting
now. (Alistair Francis)
- Add a check to 'ifdef' WINDBG_DEBUG_ON before define it. (Alistair
Francis)
- Replace printf to qemu_log. (Alistair Francis)
- Fix build on s390x host. (patchew)
- Fix code style error. (patchew)
Thanks, v3 is working with a Win10 windbg for me!
A few things I noticed during my testing (Win7 32-bit guest):
* Windbg prints:
ReadVirtual: 827403d0 not properly sign extended
after connecting. That's likely a bug hiding somewhere.
This is due to the fact that the cpu_memory_rw_debug function cannot
return the required memory region. No physical page mapped.
* lm prints only nt and a bunch of unloaded crash dump modules. This
doesn't look expected and blocks what I believe is the most common way
of initiating debugging which is setting a breakpoint on a specific
driver function. Additionally, after rebooting the guest, lm prints
only nt, nothing else. Do you see the same thing?
Yes, the same.
kd> lm
start end module name
8260b000 82a1d000 nt (pdb symbols) C:\Program
Files (x86)\Windows
Kits\10\Debuggers\x64\sym\ntkrpamp.pdb\684DA42A30CC450F81C535B4D18944B12\ntkrpamp.pdb
Unloaded modules:
869da000 869e7000 crashdmp.sys
869e7000 869f2000 dump_ataport.sys
869f2000 869fb000 dump_atapi.sys
86800000 86811000 dump_dumpfve.sys
* It seems to work on a Linux host as well! Still ok to keep it
limited to pipe: for now, especially if you don't test on Linux.
* Wondering about the legal aspects of copying code from winnt.h. I'll
let others confirm that it's ok.
I have replied to some of the patches with comments.
Thank you!
Ladi
--
Thanks,
Mihail
