From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31939 invoked by alias); 29 Apr 2002 14:29:26 -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 31613 invoked from network); 29 Apr 2002 14:28:55 -0000 Received: from unknown (HELO exchange.timesys.com) (12.147.203.19) by sources.redhat.com with SMTP; 29 Apr 2002 14:28:55 -0000 Received: from Starfish ([65.117.135.98]) by exchange.timesys.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 29 Apr 2002 10:18:55 -0400 Message-ID: <001201c1ef8a$2740ad80$6b02a8c0@Starfish> From: "John Whitney" To: Subject: GDB and multithreaded gdbserver Date: Mon, 29 Apr 2002 07:29:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 29 Apr 2002 14:18:55.0546 (UTC) FILETIME=[CBB741A0:01C1EF88] X-SW-Source: 2002-04/txt/msg00481.txt.bz2 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: 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? 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)? 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? 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. Thank you for any help, John Whitney john.whitney@timesys.com