On Mon, Oct 23, 2017 at 10:31 AM, Ladi Prosek <address@hidden>
wrote:
On Tue, Oct 17, 2017 at 3:08 PM, Mihail Abakumov
<address@hidden> 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 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)
Thank you, I am planning to take a closer look and test the changes in
a week or two.
Still wondering if it is limited to Windows hosts or if it can be used
on Linux as well, preferably with KVM.
I haven't been able to make this work.
I've built a 32-bit QEMU for Windows with these patches and used the
command line parameters given above:
qemu-system-i386.exe run with -windbg pipe:win7_dbg
windbg -b -k com:pipe,baud=115200,port=\\.\pipe\win7_dbg,resets=0
The guest is a fresh install of Win7 32-bit.
FS base passes all the checks in windbg_on_load() as the guest kernel
loads and it returns true. QEMU then sends some data over the pipe.
Windbg doesn't print anything, it's still showing:
Opened \\.\pipe\win7_dbg
Waiting to reconnect...
Is this expected? In regular remote kernel debugging, windbg produces
a bunch of output about the target state when it attaches.
The only thing I can reasonably do at this point is Ctrl+Break. This
results in some data exchange between QEMU and windbg but nothing
really changes -- windbg still says "Waiting to reconnect...". Hitting
Ctrl+Break for the second time kills windbg. I tried running windbg
under windbg and was able to capture this output:
Debug target initialization failed, 0x8000FFFF
Once I managed to make windbg actually attach (i.e. it generated the
target state output) but the QEMU process died shortly after that. I
don't know why because I haven't been able to reproduce it.
So, what am I doing wrong? Can you post your detailed steps please?
I'm pasting a dump of the pipe traffic as captured with IO Ninja. "<"
is windbg to QEMU, ">" is QEMU to windbg. QEMU initialized the stub at
14:57:48, the first Ctrl+Break was issued at 15:00:32 and the second
one at 15:01:10.