From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MBb0T-0003um-Pl for qemu-devel@nongnu.org; Tue, 02 Jun 2009 16:54:49 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MBb0P-0003pg-JC for qemu-devel@nongnu.org; Tue, 02 Jun 2009 16:54:49 -0400 Received: from [199.232.76.173] (port=50836 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MBb0P-0003p7-4s for qemu-devel@nongnu.org; Tue, 02 Jun 2009 16:54:45 -0400 Received: from mx20.gnu.org ([199.232.41.8]:1692) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MBb0O-00038E-Qz for qemu-devel@nongnu.org; Tue, 02 Jun 2009 16:54:44 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MBb0M-0006QL-RD for qemu-devel@nongnu.org; Tue, 02 Jun 2009 16:54:43 -0400 Date: Tue, 2 Jun 2009 13:54:40 -0700 From: Nathan Froyd Subject: Re: [Qemu-devel] [PATCH] fix gdbstub support for multiple threads in usermode, v2 Message-ID: <20090602205440.GB21107@codesourcery.com> 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 On Tue, Jun 02, 2009 at 09:08:14PM +0100, Paul Brook wrote: > On Tuesday 02 June 2009, Nathan Froyd wrote: > > 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? > 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: 1) gdb_exit, called at thread exit, just blasts out a 'W' packet, when such a packet is really only defined to be sent in response to a '?' packet. If I understand gdb's remote.c correctly, an unrequested 'W' packet is just going to get dropped on the floor. This behavior is probably part of the reason GDB never sees threads die until it queries the target again, along with... 2) The response to a '?' packet is, well, not smart: case '?': /* TODO: Make this return the correct value for user-mode. */ snprintf(buf, sizeof(buf), "T%02xthread:%02x;", GDB_SIGNAL_TRAP, s->c_cpu->cpu_index+1); put_packet(s, buf); which is, um, inaccurate. I'm assuming that GDB handles wrapping PIDs correctly...it's possible that it doesn't. (For instance: GDB has PIDs 12 and 14 GDB runs the target PID 12 exits (I don't think a status notification gets sent here) PID 12 gets reused by the process (no status notification here, either?) target stops GDB sees PID 12 still present but I am not a Linux target GDB expert.) 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? -Nathan