From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [Qemu-devel] Re: gdbstub: packet reply is too long Date: Fri, 02 Jan 2009 13:53:57 +0100 Message-ID: <495E0E65.9040205@web.de> 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> <4958E5A7.4000303@web.de> <20081230224302.GA30049@caradoc.them.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC006C6F2944D4E2C72DFC78D" Cc: qemu-devel@nongnu.org, Andreas Schultz , Paul Brook , kvm@vger.kernel.org To: Daniel Jacobowitz Return-path: Received: from fmmailgate03.web.de ([217.72.192.234]:37146 "EHLO fmmailgate03.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757367AbZABMyF (ORCPT ); Fri, 2 Jan 2009 07:54:05 -0500 In-Reply-To: <20081230224302.GA30049@caradoc.them.org> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC006C6F2944D4E2C72DFC78D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Daniel Jacobowitz wrote: > On Mon, Dec 29, 2008 at 03:58:47PM +0100, Jan Kiszka wrote: >> 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 > This is a transitional state. Really, there isn't supposed to be a > 'current' gdbarch; we're already moving away from it. >=20 > Thinking about it some more you may be right about the overall > solution though, sorry. The target_gdbarch idea is likely to stick > around for a while. But some work will have to be done if current and > target architectures have different register sets :-( I'll start a thread on the gdb list today, CC'ing you. Would be nice if you could then add more details on what you think would be required to achieve this. >=20 >> I'm pretty sure that the final solution will involve extended x86 >> register sets in order to inform the frontend about the full target CP= U >> state so that it can set the right current_gdbarch automatically. >=20 > Isn't everything we need for this in eflags already? You need CR0.PE to detect if you are in real or protected mode. And then you need GDTR/LDTR to find the descriptor CS is pointing at, parsing it to detect if you are running 16, 32 or 64 bit code (by default). Those extensions would also be useful in order to decode memory addresses in case descriptor.base !=3D 0 (or if it's CS >> 4, ie. you are in real mode). We have some usable patches for this @work, at least for 16 vs. 32 bit. But it's clear that more work is needed to get things upstream and we should first agree on how things should be done there, e.g. how to extend the register set and how to communicate that extension between backend and frontend. Jan --------------enigC006C6F2944D4E2C72DFC78D 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 iEYEARECAAYFAkleDmkACgkQniDOoMHTA+miswCeJW/H4YUqmQBx8/Fphff/7Pgf iaEAnj6Wi2AKD5wdUsEhCjap0lGMgIpC =Ww7Y -----END PGP SIGNATURE----- --------------enigC006C6F2944D4E2C72DFC78D-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LIjXS-0006yz-Oz for qemu-devel@nongnu.org; Fri, 02 Jan 2009 07:54:06 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LIjXS-0006yg-2z for qemu-devel@nongnu.org; Fri, 02 Jan 2009 07:54:06 -0500 Received: from [199.232.76.173] (port=37137 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LIjXR-0006ya-TM for qemu-devel@nongnu.org; Fri, 02 Jan 2009 07:54:05 -0500 Received: from fmmailgate03.web.de ([217.72.192.234]:37152) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LIjXR-0000MD-6l for qemu-devel@nongnu.org; Fri, 02 Jan 2009 07:54:05 -0500 Message-ID: <495E0E65.9040205@web.de> Date: Fri, 02 Jan 2009 13:53:57 +0100 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: gdbstub: packet reply is too long 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> <4958E5A7.4000303@web.de> <20081230224302.GA30049@caradoc.them.org> In-Reply-To: <20081230224302.GA30049@caradoc.them.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC006C6F2944D4E2C72DFC78D" Sender: jan.kiszka@web.de Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Daniel Jacobowitz Cc: Andreas Schultz , qemu-devel@nongnu.org, kvm@vger.kernel.org, Paul Brook This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC006C6F2944D4E2C72DFC78D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Daniel Jacobowitz wrote: > On Mon, Dec 29, 2008 at 03:58:47PM +0100, Jan Kiszka wrote: >> 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 > This is a transitional state. Really, there isn't supposed to be a > 'current' gdbarch; we're already moving away from it. >=20 > Thinking about it some more you may be right about the overall > solution though, sorry. The target_gdbarch idea is likely to stick > around for a while. But some work will have to be done if current and > target architectures have different register sets :-( I'll start a thread on the gdb list today, CC'ing you. Would be nice if you could then add more details on what you think would be required to achieve this. >=20 >> I'm pretty sure that the final solution will involve extended x86 >> register sets in order to inform the frontend about the full target CP= U >> state so that it can set the right current_gdbarch automatically. >=20 > Isn't everything we need for this in eflags already? You need CR0.PE to detect if you are in real or protected mode. And then you need GDTR/LDTR to find the descriptor CS is pointing at, parsing it to detect if you are running 16, 32 or 64 bit code (by default). Those extensions would also be useful in order to decode memory addresses in case descriptor.base !=3D 0 (or if it's CS >> 4, ie. you are in real mode). We have some usable patches for this @work, at least for 16 vs. 32 bit. But it's clear that more work is needed to get things upstream and we should first agree on how things should be done there, e.g. how to extend the register set and how to communicate that extension between backend and frontend. Jan --------------enigC006C6F2944D4E2C72DFC78D 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 iEYEARECAAYFAkleDmkACgkQniDOoMHTA+miswCeJW/H4YUqmQBx8/Fphff/7Pgf iaEAnj6Wi2AKD5wdUsEhCjap0lGMgIpC =Ww7Y -----END PGP SIGNATURE----- --------------enigC006C6F2944D4E2C72DFC78D--