From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L2ZDh-0005ZU-4a for qemu-devel@nongnu.org; Tue, 18 Nov 2008 17:38:53 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L2ZDg-0005ZI-An for qemu-devel@nongnu.org; Tue, 18 Nov 2008 17:38:52 -0500 Received: from [199.232.76.173] (port=36047 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L2ZDg-0005ZF-4X for qemu-devel@nongnu.org; Tue, 18 Nov 2008 17:38:52 -0500 Received: from fmmailgate01.web.de ([217.72.192.221]:37195) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L2ZDg-0004l9-16 for qemu-devel@nongnu.org; Tue, 18 Nov 2008 17:38:52 -0500 Message-ID: <492343C2.8080604@web.de> Date: Tue, 18 Nov 2008 23:37:54 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <20081117161857.26880.45423.stgit@mchn012c.ww002.siemens.net> <20081117161859.26880.70678.stgit@mchn012c.ww002.siemens.net> <492334B9.3010705@codemonkey.ws> <49233776.9050504@codemonkey.ws> In-Reply-To: <49233776.9050504@codemonkey.ws> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig708266E0FC7456B916F079D8" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [PATCH v5 18/18] gdbstub: x86: Switch 64/32 bit registers dynamically Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Paul Brook This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig708266E0FC7456B916F079D8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Anthony Liguori wrote: > Anthony Liguori wrote: >> Jan Kiszka wrote: >>> Commit 5459 broke gdbstub's dynamic register set switching between >>> x86-64 and i386. That prevents setting the correct architecture in gd= b >>> when debugging 32 or 16-bit code in a 64-bit emulator. This patch >>> reintroduces the feature over previous refactorings. >>> =20 >> >> How does this interact with SMP? If you have one VCPU in 32-bit mode >> and another in 64-bit mode, won't that confuse GDB? Each mode switch already confuses GDB: Either you see borken disassembly and are unable to match what you see with your source code, or you manually have to issue 'set arch ...' when you switch between CPUs in different addressing modes. Fortunately, the latter is not a very common case, at least to my experience. The best approach, definitely, would be to teach GDB how to switch the 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 mainli= ne. >=20 > After talking to Paul in IRC, it seems that GDB is going to make > assumptions that all threads share an address space and potentially > cache memory accesses or at least be sloppy with how it does memory > accesses. >=20 > I think this is a pretty strong argument for using fork instead of > threads. I would think you should be able to provoke this pretty easil= y > with an SMP guest. As I explained in another reply, this is not the primary use case for the gdbstub as I see it. However, I'm open to learn how fork could help us while keeping the usability we now have via threads plus opening more of the guest code for this kind of debugging (though I don't see a need for the latter - yet). Jan --------------enig708266E0FC7456B916F079D8 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 iEYEARECAAYFAkkjQ80ACgkQniDOoMHTA+kXNQCfYnGjnO5xSyoQz12WCS1WMjGb mEwAnjR1ZX2mtJDuFa/2NP5n+8dorfj9 =ivmh -----END PGP SIGNATURE----- --------------enig708266E0FC7456B916F079D8--