|
|
| (17 intermediate revisions by 3 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.)
| + | |
| − | *;1.4) Context-specific expressions : User is using the expressions view to monitor different expressions which are valid only in specific context.
| + | |
| − | *:; 1.4.1) Local variable expressions : User creates expressions for local variables in a specific function. These variables are not valid in any other context.
| + | |
| − | *:; 1.4.2) Thread-local variable expressions : User creates expressions for variables which are valid only in specific threads.
| + | |
| − | *;1.5) Clone threads : Debugging a system where multiple threads are executing the same section of code.
| + | |
| − | *:; 1.5.1) Comparing data in clone threads : User compares variables in threads which are stopped in the same section of code.
| + | |
| − | * '''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.
| + | |
| − | *;3.4) Synchronized run control operations : Some multi-core debuggers allow for performing synchronized operations on multiple cores. Allowing the debugger or the hardware to operate on multiple cores minimizes the skid, or the time lag, in when the operations are carried out on the different cores. There needs to be dedicated UI and APIs to exercise these debugger features.
| + | |
| − | | + | |
| − | == 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.
| + | |
| − | ** D.d) Currently there is no way to distinguish whether a breakpoint belongs to the active context or not if there is more than one running debug sessions. It will be even more problematic to do it in the multi-context environment.
| + | |
| − | * 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.4, 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.
| + | |
| − | | + | |
| − | == Implemented: Allow debugging without Debug view ==
| + | |
| − | Update: this feature was implemented as a "breadcrumb" mode in Debug view. For deails, see user documentation for Debug View and [http://bugs.eclipse.org/252677 Bug 252677].
| + | |
| − | | + | |
| − | == Proposal: Allow multiple debug sessions to 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 are no APIs 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:
| + | |
| − | # 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.
| + | |
| − | # 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.
| + | |
| − | | + | |
| − | == Proposal: Add context to expressions in the Expressions View ==
| + | |
| − | Currently, the Expressions view shows a flat list of expressions which are entered by the user (either directly or through drag-and-drop, etc.). Whenever a new debug context is selected in Debug view, all the expressions are re-evaluated in this new context. There are several problems with this behavior:
| + | |
| − | * (1.4) Expressions view gets filled up with invalid expressions because only a small subset of them can be evaluated in the current context.
| + | |
| − | * (1.4) Evaluating invalid expressions can be expensive for some debuggers if a large symbol database needs to be searched for a given expression.
| + | |
| − | | + | |
| − | === Persistable context ===
| + | |
| − | The major challenge for this proposal is the fact that there is currently no mechanism to persist debug context information which is sufficient for this purpose. It should be possible to persist the following information about the current context:
| + | |
| − | # ''Full selection in context'' - The debug context is a selection object, usually a tree selection, which could contain paths to multiple elements.
| + | |
| − | # ''The type of objects in context'' - Launch, debug target, stack frame, etc.
| + | |
| − | # ''Method to display the persistent context'' - We need to allow the user to examine and modify the persisted context information, so it should be possible to generate an image and a label for the context based on the persisted data.
| + | |
| − | | + | |
| − | === User control over how context is matched ===
| + | |
| − | Based on the specific use case (e.g. 1.4.1 vs 1.4.2), different elements of the context may be needed in deciding whether the expression should be evaluated. The user should be able to configure this for each expression using a control shown below, which would be added to the expression properties dialog. The default setting for this dialog should also be user-controlled.
| + | |
| − | | + | |
| − | [[Image:DSDP_DD_MultiContext-Context_selection.png]]
| + | |
| − | ''Image: Control for selecting which elements of the context should be used enable the evaluation of a given expression.''
| + | |
| − | | + | |
| − | === Filtering out disabled expressions ===
| + | |
| − | Finally, the Expression view should have the option to only show the expressions which are valid within the current context. This will greatly help in letting the user focus on what is important to his current task.
| + | |
| − | | + | |
| − | == Proposal: Compare mode in Variables views ==
| + | |
| − | This feature addresses use case 1.5. Currently, comparing variables from multiple contexts is very awkward: the user either has to switch back and forth between two contexts and search for the value, or he has to open a whole new IDE Window and compare data in the two windows. Instead, the user should be able to simply multi-select the different contexts which need to be compared, and the variables views should show data from both these contexts. Optionally the view should also highlight differences between the two data sets.
| + | |
| − | | + | |
| − | [[Image:DSDP_DD_MultiContext-variable_compare.png]]
| + | |
| − | ''Image: Variables view showing data from two different threads.
| + | |
| − | | + | |
| − | There a are some important details that still need to be worked out for this proposal:
| + | |
| − | * ''What should the detail pane show?'' The simplest implementation would be for it to show just the first value, a more complete solution could perform a detailed comparison of the values in the selected column.
| + | |
| − | * ''Which columns should be shown for comparison?'' The value column is the logical choice, but the user may also want to compare the Types column.
| + | |
| − | * ''How should the column width be determined?'' If there is more than two elements selected the user will need to be able to scroll to reveal all the values, otherwise the columns will be so narrow they won't be useful.
| + | |
| − | | + | |
| − | == Proposal: (Debug) Locations View ==
| + | |
| − | | + | |
| − | === Problem being Solved ===
| + | |
| − | The Debug view, which is currently the central point of control for all Eclipse debuggers is difficult to use when there are many threads suspended. The problem is that the top stack frame elements, which are most important part of the debug context because they indicate the location of the executing program, are buried deep in the tree hierarchy. The user has to scroll through a large amount of data in order to navigate between threads. This problem applies to more of the mult-context debugging use cases.
| + | |
| − | | + | |
| − | === View Mockup ===
| + | |
| − | This proposed Locations View would reverse the hierarchy found in the Debug View so that the debugger locations were found at the top level of the tree as shown in the image below.
| + | |
| − | | + | |
| − | [[Image:DSDP_DD_MultiContext-ip_view.png]]
| + | |
| − | ''Image: Locations view showing many threads stopped at two locations.''
| + | |
| − | | + | |
| − | === View Layout ===
| + | |
| − | The full layout of the view is the following:
| + | |
| − | * ''Debugger Location'' - This is typically the top stack frame.
| + | |
| − | ** ''Thread'' or ''Threads'' - The thread which is stopped at the given location. If there is more than one thread, then the threads are grouped together under a "Threads" node.
| + | |
| − | *** ''Debug Target'' - The debug target that the thread belongs to. The specific instances of a given element may appear multiple times in the hierarchy, since multiple threads are likely to belong to the same target.
| + | |
| − | **** ''Launch'' - The launch that the thread (and debug target) belongs to.
| + | |
| − | ** ''Stack frames'' - List of stack frames in the current thread.
| + | |
| − | ** ''Fork in the stack frame'' - If there are multiple threads which are stopped at the same debugger location, they may arrive at this location from different places in the code. If this is the case then the stack trace shown directly under the top level debugger location stops at the point where the stack traces do not match any more. Instead, separate Debugger Location elements are shown for the different stack traces.
| + | |
| − | *** ''Thread'' or ''Threads''
| + | |
| − | *** ''Stack frames''
| + | |
| − | *** ''Fork in the stack frame''
| + | |
| − | **** ...
| + | |
| − | | + | |
| − | === Issues ===
| + | |
| − | The Locations View implementation is going to be considerably more complicated than the Debug View because the Debug view closely matches the underlying debug model. While the Locations view needs to pull together and combine separate elements of the debug model into a new hierarchy. Following problems will need to be solved:
| + | |
| − | # ''New layout'' - Flexible hierarchy views allow for creating a custom layout in a view, however this process is rather complicated and error prone. The DSF Viewmodel framework makes flexible hierarchy more manageable, but it uses wrappers, so it is not %100 backward compatible, it is also currently available only for DSF-based debuggers.
| + | |
| − | # ''Running threads'' - The layouts view cannot become a replacement for the Debug view if it does not allow the user to affect threads and other debug contexts which are not stopped at any particular location.
| + | |
| − | # ''Locations API'' - Currently there is no simple API which could be used to populate the top-level locations. An API could be derived from the standard debug model, but to accomodate non-standard models (e.g. DSF) we need to create something new.
| + | |
| − | # ''Performance'' - As threads suspend and resume the Locations view may need to be repainted more than the Debug view. Special attention will need to be paid to performance to make sure that this view will be useful.
| + | |
| − | # ''Integration with Debug view'' - Currently the Debug View is the only view which is used as the provider of context for other debugger views. There is an API to allow other views, such as this one work in this role, but it has not been used and tested extensively. Some workflow problems may arise as this feature is prototyped and tested.
| + | |
| − | #* ''Debug toolbar'' - One obvious workflow issue is that the toolbar for controlling the debugger (run control, etc.) is currently located inside the Debug view. Should the locations view duplicate this toolbar, or create a top-level toolbar?
| + | |
| − | | + | |
| − | == Proposal: Debuggers View (another alternative to Debug View) ==
| + | |
| − | | + | |
| − | === Problem ===
| + | |
| − | The Debug View is at the most basic level a "launch history view". In other words, the top-level elements in the view are launch entries with the oldest one being at the top, and the newest at the bottom. Terminated launches can be automatically removed based on a preference, or they can remain in the view indefinitely.
| + | |
| − | | + | |
| − | Unfortunately, the launch history analogy does not work well for some debugging use cases such as use case 2.2 (Attaching to multiple processes). Each act of attaching to a process creates a new launch, which adds to the visual clutter. Also, launches are ordered from oldest to newest, while in this case it would be beneficial to sort the processes by ID, name, or some other criteria.
| + | |
| − | | + | |
| − | Another example where the launch analogy doesn't work is with a very simple debugger that may only exposes only certain hardware which needs to be configured. Performing an initialization cycle (using a launch) over and over may be a common task, which would also clutter the Debug view and confuse the user.
| + | |
| − | | + | |
| − | === Overview ===
| + | |
| − | The core purpose of the Debuggers View would be to present the debug model data organized by instances of a debugger. The top-level elements would be debugger connections and the hierarchy under each debugger connection would depend on the debugger. In a typical debugger scenario, like the "Java Application" launch, the debugger representation could actually be almost identical to the Debug view, since each launch creates a separate instance of a debugger connection. For other debuggers, such as new version of GDB, which can control multiple processes in a system, each debugger connection would show multiple processes being debugged. Attaching to a new process within this debugger would execute a new launch and in this way multiple launches may be associated with a single debugger connection.
| + | |
| − | | + | |
| − | [[Image:DSDP_DD_MultiContext-debuggers_view.png]]
| + | |
| − | ''Image: Debuggers View mockup showing a Java debugger connected to a program with multiple threads, and a "My Debugger" connected to two different systems:''
| + | |
| − | ''1 - A user-mode agent which is attached to a "hello" process.''
| + | |
| − | ''2 - An instruction set simulator of a PowerPC 860 processor.''
| + | |
| − | | + | |
| − | === Open Issues ===
| + | |
| − | * ''Debug View Overlap'' - This view would have a lot of overlap in functionality with the existing Debug view. As an implementation strategy, it may be better to try to change the Debug View behavior but this could prove difficult as backward compatibility requirements in Platform are very high.
| + | |
| − | * ''Remote Systems Explorer Overlap'' - The RSE already presents data in the same orientation as this view, so should RSE be used instead? However, RSE has a more broad purpose of managing remote systems, it is probably too cluttered with extra information to make it a useful debugger view. Also, for smooth integration with other views, the Debuggers View should use the flexible hierarchy framework, and RSE does not. Finally, RSE is rather heavy-weight which could deter potential adopters.
| + | |
| − | * ''API'' - There is no common API for "debugger connections". Something similar to the launch manager would be needed, contributing negatively to the large debugger API
| + | |
| − | that is in place already.
| + | |
| − | * ''Stack Frames'' - Should stack frames be shown in this view? Stack traces take up a lot of space and are a big reason why the existing Debug view is difficult to use. Ideally a separate view like the ''Locations view'' would be used in conjunction with this view to display stack frames.
| + | |
| − | * ''Debug Context Workflow'' - Just like with the Locations View, inter-operation between this view and the Debug view would be challenging.
| + | |
| − | | + | |
| − | == Proposal: Breakpoint Scope ==
| + | |
| − | | + | |
| − | == 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.
| + | |
