From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MBasH-0003JN-Vd for qemu-devel@nongnu.org; Tue, 02 Jun 2009 16:46:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MBasD-0003E4-1V for qemu-devel@nongnu.org; Tue, 02 Jun 2009 16:46:21 -0400 Received: from [199.232.76.173] (port=43313 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MBasC-0003Dr-S6 for qemu-devel@nongnu.org; Tue, 02 Jun 2009 16:46:16 -0400 Received: from nan.false.org ([208.75.86.248]:50019) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MBasC-0001Za-C8 for qemu-devel@nongnu.org; Tue, 02 Jun 2009 16:46:16 -0400 Date: Tue, 2 Jun 2009 16:46:09 -0400 From: Daniel Jacobowitz Subject: Re: [Qemu-devel] [PATCH] fix gdbstub support for multiple threads in usermode, v2 Message-ID: <20090602204609.GA20952@caradoc.them.org> References: <1243972429-7972-1-git-send-email-froydnj@codesourcery.com> <200906022108.15384.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906022108.15384.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, Nathan Froyd On Tue, Jun 02, 2009 at 09:08:14PM +0100, Paul Brook wrote: > On Tuesday 02 June 2009, Nathan Froyd wrote: > > When debugging multi-threaded programs, QEMU's gdb stub would report the > > 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: > > > > initial thread created > > new thread #1 > > new thread #2 > > thread #1 exits > > new thread #3 > > > > thread #3 will have the same cpu_index as thread #1, which would confuse > > GDB. > > Really? Why doesn't GDB get confused on real machines when the PID wraps? It would, if using gdbserver and no one had done 'info threads' in between. > Is the real bug that we're missing some sort of thread creation/destruction > event reporting? The remote protocol doesn't have creation/destruction events (yet; it's a known limitation). -- Daniel Jacobowitz CodeSourcery