From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LHJbL-00052W-UP for qemu-devel@nongnu.org; Mon, 29 Dec 2008 10:00:15 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LHJbI-00050o-DK for qemu-devel@nongnu.org; Mon, 29 Dec 2008 10:00:14 -0500 Received: from [199.232.76.173] (port=51724 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LHJbI-00050k-4E for qemu-devel@nongnu.org; Mon, 29 Dec 2008 10:00:12 -0500 Received: from fmmailgate02.web.de ([217.72.192.227]:46404) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LHJbH-0005HO-Et for qemu-devel@nongnu.org; Mon, 29 Dec 2008 10:00:11 -0500 Message-ID: <4958E5A7.4000303@web.de> Date: Mon, 29 Dec 2008 15:58:47 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <1229776952.22890.2.camel@ws-aschultz> <200812202208.34044.paul@codesourcery.com> <494D72E1.6020104@web.de> <200812202246.39036.paul@codesourcery.com> <494D8344.8010203@web.de> <20081226233012.GA9221@caradoc.them.org> In-Reply-To: <20081226233012.GA9221@caradoc.them.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig39D38E985A0DD6FB47E59EED" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: gdbstub: packet reply is too long Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Andreas Schultz , Paul Brook , kvm@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig39D38E985A0DD6FB47E59EED Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Daniel Jacobowitz wrote: > On Sun, Dec 21, 2008 at 12:44:04AM +0100, Jan Kiszka wrote: >> And that means setting current_gdbarch while keeping target_gdbarch - >> that's where reality (existing gdb code) bites us. Again, I'm not >> arguing against fixing this, I'm arguing in keeping qemu's workaround >> until this is done. I will look into the gdb part, but one after the o= ther. >=20 > No, it does not mean setting current_gdbarch different from > target_gdbarch. With the current gdbarch set to a 64-bit one that > accurately describes the target, GDB should be able to debug code > running in 32-bit mode. If it can't, there are simply bugs in GDB to > fix. Well, in the current gdb design, current_gdbarch is consulted when disassembling the code while target_gdbarch defines the register set that is exchanged with the remote stub. >=20 > If you'd like to reach some solution to this problem, which I've seen > come up on the QEMU list a half-dozen times now, please describe how > you're using GDB on the gdb@sourceware.org mailing list and let's see > if we can't fix the GDB bugs. I'm pretty sure that any solution is > going to involve always transferring the x86-64 register set, though. I'm pretty sure that the final solution will involve extended x86 register sets in order to inform the frontend about the full target CPU state so that it can set the right current_gdbarch automatically. That's one reason (the other is current/target_gdbarch decoupling) why I see no quick "bug fix" on the gdb side to actually solve the issue and suggest the reintroduction of the qemu workaround until gdb is enhanced appropriately. But you I right, it's time to start a discussion on the gdb list, hopefully laying the ground for a better x86 low-level support. And Maybe I actually miss some smart intermediate step towards this. Jan --------------enig39D38E985A0DD6FB47E59EED 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.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAklY5acACgkQniDOoMHTA+l1qQCdEgHMJPM050pjzIVBQ2RWlZrb WzEAn2bfAyP4Ek2S4eEvHVr075Z1+Prp =8V8c -----END PGP SIGNATURE----- --------------enig39D38E985A0DD6FB47E59EED--