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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
