Re: tools to dump guest memory and generate core file

[Avi Kivity <avi@qumranet.com>]

david ahern wrote:
> Attaching gdb to qemu you work with addresses as seen by the qemu process; the
> idea is to work with addresses as seen inside the guest.
>
> For example, in the qemu console you can examine guest kernel memory such as
> task structs using guest kernel based addresses:
>
> (qemu) x /128w 0xc0327a80
> 00000000c0327a80: 0x00000000 0xc039a000 0x00000002 0x00000000
> 00000000c0327a90: 0x00000000 0xffffffff 0x0000008c 0x00000078
> 00000000c0327aa0: 0xc0327aa0 0xc0327aa0 0x00000000 0x00000000
> 00000000c0327ab0: 0xffffff9b 0xdae71a00 0x003d098c 0xdae71a00
> 00000000c0327ac0: 0x003d098c 0x00000000 0x00000000 0xffffffff
> ...
>
> where 0xc0327a80 is the address of the first task (init_task symbol). This form
> is really painful to decipher much less follow the task list.
>
>
> Now, if you attach gdb to the qemu process,
>
> gdb /usr/local/bin/qemu-system-x86_64 2346
>   


I meant connecting to the gdb stub in qemu that represents the guest:

  (gdb) target remote localhost:1234

Of course, it means starting qemu with the gdb stub enabled.  We might 
add a monitor command to start it after the fact.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/