From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M6SZh-0005OB-Cj for qemu-devel@nongnu.org; Tue, 19 May 2009 12:53:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M6SZc-0005GZ-Cd for qemu-devel@nongnu.org; Tue, 19 May 2009 12:53:56 -0400 Received: from [199.232.76.173] (port=48810 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M6SZc-0005GO-7O for qemu-devel@nongnu.org; Tue, 19 May 2009 12:53:52 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]:36218) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M6SZb-0003Ei-IQ for qemu-devel@nongnu.org; Tue, 19 May 2009 12:53:51 -0400 Received: from smtp07.web.de (fmsmtp07.dlan.cinetic.de [172.20.5.215]) by fmmailgate01.web.de (Postfix) with ESMTP id 3B4E0102BD277 for ; Tue, 19 May 2009 18:53:49 +0200 (CEST) Received: from [87.230.10.181] (helo=[139.25.109.167]) by smtp07.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #277) id 1M6SZY-0003bU-00 for qemu-devel@nongnu.org; Tue, 19 May 2009 18:53:49 +0200 Message-ID: <4A12E418.4040403@web.de> Date: Tue, 19 May 2009 18:53:44 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1242156943-27850-1-git-send-email-froydnj@codesourcery.com> <4A09E1C2.9020302@web.de> <20090519150636.GA23911@codesourcery.com> In-Reply-To: <20090519150636.GA23911@codesourcery.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig333E164F5134DAA2A9C6A35F" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [PATCH] fix gdbstub support for multiple threads in usermode List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig333E164F5134DAA2A9C6A35F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Nathan Froyd wrote: > On Tue, May 12, 2009 at 10:53:22PM +0200, Jan Kiszka wrote: >> Nathan Froyd wrote: >>> We fix this by adding a stable gdbstub_index field for each CPU; the >>> index is incremented for every CPU (thread) created. We ignore >>> wraparound issues for now. Once we have this field, the stub needs t= o >>> use this field instead of cpu_index for communicating with GDB. >>> [...] >>> @@ -554,6 +556,7 @@ void cpu_exec_init(CPUState *env) >>> cpu_index++; >>> } >>> env->cpu_index =3D cpu_index; >>> + env->gdbstub_index =3D ++next_gdbstub_index; >> While this is simple and sufficient for most cases, making >> next_gdbstub_index robust against collisions due to overflow is not mu= ch >> more complicated - so why not do this right from the beginning? >=20 > We could just make it a 64-bit field. :) Well... kind of pragmatic. >=20 > The best way I can think of to do this is to maintain a > separately-chained list of CPUStates (through a new field similar to > next_cpu) ordered by gdbstub_index. Grabbing a new gdbstub_index then > walks through the list, looking for "holes" between adjacent entries in= > the list. A new gdbstub_index is then picked if we find a hole; we die= > if we can't find a hole. Why creating a new list? Just generate a new index and then walk through all so far registered CPUStates until no collision is found. >=20 > Is this what you had in mind, or am I not being clever enough? >=20 >> I don't think we need these #ifdefs here. You assign continuously >> increasing IDs also to system-mode CPUs, so we can handle them >> identically (we have to anyway once cpu hotplugging hits upstream). >=20 > Will fix, thanks. >=20 >> Hmm, I bet you now have some use for my good-old vCont patch (=3D>cont= inue >> single-stepping on different CPU / in different thread). Will repost s= oon. >=20 > Yes, I think that would be useful. On my todo list. I practically just need to include your patch in my queu= e. Jan --------------enig333E164F5134DAA2A9C6A35F 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 iEYEARECAAYFAkoS5BwACgkQniDOoMHTA+nRXQCfV3n+fNlEyuZoiqsjZhYx8UQT qLYAn03Wwy3Ej41KsVmATlrxxqY1oVxk =Ssva -----END PGP SIGNATURE----- --------------enig333E164F5134DAA2A9C6A35F--