From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26391 invoked by alias); 4 Dec 2007 18:17:07 -0000 Received: (qmail 26383 invoked by uid 22791); 4 Dec 2007 18:17:06 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 04 Dec 2007 18:17:01 +0000 Received: (qmail 18642 invoked from network); 4 Dec 2007 18:16:59 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 4 Dec 2007 18:16:59 -0000 To: Thiago Jung Bauermann Cc: Nathan Sidwell , gdb@sourceware.org Subject: Re: Non-stop multi-threaded debugging References: <4743178A.3050501@codesourcery.com> <1196455712.6746.160.camel@localhost.localdomain> From: Jim Blandy Date: Tue, 04 Dec 2007 18:17:00 -0000 In-Reply-To: <1196455712.6746.160.camel@localhost.localdomain> (Thiago Jung Bauermann's message of "Fri, 30 Nov 2007 18:48:32 -0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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-12/txt/msg00027.txt.bz2 Thiago Jung Bauermann writes: > That's great news. > I'm interested in seeing non-stop multi-thread debugging support working > in Linux and in having it usable via the command line interface, so I'm > willing to help in those areas (not sure how much work/test you'll be > doing in Linux, since you mention your focus is the client's OS). > > I'll keep an eye on the design discussions, and especially the "it would > be nice if someone would implement this" parts for Linux/CLI.. That sounds great! Here is my sketch of what would be needed for a CLI interface. Since it wasn't something Ericsson was interested in, I wasn't as careful to keep it up to date as the rest of the document changed, but hopefully it will still be useful. As with the MI commands, folks should read this as an attempt to mention the issues that need to be addressed, not as a fully worked-out design. If there are things that seem clumsy, and you think you have a better idea, you're probably right. P10) Non-stop debugging via the command-line interface This project makes non-stop multi-threaded debugging available via the GDB command-line interface. This was not a stated Ericsson requirement. It builds on P1. An IDE using a graphical user interface can support non-stop multi-threaded debugging in a natural way. A command-line interface, however, encounters some challenges: - One of the attractive characteristics of a non-stop debugger is that the debugger is always ready to respond to the user, regardless of what the debuggee is doing. However, commands like 'stop', 'next' and 'finish' traditionally indicate that the operation has completed simply by withholding the command prompt until that point. - In non-stop debugging, events of interest to the user may occur in the debuggee's running threads while the user is inspecting a stopped thread. Because a command-line interface cannot segregate event notifications and user interaction in separate areas of the display the way a GUI can, a flood of events in the debuggee can obscure the results of prior commands and make it difficult for the user to make headway. The following changes would allow GDB to support non-stop debugging on the command line in a way that addresses those problems: - The CLI shall provide commands to switch between all-stop mode (the current behavior) and non-stop mode. - The CLI 'info threads' command shall indicate, for each thread, whether it is currently stopped or running. The information displayed for running threads may be limited. - Selecting any thread shall cause that thread to stop. - When a thread encounters a breakpoint or a fault, GDB shall stop only that thread. Any other running threads shall continue to execute. - Resumption commands like 'step' and 'finish' shall affect only the selected thread; any other stopped threads will remain stopped. The CLI shall not prompt the user for a new command until the operation completes, or an event occurs in any thread, or the user sends an interrupt to the terminal. (This allows the presence of the prompt to continue to indicate when a command has completed, as it does in all-stop mode.) - The CLI's 'continue' command shall print a message indicating that threads are running, and then immediately prompt the user for the next command. - At a given command prompt, the CLI shall display only a limited number of lines of event notifications. If the limit has been reached and more events occur, the CLI will display a final message indicating that further events are available to report, and explain briefly what the user must do to see them. - Sending an interrupt to the terminal at any time shall cause the CLI to prompt the user for a new command, but shall not stop any threads. The CLI shall print a message to this effect, explaining briefly how the user may stop all threads if needed. - The CLI shall provide commands to stop all threads, and to continue all threads.