From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MBbyD-0002xU-BN for qemu-devel@nongnu.org; Tue, 02 Jun 2009 17:56:33 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MBby8-0002qM-F2 for qemu-devel@nongnu.org; Tue, 02 Jun 2009 17:56:32 -0400 Received: from [199.232.76.173] (port=35549 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MBby8-0002q8-B5 for qemu-devel@nongnu.org; Tue, 02 Jun 2009 17:56:28 -0400 Received: from mx20.gnu.org ([199.232.41.8]:4809) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MBby8-00039t-0i for qemu-devel@nongnu.org; Tue, 02 Jun 2009 17:56:28 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MBby7-0001Mn-05 for qemu-devel@nongnu.org; Tue, 02 Jun 2009 17:56:27 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH] fix gdbstub support for multiple threads in usermode, v2 Date: Tue, 2 Jun 2009 22:56:24 +0100 References: <1243972429-7972-1-git-send-email-froydnj@codesourcery.com> <200906022214.22865.paul@codesourcery.com> <20090602214828.GC21107@codesourcery.com> In-Reply-To: <20090602214828.GC21107@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906022256.24790.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Nathan Froyd Cc: qemu-devel@nongnu.org > > Could we use the real TID? Seems silly to invent a new value when the > > host has already found one for us... > > 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. Using threads for CPU emulation is just plain wrong. Paul