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

[Ladi Prosek <lprosek@redhat.com>]

On Tue, Nov 21, 2017 at 3:07 PM, Mihail Abakumov
<mikhail.abakumov@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.

* 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