Ladi Prosek писал 2017-11-08 16:43:
On Wed, Nov 8, 2017 at 12:54 PM, Mihail Abakumov
<mikhail.abaku...@ispras.ru> wrote:
Ladi Prosek писал 2017-11-06 18:15:
On Mon, Oct 23, 2017 at 10:31 AM, Ladi Prosek <lpro...@redhat.com>
wrote:
On Tue, Oct 17, 2017 at 3:08 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 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.
This is very strange.
After reading the desired addresses (windbg_on_load()), the
interaction
between the stub and windbg begins. A lot of packets are being sent.
This happens about 10 seconds. All this time "Waiting to reconnect
..."
Then the windbg connects.
In your case windbg does not send packets, more specifically, does not
continue to do it. What is your version of windbg. Also, windbg stub
has
been supported only for windbg x64, yet.
Ah, so that's a pretty important piece of information and not very
intuitive given the "Only i386 is supported now." sentence in the
cover email.
Microsoft (R) Windows Debugger Version 10.0.15063.468 X86
Microsoft (R) Windows Debugger Version 10.0.15063.468 AMD64
Microsoft (R) Windows Debugger Version 10.0.16299.15 X86
Microsoft (R) Windows Debugger Version 10.0.16299.15 AMD64
are the versions I have tried. I don't see any difference between x86
and amd64, all versions never connect and crash after the second
break.
What guest OS are you running? Can you maybe zip up your QEMU binaries
and share them with me?
Thanks,
Ladi
Oh, it looks like a problem in the versions. I use the Windbg from
Windows 7.
Windbg version: 6.12.0002.633 AMD64. I will try to test with your
version.
