From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L2a9p-0006CO-8e for qemu-devel@nongnu.org; Tue, 18 Nov 2008 18:38:57 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L2a9m-0006BO-Bl for qemu-devel@nongnu.org; Tue, 18 Nov 2008 18:38:56 -0500 Received: from [199.232.76.173] (port=51883 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L2a9m-0006BJ-8X for qemu-devel@nongnu.org; Tue, 18 Nov 2008 18:38:54 -0500 Received: from fmmailgate02.web.de ([217.72.192.227]:49549) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L2a9m-0001KY-9U for qemu-devel@nongnu.org; Tue, 18 Nov 2008 18:38:54 -0500 Message-ID: <492351D9.7000408@web.de> Date: Wed, 19 Nov 2008 00:38:01 +0100 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH v5 18/18] gdbstub: x86: Switch 64/32 bit registers dynamically References: <20081117161857.26880.45423.stgit@mchn012c.ww002.siemens.net> <200811182246.54653.paul@codesourcery.com> <49234ABB.90303@web.de> <200811182323.52357.paul@codesourcery.com> In-Reply-To: <200811182323.52357.paul@codesourcery.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig65B9A38FE9C49018E3EBBF52" 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: Paul Brook Cc: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig65B9A38FE9C49018E3EBBF52 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Paul Brook wrote: > On Tuesday 18 November 2008, Jan Kiszka wrote: >> Paul Brook wrote: >>>> The best approach, definitely, would be to teach GDB how to switch t= he >>>> disassembler mode depending on the thread's (or VCPUs) state. But so= >>>> there is neither a mechanism in GDB for this, nor is GDB even aware = of >>>> the x86 modes (no tracking of privileged registers). We have some >>>> preliminary patches for this, but they are still far away from GDB >>>> mainline. >>> I'm pretty sure all the infrastructure is there. gdb is able to nativ= ely >>> debug 32-bit binaries on a 64-bit host and is able to switch disassem= bler >>> modes for ARM vs. Thumb. >> How is it done on ARM? Maybe that will provide the right pointer for x= 86. >=20 > Anything you have symbols for you know what type of code it is from the= =20 > binary. On ARM there's an EABI defined scheme for identifying arm/thumb= /data=20 > regions. On x86 the ELF class of the image is probably sufficient. ELF-based detection can only work as good the underlying 'raw' switching works. >=20 > In the absence of real information gdb falls back to the current CPU mo= de,=20 > which is a bit in the CPU status register. Exactly which register/bit d= epends=20 > whether you're talking to an M-profile device. M-profile cores are iden= tified=20 > based on the XML register descriptions. If you don't have an XML capabl= e=20 > target then you don't get to debug M-profile devices. =2E..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.= >=20 > 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. Jan --------------enig65B9A38FE9C49018E3EBBF52 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 iEYEARECAAYFAkkjUd8ACgkQniDOoMHTA+kc0wCeJxR1A9QkQ6qfJBvnn62ocWZI ljgAn38zsV2T1jC7Sl0oc5nEwNWf+y57 =Mqww -----END PGP SIGNATURE----- --------------enig65B9A38FE9C49018E3EBBF52--