From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MBcie-00010D-UA for qemu-devel@nongnu.org; Tue, 02 Jun 2009 18:44:32 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MBcia-0000sM-77 for qemu-devel@nongnu.org; Tue, 02 Jun 2009 18:44:32 -0400 Received: from [199.232.76.173] (port=47494 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MBcia-0000sE-2l for qemu-devel@nongnu.org; Tue, 02 Jun 2009 18:44:28 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:51548) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MBciZ-0004KG-D5 for qemu-devel@nongnu.org; Tue, 02 Jun 2009 18:44:27 -0400 Message-ID: <4A25AB42.30709@web.de> Date: Wed, 03 Jun 2009 00:44:18 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1243972429-7972-1-git-send-email-froydnj@codesourcery.com> <200906022108.15384.paul@codesourcery.com> <20090602205440.GB21107@codesourcery.com> <200906022214.22865.paul@codesourcery.com> <20090602214828.GC21107@codesourcery.com> In-Reply-To: <20090602214828.GC21107@codesourcery.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9CEFC31734E76309AE90BE99" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [PATCH] fix gdbstub support for multiple threads in usermode, v2 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook , qemu-devel@nongnu.org, Nathan Froyd This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9CEFC31734E76309AE90BE99 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Nathan Froyd wrote: > On Tue, Jun 02, 2009 at 10:14:22PM +0100, Paul Brook wrote: >>>> Really? Why doesn't GDB get confused on real machines when the PID w= raps? >>>> Is the real bug that we're missing some sort of thread >>>> creation/destruction event reporting? >>> Hm, this is a good point. I think the bug is that: >>> ... >>> I'm also not sure what to do differently that doesn't involve making >>> QEMU remember what happened to all the threads it's seen until GDB as= ks >>> about them. Ideas? >> Ok, from Daniel's response it sounds like this bit of gdb is broken. >> >> Could we use the real TID? Seems silly to invent a new value when the = host has=20 >> already found one for us... >=20 > That would work for threaded usermode emulation. But for multiple-cpu > system-mode emulation, the CPUs are unlikely to have unique TID values > (e.g. r2 on powerpc or what have you). And if you're going to support > hotplugging someday, you're going to have support generation of unique > IDs somewhere along the way. Using the same code for usermode and > system mode seems like the better, more robust/future-proof option. For system-mode emulation, this is not that problematic. The threaded model assumes that all CPUs use the same memory mapping (for the code of interest at least) and are programmed with the same set of break/watchpoints. Pulling one and reinserting it will not require gdb to handle the newly plugged one differently within this model. Once we have a true multicore model for gdb and proper protocol extensions to handle more complex use cases, I bet we will also have a CPU hotplug event channel for gdb. Jan --------------enig9CEFC31734E76309AE90BE99 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 iEYEARECAAYFAkolq0gACgkQniDOoMHTA+kl9ACdFfw/jNuqdSyZ1aQYhE8bNnSg xfAAnR1LbSEUruMC2/xx/pCdHA383PhB =/Zdl -----END PGP SIGNATURE----- --------------enig9CEFC31734E76309AE90BE99--