From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1L2aaK-00086U-5m
	for qemu-devel@nongnu.org; Tue, 18 Nov 2008 19:06:20 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1L2aaJ-000851-6A
	for qemu-devel@nongnu.org; Tue, 18 Nov 2008 19:06:19 -0500
Received: from [199.232.76.173] (port=47601 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1L2aaJ-00084u-2p
	for qemu-devel@nongnu.org; Tue, 18 Nov 2008 19:06:19 -0500
Received: from mail.codesourcery.com ([65.74.133.4]:35624)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1L2aaJ-0003UE-7o
	for qemu-devel@nongnu.org; Tue, 18 Nov 2008 19:06:19 -0500
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] Re: [PATCH v5 18/18] gdbstub: x86: Switch 64/32 bit
	registers dynamically
Date: Wed, 19 Nov 2008 00:06:14 +0000
References: <20081117161857.26880.45423.stgit@mchn012c.ww002.siemens.net>
	<200811182323.52357.paul@codesourcery.com>
	<492351D9.7000408@web.de>
In-Reply-To: <492351D9.7000408@web.de>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200811190006.14704.paul@codesourcery.com>
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: Jan Kiszka <jan.kiszka@web.de>

> > In the absence of real information gdb falls back to the current CPU
> > mode, which is a bit in the CPU status register. Exactly which
> > register/bit depends whether you're talking to an M-profile device.
> > M-profile cores are identified based on the XML register descriptions. If
> > you don't have an XML capable target then you don't get to debug
> > M-profile devices.
>
> ...and this surely doesn't map on x86 (yet): gdb has no clue at all
> about the CPU mode as it has no clue about segments or control registers.
>
> > IIRC There's also a gdb option to override the fallback mode.
>
> For x86, the core of the issue is a decoupled control of the gdb remote
> protocol and the disassembly mode. I guess I have to dig a bit in the
> code to see if the hard coupling we see in practice can be broken up.
> Not according to the command help I found so far.

This is sounding a lot like "we can't be bothered fixing gdb, so we're going 
to add ugly hacks to qemu instead". I don't find this a particularly 
convincing argument.

Paul