|
|
| (58 intermediate revisions by 4 users not shown) |
| Line 1: |
Line 1: |
| − | 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: [http://dev.eclipse.org/mhonarc/lists/platform-debug-dev/msg01179.html "ideas for improving multi-context debugging"]. The first document produced by this group was [[DSDP/DD/MultiContext_UnlinkViewContextProposal|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.
| + | The work tracked by this page has moved to this [[CDT/designs/MultiCoreDebug| new page]] as part of the CDT project. |
| | | | |
| − | == Use cases ==
| + | The Multi-core Debugging Work Group page can be found [[CDT/MultiCoreDebugWorkingGroup|here]]. |
| − | 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. :
| + | |
| − | *:;:# When a thread blocks while stepping,
| + | |
| − | *:;:# User switches focus to another thread and steps until the lock is released,
| + | |
| − | *:;:# 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 :
| + | |
| − | *:;:# User sets a breakpoint at a location where a shared variable is written.
| + | |
| − | *:;:# Multiple threads hit the breakpoint
| + | |
| − | *:;:# User looks at each threads to see the thread-private data in each thread.
| + | |
| − | *:;:# User steps the threads individually to watch what happens to the shared data.
| + | |
| − | *:;:# Alternatively, user steps all threads.
| + | |
| − | *:;:# Multiple threads may hit the breakpoint at the same time.
| + | |
| − | *:;:# User sets another breakpoint further down in routines that access the shared data.
| + | |
| − | *:;:# 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.
| + | |
| − | *:;:# User creates a breakpoint on the routine to be debugged.
| + | |
| − | *:;:# User defines which threads should be allowed to hit the breakpoint.
| + | |
| − | *:;:# 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 :
| + | |
| − | *:;:# User debugs a subset of threads (using filtered breakpoints, etc.).
| + | |
| − | *:;:# 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.
| + | |
| − | *:;:# User sets a breakpoint and a number of threads hit the breakpoint, user examines the data and resumes threads individually.
| + | |
| − | *:;:# 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
| + | |
| − | *:;:# User sets a breakpoint that some threads may hit.
| + | |
| − | *:;:# Some threads hit the breakpoint.
| + | |
| − | *:;:# 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.
| + | |
| − | | + | |
| − | == Comments ==
| + | |
| − | To comment and discuss the content on this page use the [[Talk:DSDP/DD/MultiContext|Talk page]]. You can get to this page by clicking on the "Discussion" link on the menu on the left side of the page.
| + | |
