From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13865 invoked by alias); 29 Apr 2002 15:32:45 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 13840 invoked from network); 29 Apr 2002 15:32:40 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 29 Apr 2002 15:32:40 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 172D98-0002CD-00; Mon, 29 Apr 2002 11:32:58 -0400 Date: Mon, 29 Apr 2002 08:32:00 -0000 From: Daniel Jacobowitz To: John Whitney Cc: gdb@sources.redhat.com Subject: Re: GDB and multithreaded gdbserver Message-ID: <20020429113258.B8170@nevyn.them.org> Mail-Followup-To: John Whitney , gdb@sources.redhat.com References: <001201c1ef8a$2740ad80$6b02a8c0@Starfish> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001201c1ef8a$2740ad80$6b02a8c0@Starfish> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-04/txt/msg00483.txt.bz2 On Mon, Apr 29, 2002 at 10:28:37AM -0400, John Whitney wrote: > Hello, > > I am investigating writing a multithreaded gdbserver for linux (only, > because I am doing away with thread_db), and had some implementation/remote > protocol questions: Before you go down this path, John, I should tell you that I've got the work entirely finished now. I have another couple days of legal legwork, but I hope to be posting the code (or at least the first step, which requires two small changes to the remote protocol) by the end of the week. > 1. What is the algorithm for stepping/continuing threads? It *appears* to > be something like the following: > When continuing a thread, continue ALL threads (and/or report interesting > signals stopping another thread already). When stepping a thread, step ONLY > the current thread and don't report interesting signals on other threads > until switched to them or this thread is continued. Is there any way to > step all (or some) threads at the same time? Look at general_thread and cont_thread. If cont_thread is 0, and a step command is received, you step one thread and continue all the others. Single-stepping multiple threads in lockstep isn't supported, but it's really not very useful... we'd need to extend the protocol further to support that. One of the protocol extensions I mentioned allows specifying -which- thread to singlestep when cont_thread is 0. > 2. I've seen some postings about not being able to report thread deaths, but > I haven't yet been able to determine if this is a thread_db limitation or a > protocol limitation. If it is a thread_db limitation, what is the correct > procedure to report a thread death (a W status seems to be interpreted by > GDB as death of the inferior in general and causes it to stop debugging)? In the context you've seen it mentioned, it is a limitation of a buggy version of thread_db. In glibc 2.2.x, this works fine, but isn't especially necessary. It is also a limitation of the remote protocol; my other protocol extension was thread death notification :) > 3. What's the proper response to the qfThreadInfo request? Based on > Subhashini's (I think?) gdbserver document, it looks like this should be > answered with an OK packet, and the server should expect a qsThreadInfo > request to actually retrieve this information. However, using GDB5.1.1, I > never see a qsThreadInfo request, so I am assuming this is a design > suggestion and not the way it is currently implemented. If that is indeed > the case, what IS the proper response to this packet? Not an OK, a single (or multiple) thread ID ('m' packet). I just do one instead of fitting as many in the buffer as possible, but I'll fix that after it's merged; it's a minor performance improvement. > 4. I guess most importantly, is there a document describing the remote > protocol? I've looked at the one referenced on Dan Kegel's site (Quality > Quorum's document), but it seems a bit out-of-date. Some things I've > figured out by looking at remote.c in the GDB source, but that is a bit > cumbersome. It's in the GDB Texinfo manual, node "Remote Serial Protocol". -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer