Difference between revisions of "DSDP/DD/MultiContext"

Revision as of 16:01, 18 June 2008

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.

Format:

• Family of use cases

  Use case 

  Description of the use case

  Scenario

  • 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.

1. 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.

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

This would involve two 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).

Comments

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.