This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Non-stop multi-threaded debugging
- From: Jim Blandy <jimb at codesourcery dot com>
- To: Thiago Jung Bauermann <bauerman at br dot ibm dot com>
- Cc: Nathan Sidwell <nathan at codesourcery dot com>, gdb at sourceware dot org
- Date: Tue, 04 Dec 2007 10:16:59 -0800
- Subject: Re: Non-stop multi-threaded debugging
- References: <4743178A.3050501@codesourcery.com> <1196455712.6746.160.camel@localhost.localdomain>
Thiago Jung Bauermann <bauerman at br.ibm.com> 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.