From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LJTNG-0004Bv-Cn for qemu-devel@nongnu.org; Sun, 04 Jan 2009 08:50:38 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LJTNE-0004BX-NJ for qemu-devel@nongnu.org; Sun, 04 Jan 2009 08:50:37 -0500 Received: from [199.232.76.173] (port=42779 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LJTNE-0004BT-Hz for qemu-devel@nongnu.org; Sun, 04 Jan 2009 08:50:36 -0500 Received: from fmmailgate02.web.de ([217.72.192.227]:44611) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LJTND-0006TG-7z for qemu-devel@nongnu.org; Sun, 04 Jan 2009 08:50:36 -0500 Message-ID: <4960BE9A.3010603@web.de> Date: Sun, 04 Jan 2009 14:50:18 +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> <495E0E65.9040205@web.de> <20090103015307.GA1927@shareable.org> In-Reply-To: <20090103015307.GA1927@shareable.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC4D47BEAE9A19368BE082D61" 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: Jamie Lokier Cc: Andreas Schultz , Paul Brook , qemu-devel@nongnu.org, kvm@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC4D47BEAE9A19368BE082D61 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jamie Lokier wrote: > Jan Kiszka wrote: >> You need CR0.PE to detect if you are in real or protected mode. And th= en >> you need GDTR/LDTR to find the descriptor CS is pointing at, parsing i= t >> 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). >=20 > If you're going to decode segment descriptors (great idea, btw, and > helpful for threaded code), it might be better to supply the CPU's > internal segment state, if that's possible, instead of looking at the > LDT/GDT in memory, since the CPU's state can differ from the memory > version when the latter is written to. Good point. I included this in an initial suggestion of an extended register set, see [1]. Providing this information will likely remain VM-business, but that doesn't mean we shouldn't use it when available. Jan [1] http://sourceware.org/ml/gdb/2009-01/msg00008.html --------------enigC4D47BEAE9A19368BE082D61 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 iEYEARECAAYFAklgvpoACgkQniDOoMHTA+mEwgCfRZhBamDBww16P34qL7rTPD52 FBAAnj1EBhGVB0Td9IQriy/8NGDNXyYc =jSoi -----END PGP SIGNATURE----- --------------enigC4D47BEAE9A19368BE082D61--