From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8882 invoked by alias); 28 Nov 2007 05:18:56 -0000 Received: (qmail 8870 invoked by uid 22791); 28 Nov 2007 05:18:54 -0000 X-Spam-Check-By: sourceware.org Received: from mail.windriver.com (HELO mail.wrs.com) (147.11.1.11) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 28 Nov 2007 05:18:46 +0000 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id lAS5IiUS024315 for ; Tue, 27 Nov 2007 21:18:44 -0800 (PST) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 21:18:44 -0800 Received: from [147.11.233.35] ([147.11.233.35]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 21:18:44 -0800 Message-ID: <474CFA34.1030309@windriver.com> Date: Wed, 28 Nov 2007 05:18:00 -0000 From: Pawel Piech User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: gdb@sourceware.org Subject: Re: Non-stop multi-threaded debugging Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-11/txt/msg00253.txt.bz2 Hello, I am collaborating with Ericsson on implementing GDB support in Eclipse and I'm very much looking forward to seeing this functionality implemented in GDB. With the Eclipse use of the MI protocol in mind I have a couple of comments and questions on the proposal: > P1) Non-stop multi-threaded native debugging > - The MI '-exec-interrupt' command shall stop all threads. This > will always generate an 'EXEC-ASYNC-OUTPUT' record, even if all > threads were already stopped. (This helps users handle the case > where the thread stops of its own accord just as the user sends > it an '-exec-interrupt' command.) > > - The MI '-thread-select' command shall stop the thread selected, > if it is running. The previously selected thread is left in its > former state, either stopped or running. A '-thread-select' > command shall always generate an 'EXEC-ASYNC-OUTPUT' record, > even if the thread was already stopped. I think using -thread-select to suspend a thread will have negative consequences to the MI-client. The -thread-select is used to change the protocol state before requesting data related to that thread. Adding the side-effect of suspending the thread, will force the client to add additional logic to avoid suspending threads accidentally as a result of attempting to read data. I think it would be much safer to use an explicit -exec-interrupt request (after a -thread-select) to suspend a thread. Note that either way GDB will have to handle and return an errors to requests for data (such as stack or expressions) while a selected thread is running. If a client sends a -exec-continue, I assume that whatever thread was selected last will still be selected. So a -stack-list-frames should result in an error. > P7) Non-stop multi-threaded multi-process native debugging > - MI shall provide a command to stop all the threads in a given > process, and a command to resume all stopped threads in a given > process. I would like to make a suggestion here. Instead of inventing a new set of parallel commands and events to deal with process-wide events, it would be cleaner to simply assign thread IDs to processes and use existing commands and events to operate on them. A -thread-select on an ID of a process followed by an -exec-continue would resume an entire process, while a -thread-select of a thread's ID followed by a continue would resume only that thread. This could also be applied to all other commands that need to operate on a process, such as -thread-list-ids, -break-insert, etc. While events could also be re-used to report without any changes to the event format, it would be very helpful for the client if the events included both the process's and thread's thread ID, as well as whether all threads stopped as the result of the event: ... -thread-select 2 ^done -exec-interrupt *stopped, thread-id="2", process-thread-id="1", all-threads="false", .... ^done ... -thread-select 1 ^done -exec-continue ^running, thread-id="1", process-thread-id="1", all-threads="true" ... Cheers, Pawel