From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MBbqY-0002TK-SO for qemu-devel@nongnu.org; Tue, 02 Jun 2009 17:48:38 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MBbqS-0002Lb-JW for qemu-devel@nongnu.org; Tue, 02 Jun 2009 17:48:38 -0400 Received: from [199.232.76.173] (port=52214 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MBbqS-0002L0-4z for qemu-devel@nongnu.org; Tue, 02 Jun 2009 17:48:32 -0400 Received: from mx20.gnu.org ([199.232.41.8]:4486) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MBbqR-0001hd-Mm for qemu-devel@nongnu.org; Tue, 02 Jun 2009 17:48:31 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MBbqQ-0000zS-AH for qemu-devel@nongnu.org; Tue, 02 Jun 2009 17:48:30 -0400 Date: Tue, 2 Jun 2009 14:48:28 -0700 From: Nathan Froyd Subject: Re: [Qemu-devel] [PATCH] fix gdbstub support for multiple threads in usermode, v2 Message-ID: <20090602214828.GC21107@codesourcery.com> References: <1243972429-7972-1-git-send-email-froydnj@codesourcery.com> <200906022108.15384.paul@codesourcery.com> <20090602205440.GB21107@codesourcery.com> <200906022214.22865.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906022214.22865.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org 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 wraps? > > > 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 asks > > 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 > 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. -Nathan