From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M6Qtv-0000ca-40 for qemu-devel@nongnu.org; Tue, 19 May 2009 11:06:43 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M6Qtq-0000Zm-IT for qemu-devel@nongnu.org; Tue, 19 May 2009 11:06:42 -0400 Received: from [199.232.76.173] (port=36700 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M6Qtq-0000Zg-7z for qemu-devel@nongnu.org; Tue, 19 May 2009 11:06:38 -0400 Received: from mx20.gnu.org ([199.232.41.8]:17402) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1M6Qtp-0006o9-Sh for qemu-devel@nongnu.org; Tue, 19 May 2009 11:06:38 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M6Qtp-0003Iv-6Q for qemu-devel@nongnu.org; Tue, 19 May 2009 11:06:37 -0400 Date: Tue, 19 May 2009 08:06:36 -0700 From: Nathan Froyd Message-ID: <20090519150636.GA23911@codesourcery.com> References: <1242156943-27850-1-git-send-email-froydnj@codesourcery.com> <4A09E1C2.9020302@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A09E1C2.9020302@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: Jan Kiszka Cc: qemu-devel@nongnu.org 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 to > > 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 = cpu_index; > > + env->gdbstub_index = ++next_gdbstub_index; > > While this is simple and sufficient for most cases, making > next_gdbstub_index robust against collisions due to overflow is not much > more complicated - so why not do this right from the beginning? We could just make it a 64-bit field. :) 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. Is this what you had in mind, or am I not being clever enough? > 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). Will fix, thanks. > Hmm, I bet you now have some use for my good-old vCont patch (=>continue > single-stepping on different CPU / in different thread). Will repost soon. Yes, I think that would be useful. -Nathan