From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37719 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PZiNY-00049B-Fn for qemu-devel@nongnu.org; Mon, 03 Jan 2011 06:15:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PZiNX-0001fh-0u for qemu-devel@nongnu.org; Mon, 03 Jan 2011 06:15:08 -0500 Received: from fmmailgate02.web.de ([217.72.192.227]:53976) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PZiNW-0001fa-Iv for qemu-devel@nongnu.org; Mon, 03 Jan 2011 06:15:06 -0500 Message-ID: <4D21AFB5.9010605@web.de> Date: Mon, 03 Jan 2011 12:15:01 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4D21A474.2040909@salomon.at> In-Reply-To: <4D21A474.2040909@salomon.at> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig57047666D63F7073967E12C7" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: Debugging a 64-bit kernel in qemu List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Duft Cc: gdb@sourceware.org, qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig57047666D63F7073967E12C7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 03.01.2011 11:27, Markus Duft wrote: > Hi! >=20 > I have been playing a little with this: I'm writing a kernel for both x= 86 and x86-64. While doing so, i'd like to debug the kernel using qemu (a= nd it's gdb stub) and gdb. This worked very well until qemu-0.11.1 (gdb v= ersion does not seem to play any role...). From there on, debugging the 6= 4 bit version no longer works. My sessions look like this with qemu-0.13.= 50 (and any version above 0.11.1, actually...): >=20 > mduft@s01en22 /big/Privat/osdev/tachyon2 $ x86_64-pc-linux-gnu-gdb .bui= ld/x86_64/x86_64-tachyon > GNU gdb (GDB) 7.2.50.20110103-cvs > [snip] > Reading symbols from /big/Privat/osdev/tachyon2/.build/x86_64/x86_64-ta= chyon...done. > (gdb) target remote:1234 > Remote debugging using :1234 > 0x0000000000000000 in ?? () > (gdb) b boot > Breakpoint 1 at 0xffffffff80119000: file /big/Privat/osdev/tachyon2/cor= e/tachyon.boot/Entry.cc, line 25. > (gdb) c > Continuing. > Remote 'g' packet reply is too long: 09ea1180ffffffff009500000000000000= 00000000000000000010000000000002b0ad2b009500000095000000000000d6101180fff= fffffce101180ffffffff0000000000000000000000000000000000000000000000000000= 0000000000000000000000000000000000000000000000000000000000000000000000000= 00000901180ffffffff460000001800000010000000100000001000000010000000100000= 0000000000000000000000000000000000000000000000000000000000000000000000000= 0000000000000000000000000000000000000000000000000000000000000000000000000= 00000000000000007f0300000000000000000000000000000000000000000000000000000= 0000000000000000000000000000000000000000000000000000000000000000000000000= 0000000000000000000000000000000000000000000000000000000000000000000000000= 000000000000000000000000000000000000000000000000000000000000000000000000 > 0000000000000000000000000000000000000000000000000000000000000000000000= 0000000000000000000000000000000000000000000000000000000000000000000000000= 00000000000000000000000000000000000000000000000 > 00000000000000000000000000000000000000000000000000000000000000000000000= 0000000000000000000000000000000000000000801f0000 > (gdb) quit >=20 > actuallly, i _can_ debug the kernel, nut only until the long mode switc= h occurs. after this point: no luck... :[ >=20 > now for the questions: >=20 > 1) is this a problem with qemu or was qemu "fixed" and gdb has a proble= m? > (that's why i CCd the gdb list ;)). > 2) is there any plan to fix this issue? > 3) is there some kind of workaround i can use (i'd be happy with an ugl= y/unsupported patch too, since i build all my stuff myself ;)). You see the effects of a workaround in qemu for gdb shortcomings on x86. See e.g. http://thread.gmane.org/gmane.comp.emulators.qemu/80327, there should be some threads on the gdb list as well. Jan --------------enig57047666D63F7073967E12C7 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.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk0hr7gACgkQitSsb3rl5xTE3ACfaFAHq836G0ROTHSDXxwcaaKe kwAAnAg+9rghI3QvA6F1UcvVqJ70RhAJ =veh2 -----END PGP SIGNATURE----- --------------enig57047666D63F7073967E12C7--