Re: Non-stop multi-threaded debugging

[Jim Blandy <jimb@codesourcery.com>]

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.