From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41490) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8u3h-0006ax-4L for qemu-devel@nongnu.org; Sat, 17 Mar 2012 09:52:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S8u3b-0004L4-OU for qemu-devel@nongnu.org; Sat, 17 Mar 2012 09:52:36 -0400 Received: from fmmailgate05.web.de ([217.72.192.243]:38638) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8u3b-0004Kt-Eq for qemu-devel@nongnu.org; Sat, 17 Mar 2012 09:52:31 -0400 Received: from moweb001.kundenserver.de (moweb001.kundenserver.de [172.19.20.114]) by fmmailgate05.web.de (Postfix) with ESMTP id 5F8066B80B37 for ; Sat, 17 Mar 2012 14:52:29 +0100 (CET) Message-ID: <4F64971B.4010802@web.de> Date: Sat, 17 Mar 2012 14:52:27 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4F645124.7090001@web.de> <1331983559.29216.1.camel@Quad> In-Reply-To: <1331983559.29216.1.camel@Quad> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC74835E7C52DEE11550DDE1C" Subject: Re: [Qemu-devel] Failed to set a breakpoint on start_kernel List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laurent Vivier Cc: Wei Yang , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC74835E7C52DEE11550DDE1C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2012-03-17 12:25, Laurent Vivier wrote: > Le samedi 17 mars 2012 =C3=A0 09:53 +0100, Jan Kiszka a =C3=A9crit : >> 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=3Dx86_64-softmmu --enable-kvm >>> --enable-debug-tcg --enable-debug --enable-trace-backend=3Dsimple >>> >>> 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 a= nd 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=3D/dev/mapper/vg_wizard-lv_root ro rd.lvm.lv=3Dvg_wizard/lv_roo= t >>> rd.md=3D0 rd.lvm.lv=3Dvg_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=3D/dev/mapper/vg_wizard-lv_root ro rd.lvm.lv=3Dvg_wizard/lv_roo= t >>> rd.md=3D0 rd.lvm.lv=3Dvg_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 tra= p >> 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 (t= he >> CPU starts in 16 bit) and the 64-bit mode of kernel within the same gd= b >> 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 >=20 > You can also try my patch : >=20 > 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 --------------enigC74835E7C52DEE11550DDE1C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9klxwACgkQitSsb3rl5xSZkACg2stJ6QR5P3jOerzX1oJDaAae VK0AoLAcBl5rZtn+WJhzvL5sNlo/fX62 =Waxr -----END PGP SIGNATURE----- --------------enigC74835E7C52DEE11550DDE1C--