From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MBwKV-0001Wz-JY for qemu-devel@nongnu.org; Wed, 03 Jun 2009 15:40:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MBwKR-0001Rk-5v for qemu-devel@nongnu.org; Wed, 03 Jun 2009 15:40:55 -0400 Received: from [199.232.76.173] (port=52602 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MBwKQ-0001Rh-U7 for qemu-devel@nongnu.org; Wed, 03 Jun 2009 15:40:50 -0400 Received: from fmmailgate03.web.de ([217.72.192.234]:38104) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MBwKQ-0005AM-Cr for qemu-devel@nongnu.org; Wed, 03 Jun 2009 15:40:50 -0400 Message-ID: <4A26D1C0.80701@web.de> Date: Wed, 03 Jun 2009 21:40:48 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1244053988-14307-1-git-send-email-froydnj@codesourcery.com> In-Reply-To: <1244053988-14307-1-git-send-email-froydnj@codesourcery.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4F52E7ABDEE86AC54502C0D7" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [PATCH] fix gdbstub support for multiple threads in usermode, v3 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Nathan Froyd Cc: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4F52E7ABDEE86AC54502C0D7 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Nathan Froyd wrote: > When debugging multi-threaded programs, QEMU's gdb stub would report th= e > correct number of threads (the qfThreadInfo and qsThreadInfo packets). > However, the stub was unable to actually switch between threads (the T > packet), since it would report every thread except the first as being > dead. Furthermore, the stub relied upon cpu_index as a reliable means > of assigning IDs to the threads. This was a bad idea; if you have this= > sequence of events: >=20 > initial thread created > new thread #1 > new thread #2 > thread #1 exits > new thread #3 >=20 > thread #3 will have the same cpu_index as thread #1, which would confus= e > GDB. (This problem is partly due to the remote protocol not having a > good way to send thread creation/destruction events.) >=20 > We fix this by using the host thread ID for the identifier passed to GD= B > when debugging a multi-threaded userspace program. The thread ID might= > wrap, but the same sort of problems with wrapping thread IDs would come= > up with debugging programs natively, so this doesn't represent a > problem. > --- > cpu-defs.h | 1 + > exec.c | 2 +- > gdbstub.c | 69 +++++++++++++++++++++++++++++++-----------= ------- > linux-user/syscall.c | 4 ++- > 4 files changed, 49 insertions(+), 27 deletions(-) >=20 > Changes from earlier versions: use the host thread ID as the unique ID > to pass to GDB instead of inventing a new ID that tries to be robust > against wrapping. Looks good to me, has additionally some nice cleanup aspects, and survived a quick regression test in system mode. Jan --------------enig4F52E7ABDEE86AC54502C0D7 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 iEYEARECAAYFAkom0cAACgkQniDOoMHTA+kKAQCfSAtaPiyAForFtzbD+1xeXYR8 25wAn0xevQpWQsX0incm7nPgos+WGKuJ =rv1i -----END PGP SIGNATURE----- --------------enig4F52E7ABDEE86AC54502C0D7--