From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LIvhW-0003pY-I6
	for qemu-devel@nongnu.org; Fri, 02 Jan 2009 20:53:18 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LIvhT-0003pL-Rg
	for qemu-devel@nongnu.org; Fri, 02 Jan 2009 20:53:18 -0500
Received: from [199.232.76.173] (port=44160 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LIvhT-0003pI-NC
	for qemu-devel@nongnu.org; Fri, 02 Jan 2009 20:53:15 -0500
Received: from mail2.shareable.org ([80.68.89.115]:50301)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <jamie@shareable.org>) id 1LIvhT-0008EE-5L
	for qemu-devel@nongnu.org; Fri, 02 Jan 2009 20:53:15 -0500
Date: Sat, 3 Jan 2009 01:53:07 +0000
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: [Qemu-devel] Re: gdbstub: packet reply is too long
Message-ID: <20090103015307.GA1927@shareable.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <495E0E65.9040205@web.de>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: Andreas Schultz <aschultz@warp10.net>, Paul Brook <paul@codesourcery.com>, kvm@vger.kernel.org

Jan Kiszka wrote:
> 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 != 0 (or if it's CS >> 4, ie. you are in real
> mode).

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.

-- Jamie