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

[Mihail Abakumov <mikhail.abakumov@ispras.ru>]

Ladi Prosek писал 2017-11-29 11:23:
> 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.
> 

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