2012/3/17 Jan Kiszka <jan.kis...@web.de>: > [ re-added qemu-devel to CC ] > > On 2012-03-17 13:10, Wei Yang wrote: >>> Two major issues with this procedure: >>> >>> 1. When using kvm, a soft breakpoint (as set by 'b') will inject a trap >>> instruction into the guest image - which is not yet loaded after the >>> bios ran. You need to use a hardware breakpoint in this case. >>> >>> 2. Due to gdb limitations, you cannot switch between 16/32-bit mode (the >>> CPU starts in 16 bit) and the 64-bit mode of kernel within the same gdb >>> session. Therefore: >>> - let the target run into Linux is active >>> - attach gdb >>> - issue "hw start_kernel" >>> - reboot (e.g. "monitor system_reset") >>> - you will hit the breakpoint, and gdb will be usable >>> >>> Jan >>> >>> >> oh, so when qemu run with kvm enabled, I couldn't debug the kernel right? > > That's not what I said. You need to be aware of how it works. And, in > contrast to pure emulation, kwm uses a non-transparent mechanism for > injecting software breakpoints. Consider it the price for the gained speed. >
Thanks :) It works. Though I don't understand it totally, I get the rough idea of it. :) >> >> I tried to run qemu with out -enable-kvm, kernel could stop at the break >> point. >> >> BTW, I tried "hw start_kernel", but it failed. >> (gdb) hw start_kernel >> Undefined command: "hw". Try "help". > > Sorry, typo. Must be "hb". > > Jan > -- Richard Yang Help You, Help Me
