Re: [Qemu-devel] [PATCH v3 00/45] Windbg supporting

[Ladi Prosek]

On Tue, Nov 21, 2017 at 3:07 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 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.

* 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?

  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