Jump to: navigation, search


This sub-group is focused on improving the workflow of multi-context debugging. Multi-context refers to simultaneous debugging of multiple cores, processes, threads, or other objects which are represented in standard debugger views. This sub-group was created following a discussion about platform debug dev: "ideas for improving multi-context debugging". The first document produced by this group was Unlink View Context proposal, this document is now deprecated and the current effort is organized around this wiki page being created by the community interested in this problem.

Use cases

Use cases to be considered when evaluating the multi-context debugging workflow.


  • Family of use cases
    Use case 
    Description of the use case
    • Step

  • 1) Programs with multiple threads
    1.1) Two or more threads interacting 
    User is debugging a program with multiple threads which are interacting with each other.
    1.1.1) Debugging threads which contend for the same lock. 
    1. When a thread blocks while stepping,
    2. User switches focus to another thread and steps until the lock is released,
    3. User switches focus back to the first thread and continues debugging.
    1.1.2) Debugging race conditions where multiple threads are reading and writing some shared data 
    1. User sets a breakpoint at a location where a shared variable is written.
    2. Multiple threads hit the breakpoint
    3. User looks at each threads to see the thread-private data in each thread.
    4. User steps the threads individually to watch what happens to the shared data.
    5. Alternatively, user steps all threads.
    6. Multiple threads may hit the breakpoint at the same time.
    7. User sets another breakpoint further down in routines that access the shared data.
    8. User continues some or all of the threads which stopped at the first breakpoint so that they may reach the second breakpoint.
    1.2) Debugging a subset of threads 
    User is debugging a program with multiple threads, but he is interested only in interacting with some of the threads.
    1.2.1) User debugs with breakpoints restricted to a sub-set of threads.
    1. User creates a breakpoint on the routine to be debugged.
    2. User defines which threads should be allowed to hit the breakpoint.
    3. The threads hit the breakpoint and user steps through them.
    1.2.2) Run control for a subset of threads 
    User repeatedly suspends and resumes a subset of threads.
    1.2.3) Terminating/re-launching 
    1. User debugs a subset of threads (using filtered breakpoints, etc.).
    2. User terminates and relaunches a process, and continues to debug the same set of threads.
    1.2.4) Tasks submitted to a thread pool 
    User is debugging a routine which may be executed by any thread in a thread pool at any time, and by some threads in the thread pool at the same time.
    1. User sets a breakpoint and a number of threads hit the breakpoint, user examines the data and resumes threads individually.
    2. User sets a conditional breakpoint where the condition is used to identify a specific tasks. For example, an instance of an update object when debugging flexible hierarchy views.
    1.3) Program with large number (100+) of threads 
    User is debugging programs with large numbers of threads and he needs to manage those threads effectively.
    1.3.1) User needs to switch between suspended threads
    1. User sets a breakpoint that some threads may hit.
    2. Some threads hit the breakpoint.
    3. User switches focus between suspended threads to control them and examine their data.
    1.3.2) Threads created/destroyed rapidly
    User is debugging a process with threads being created and destroyed at a rapid rate (more than 1 thread/sec.)
  • 2) Multiple processes that interact with each other
    2.1) Launching multiple processes at the same time 
    When starting a debug session, user creates multiple processes and debugs them.
    2.2) Attaching to multiple processes 
    Instead of launching, user attaches to multiple processes and debugs them simultaneously.
    2.3) Debugging a process that forks 
    User is debugging a process that forks. After the fork user debugs both processes.
  • 3) Systems with multiple cores (On Chip Debugging)
    3.1) Hardware bring-up debugging 
    User attaches a debugger to a multi-core system for purpose of hardware configuration, such as configuring registers, IO devices, etc. (no OS, no symbol data, no executable image)
    3.2) No-OS debugging 
    User attaches to a multi-core system and downloads simple executable image to each core and debugs them.
    3.3) Debugging with OS-awareness 
    User attaches to a multi-core system, downloads an OS image to each, starts debugging the entire OS on each board, or specific tasks/processes running on specific cores.

Problems with workflow

Issues with the user experience when executing the above use cases.

  • A) (1.1) There is no way to get the debugger to focus on more than one context at a time. It is true that multiple workbench windows can be opened, but splitting the whole screen between the two windows is not practical.
    • A.a) There is no simple way to compare data (variables, registers, memory,etc) from multiple contexts
  • B) (all) Switching between contexts requires that the Debug view be visible. The Debug view takes a lot of screen space which could be used to view code or other program data.
  • C) (1.1.2) If two instruction pointers are shown in the same editor, there is no way to distinguish which IP belongs to which context.
  • D) (all) It is difficult to specify and manage breakpoint filters. Breakpoints get applied to wrong threads/processes/cores.
    • D.a) Breakpoint filters have to be specified after breakpoints are created.
    • D.b) Breakpoint filters are not persisted between debug sessions.
    • D.c) Breakpoint filters are not directly shown in the Breakpoints view, and breakpoints cannot be grouped based on a filter.
  • E) (1.3) With large stack traces and lots of threads, it is difficult to find things in Debug view.
  • F) (1.3.2) Processes/Threads being started rapidly can make the debug view flicker degrading UI performance.
  • G) (1.2.2, step 2) Creating a conditional breakpoint is error prone, because values from the variables/expressions views have to be cut and pasted into a modal dialog.

Proposed changes

Proposals for new features and changes in existing workflow.

Allow debugging without Debug view

This workflow change would require a few separate features (each described in more detail in following sections):

  • Debug top-level tool-bar with run control actions
  • An active debug context for each window not tied to any particular view
  • A selection dialog for changing the active context
  • A slick UI to make the currently-selected context plainly visible.

The main workflow problem these changes would help address is B), but it could also help with E) and F) depending on the selection dialog implementation.

Debug toolbar

In concept this feature is very simple. The run control commands in the Debug action set should be available on the main tool-bar. However, there are two major challanges to implementing this feature. They are listed below along with ideas on how to mitigate them.

  1. The tool-bar space is very limited and a Debug tool-bar would take up a lot of this space.
    • The action set (customize perspective) control mechanism could be extended to allow the user to selectively enable the tool-bar buttons in an action set.
      • + This would be a very clean solution and it would benefit not just the debug users but everyone that finds most of the tool-bar buttons use-less.
      • - Unfortunately this change is beyond the scope of platform Debug, thus it would require many approvals.
    • Alternative the tool-bar actions could be enabled by a separate action set "Debug toolbar".
      • + It would work without needing any infrastructure features.
      • + It would be easy to use.
      • - This is a pretty lame solution as far as user workflow.
      • - There is no precedent for it, for all other action sets it's either all or nothing.
  2. Users have learned to expect the run control actions to be present on the Debug view tool-bar, and moving them could create confusion.
    • The Debug view tool-bar could be left alone with the run control actions and all.
      • + No changes in user expectations needed.
      • + Easy to do :-)
      • - The duplicate run control actions in the view and on the main tool-bar would look very unpolished at best.
    • The Debug view tool-bar run control actions could be made visible based on a preference.
      • + It would create a smoother transition path for users.
      • + The preference could be set by vendors depending on how conservative they want to be with changing workflow in their product.
      • - Same unpolished look problem if the buttons are visible in both tool-bars.
    • The Debug view tool-bar actions AND the debug top-level tool-bar could be controlled via a preference.
      • + All the same benefits as the previous solution.
      • + It would eliminate the double-button unpolished look.
      • - Would require porting actions to the command framework and may require some unorthodox coding (i.e. hacks).
      • - The preference would interfere with the standard Customize Perspective action set configuration workflow.

Default debug context provider

A brief overview of the debug context framework:

The Eclipse debugger framework has a concept of an "active debug context" in each Workbench window, which is modeled after the active selection service in Workbench. This active context is consumed by the common debugger views (variables, memory, modules, etc.) to display relevant data. On the provider side, views can register themselves as debug context providers and when they become active their context becomes the active window context, and currently the Debug view is the only such context provider. There is a provision in the framework for a "default" context provider which is not associated with any view, however this default provider is rather limited and is currently not being used.

To allow for meaningful debugging without the debug view present, I believe the following changes would need to be made to the active debug context behavior:

  1. A default debug context provider (not associated with any view) is always created.
  2. The default context provider reacts to debug model events in the same way as the Debug view does and uses the model-provided selection policy to resolve selection conflicts.
    • In listening to model events, the default context provider by default, masquerades as the Debug view to the model, by using the same presentation context ID.
    • Alternatively the default context provider could use the presentation context ID of a different view, such as Target Manager. This may require additional infrastructure and APIs.
  3. When a view which is not a debug context provider becomes active, the default context provider becomes the active debug context provider.
  4. When not active, the Debug view listens to the active window debug context and changes its selection to match the active context.

Active debug context selection dialog

Without the Debug view open, users will need a method to change the active context: a specialized selection dialog can be used for the purpose. The selection dialog could be made available through the Navigate menu and a short-cut key.

The "Select Debug Context" debug context dialog would have the following features:

  1. A drop down box for selecting the content provider. This would normally be the content provider mimicking the Debug view, but differenent content providers could be registered as well.
  2. A recently-selected contexts list.
  3. A tree-viewer with the contexts from the selected content provider (essentially the debug-view in a dialog).
  4. The two lists above could share the same viewer for easier navigation.
  5. A filter-as you type text area would NOT be used as it would be difficult to implement with a lazy content provider and would not necessarily be that useful with debug elements (threads/stack frames/etc).

Active debug context UI indicator

Without the Debug view open, currently there is no indication in the UI as to what is the active debug context. To address this problem, there needs to be a dedicated display area for the current active context. The workbench status bar seems like the best-suited place for this information. It would be implemented as follows:

  • The default debug context provider registers a control with the status bar that shows the active debug context.
  • The status bar uses it own presentation context ID to request labels from the model.
  • The debug models generate a dedicated label and icon which combines information about contexts launch, target, thread, and frame information.
  • The active debug context status control is configurable to show either a single icon and string, or multiple icons and strings (i.e. columns).
  • A hover for the this control is dedicated which shows the active debug context as it would appear in its full hierarchy in the Debug view.
  • Finally, the active debug context status control includes a button to open the debug context selection dialog.

Allow multiple debug sessions to be equally share screen space in a single window

This would involve these new features:

  • Allow multiple instances of debugger views (variables, console, etc.), which would stay focused on a given context, or group of contexts.
  • Allow the editor area to be configured to show multiple editors, which is possible now, but to also allow the debugger to explicitly select the section of the editor area, where to show an editor part.

The main problem these changes would address is A), but it could also help with C).

Debug Working sets

Just like the resource system, the debugger can quickly overwhelm the user with data. The resource system provides working sets the help the user manage all this information. So far, an equivalent system is missing in the debugger. Part of the problem is that the debugger data is much more dynamic than the resource system, so implementation of a debug working set may need to be much different than the resource one and will need to allow for elements to be added/removed based on filters rather than on a fixed set. The features of the Debug Working Sets would include:

  • A Debug Working Set allows the user to add any debug elements from the Debug view or other debug content provider.
  • The working set stores the elements as mementos rather than actual object instances. If multiple objects match a given memento, they are all all included in the working set.
  • A Debug Working Set can have an icon decorator and a label associated with it. Per user preference, this decorator and or label is added to its elements when displayed in Debug view and elsewhere.

Multiple debugger view instances

Allowing multiple instances of views is rather easy, managing the active contexts of multiple views is the difficult part. The complete feature would include the following provisions:

  • The debugger views include a view menu and tool-bar action to duplicate the given view.
  • These views would allow the user to change the input of the view from the the window's active debug context to any debug context, using the debug context selection dialog.
  • Once the view is focused on a particular context, its content description shows that context's label. This is the same label as the one used in the status bar active debug context control.
  • Additionally, rather than explicitly setting the input context of a debugger view, a user may restrict a given view to a working set.
  • When a debugger view is restricted to a working set, it changes it's input only when the active debug context is within this active working set.
  • Also, when a debugger view if restricted to a working set, as an option, that working set's decorator is added to the view's icon and the working set label is shown in the view's content description.

Debugging with multiple editors visible

The multiple debugger views could be useful when debugging multiple contexts simultaneously, but they will not be that useful if the source from only one context will be visible at a time. Currently, the user is able to arrange multiple editor side by side in the editor area. However, there API to allow the debugger to ensure that an editor is opened in a particular section of the editor area. There are two ways to solve this:

  1. Add functionality to workbench editor area management:
    • Add an API to workbench to allow the debugger and other clients to identify and target specific editor areas.
    • Add a feature in the debugger to open editors for a specific working set in a specific section of the editor area.
  2. Create a "source viewer" editor.
    • As the user steps through the code, the source viewer is used to show the code and the IP instead of the standard editor associated with the given content type.
    • The source viewer editors probably need to be debug model specific, and content-specific.
    • The source viewer can be restricted to a given working set just like other debugger views.
    • The source viewers can be arranged as needed by the user in the editor area, so that multiple debug sessions can share the same window's editor area.


To comment and discuss the content on this page use the Talk page. You can get to this page by clicking on the "Discussion" link on the menu on the left side of the page.