On 2012-03-17 12:25, Laurent Vivier wrote: > Le samedi 17 mars 2012 à 09:53 +0100, Jan Kiszka a écrit : >> On 2012-03-16 03:43, Wei Yang wrote: >>> All >>> >>> I like qemu very much and know it could debug the kernel. >>> >>> I tried what I searched on web but couldn't stop at the break point. >>> Below is what I did. >>> >>> 1. Both host and guest installed the same OS, Fedora16 x86_64. >>> >>> 2. Compile the qemu with >>> ./configure --target-list=x86_64-softmmu --enable-kvm >>> --enable-debug-tcg --enable-debug --enable-trace-backend=simple >>> >>> 3. With this command I can boot up my guest. >>> ./../qemu/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -smp 4 -m >>> 1024 -boot dc fedora16.img -monitor stdio >>> >>> 4. I git clone the kernel source in the guest and make a new kernel and >>> initrd. >>> I start the guest with this new kernel successfully >>> >>> 5. I copy out the initrd.img and the .config of kernel to host. >>> compile the kernel on host. >>> the kernel source code is identical on host and gueset, >>> >>> 6. I start the guest with the kernel and initrd on host >>> ./../qemu/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -smp 4 -m >>> 1024 -boot dc fedora16.img -monitor stdio -kernel >>> ~/git/linux-yinghai/arch/x86_64/boot/bzImage -initrd >>> ~/git/debug/initramfs-3.0.0.img -append >>> "root=/dev/mapper/vg_wizard-lv_root ro rd.lvm.lv=vg_wizard/lv_root >>> rd.md=0 rd.lvm.lv=vg_wizard/lv_swap" >>> >>> This works fine. >>> >>> 7. Then I start the guest with gdbstub option >>> ./../qemu/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -smp 4 -m >>> 1024 -boot dc fedora16.img -monitor stdio -kernel >>> /home/ywywyang/git/linux-yinghai/arch/x86_64/boot/bzImage -initrd >>> /home/ywywyang/git/debug/initramfs-3.0.0.img -append >>> "root=/dev/mapper/vg_wizard-lv_root ro rd.lvm.lv=vg_wizard/lv_root >>> rd.md=0 rd.lvm.lv=vg_wizard/lv_swap" -S -gdb tcp::4321 >>> >>> Then the guest stop at the beginning. >>> >>> 8. Attach the gdb in the kernel source directory >>> gdb >>> file vmlinux >>> target remote localhost:4321 >>> b start_kernel >>> c >>> >>> Then the guest will run very happily.... >>> >>> Also use the "info b " could show the break point is set. >>> >>> Which step I made a mistake? >> >> 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 > > You can also try my patch : > > http://patchwork.ozlabs.org/patch/137543/
Unless there is a use case beyond this x86 band-aid, lets focus on getting gdb right. Reminds me that gdb folks asked me to file a bug about this - which I still need to do. :-/ Jan
signature.asc
Description: OpenPGP digital signature