Markus Armbruster wrote:
> Jan Kiszka <[EMAIL PROTECTED]> writes:
>
> [...]
>> To summarize the contributions of this series (+ its related kernel
>> bits):
>> - fully functional guest debugging via gdbstub,
>> including hardware breakpoints and watchpoints
>> (pick up current gdb cvs to have hbreak via remote gdb)
>> - (Almost) unlimited number of standard breakpoints
>> - SMP guest debugging support
>> - x86 debug registers support (makes guest's gdb and kgdb happy)
>>
>> The patches are in daily use for several moons here and have proven to
>> be very helpful for tricky kernel debugging task. Specifically,
>> reproducing and then tracking down certain races/deadlocks on SMP boxes
>> is far more comfortable with KVM than on "real metal".
>
> Sounds intriguing. Could you explain briefly what exactly you do to
> wire a debuffer to a guest, so dummies like me can give it a whirl?
It's fairly simple, at least for Linux guests: Compile and install a
guest kernel with CONFIG_DEBUG_INFO, then fire up qemu with '-s'. It
will tell you that it's now listening on TCP port 1234 for incoming
remote gdb connections. Next you can start gdb (or some frontend like
ddd) with the recently compiled 'vmlinux' and connect to qemu via
'tar[et] re[mote] :1234'. You are now able to do source-level debugging
with you guest kernel.
Some things you may want to play with:
o Switching between the guest VCPUs (use 'info threads' and
'thread <n>')
o Hardware breakpoints ('hbreak <symbol>'), useful if you don't want
kvm to insert INT3 in the guest code or if the target address is
currently not addressable
o Hardware watchpoints ('watch <expression>')
BTW, the recommended gdb version for full functionality is not yet
released AFAIK: it's post 6.8. Release 6.8 introduced hbreak/watch via
remote links and fixed thread selection for single-stepping, but had
problems here with reading vmlinux symbols.
Yesterday I posted a new version of the qemu bits in this series and I'm
now hoping for their inclusion. A rebase of the kvm part will soon be
set out as well, but if you stumble over problems with what is currently
available for kvm earlier, let me know, will then try to accelerate things.
Enjoy,
Jan
--
Siemens AG, Corporate Technology, CT SE 2 ES-OS
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
