|
|
| (165 intermediate revisions by 7 users not shown) |
| Line 1: |
Line 1: |
| | = Introduction = | | = Introduction = |
| | | | |
| − | This page documents the activities of CDT's Multi-Core Working Group. This group aims to bring together different people from the community to jointly work on developing multi-core debugging for CDT. The group was first proposed at the CDT Summit 2010 and the suggestion was well received. | + | This page documents the activities of CDT's Multi-Core Working Group. This group aims to bring together different people from the community to jointly work on developing multi-core debugging for CDT. The group was first proposed at the [http://wiki.eclipse.org/CDT/summitfall2010 CDT Summit 2010] and the suggestion was well received. |
| | | | |
| − | Any one interested in helping in this effort is welcome to follow or join the group.
| + | Although this effort does cover the debugging of target with multiple cores, we use the term ''Multi-core debugging'' in a much wider sense. ''Multi-core debugging'' is meant to describe the simultaneous debugging of multiple cores, processes, threads, or other objects which are represented in standard debugger views. |
| | | | |
| − | === Conference calls ===
| + | Any one interested in helping in this effort is welcome to follow or join the group. Teleconferences are held on a regular basis to discuss progress, issues, features, tasks, etc.<br> |
| | | | |
| − | Conference calls are held on a regular basis to discuss progress, issues, features, tasks, etc.<br>
| + | = Next Teleconference = |
| − | Currently, we have conference calls every two weeks. The next call info is:
| + | |
| | | | |
| − | : Tuesday November 30th, 2010 at 11 a.m. Ottawa time
| + | Every second Tuesday of the month at 11 a.m. Ottawa time <br> |
| − | : Canada and US Toll Free - (877) 748-5444
| + | The next one will be on Tuesday November 11th, 2014<br> |
| − | : [[CDT/MultiCoreDebugWorkingGroup/calls | International Numbers]]
| + | |
| − | : Conference ID - 620 4947
| + | |
| − | : [[CDT/MultiCoreDebugWorkingGroup/calls/minutes | Upcoming agenda and previous minutes]]
| + | |
| | | | |
| − | == Multi-Core Debugging ==
| + | The call info is the same as for the CDT monthly calls: |
| | | | |
| − | Although this effort covers the debugging of target with multiple cores, we use the term ''Multi-core debugging'' in much wider sense. ''Multi-core debugging'' is meant to describe the simultaneous debugging of multiple cores, processes, threads, or other objects which are represented in standard debugger views.
| + | * North America 1-866-569-4992 |
| | + | * Germany 49-692-2224-6059 |
| | + | * France 33-(0)-17-070-8535 |
| | + | * UK 0800-033-7806 |
| | + | * Switzerland 41-44-580-2115 |
| | + | * Sweden 46-85-063-8386 |
| | + | * Italy 003-902-3604-8268 |
| | | | |
| − | == Features of current interest ==
| + | Attendees use this: Extension: 700 Passcode: 19455 |
| | | | |
| − | # Grouping of debug view elements
| + | '''Agenda'''<br> |
| − | #* DSF sees to have a limitation where it only accepts a single level of IContainerDMContext.
| + | * SWTBot testing for Debug/CDT |
| − | # Debug operations (step, resume) on groups
| + | * [http://eclip.se/434558 Multi-terminate/Multi-disconnect] |
| − | # Hiding of debug view elements
| + | * [http://eclip.se/235747 Register grouping] |
| − | # User-selectable Debug View layouts
| + | * Launch bar next steps/integration with our launches |
| − | # [[PinAndClone | Pin and Clone of debugging views]]
| + | * New UI |
| − | # Grid view
| + | * EclipseCon/CDT Summit |
| | + | * Other |
| | | | |
| − | == Features already completed == | + | = Previous minutes of meetings = |
| | | | |
| − | [[CDT/MultiCoreDebugWorkingGroup/CompletedFeatures | List of features that have already been implemented.]] | + | : [[CDT/MultiCoreDebugWorkingGroup/calls/minutes | Previous minutes of meetings]] |
| | | | |
| − | == Use-cases == | + | = Features of current interest = |
| | | | |
| − | [[CDT/MultiCoreDebugWorkingGroup/UseCases | Description of the set of use-cases proposed to be covered.]]
| + | The following is a list of features have had some effort invested in them but are not ready for release. The effort might have stopped due to lack of resources, but could be easily revived. |
| | | | |
| − | == Current issues ==
| + | # [[CDT/MultiCoreDebugWorkingGroup/MultiLevelHierarchy | Multi Level Hierarchy in the Debug View]] |
| | + | # [[CDT/MultiCoreDebugWorkingGroup/DebugElementsGrouping | Grouping of debug view elements]] |
| | + | # [[CDT/MultiCoreDebugWorkingGroup/DebugElementsHiding | Hiding of debug view elements]] |
| | + | # [[CDT/MultiCoreDebugWorkingGroup/DebugViewLayouts | User-selectable Debug View layouts]] |
| | + | # [[CDT/MultiCoreDebugWorkingGroup/VisualizerView | Visualizer View]] |
| | + | #* A first version of the Multicore Visualizer as well as the Visualizer Framework are part of the Juno release |
| | + | #* Many enhancements are still of interest. |
| | + | # [[CDT/MultiCoreDebugWorkingGroup/SynchronizedOperations | Synchronized/Grouped Run Control Operations]] |
| | + | #* User defines a group (cores or processes or threads) which makes up the application, and can perform application-level operations on it |
| | + | # [[CDT/MultiCoreDebugWorkingGroup/GlobalBreakpoints | Global breakpoints]] |
| | + | # [[CDT/MultiCoreDebugWorkingGroup/EnhancedBreakpoints | Enhanced Breakpoint Support]] |
| | + | # [[CDT/MultiCoreDebugWorkingGroup/NewLaunchUI | New Launch UI]] |
| | | | |
| − | [[CDT/MultiCoreDebugWorkingGroup/Issues | List of current issues affecting this effort.]]
| + | = Features already completed = |
| | | | |
| − | = '''Description of potential features''' =
| + | [[CDT/MultiCoreDebugWorkingGroup/CompletedFeatures | List of features that have already been implemented.]] |
| − | | + | |
| − | Below is a description of different features that have been proposed. Some of them are currently of interest, others are proposals that still need to be discussed.
| + | |
| − | | + | |
| − | == Multi Level Hierarchy in the Debug View using DSF (Dobrin)==
| + | |
| − | | + | |
| − | Currently Platform Flexible enables the debug view to show any hierarchy of objects.
| + | |
| − | | + | |
| − | DSF currently has defined two data model interfaces IExecutionDMContext and IContainerDMContext
| + | |
| − | and two view models classes: AbstractThreadVMNode and AbstractContainerVMNode. <br>
| + | |
| − | I would like to explore these interfaces and the classes using them to deliver the following features:
| + | |
| − | | + | |
| − | * Containers can be recursive - each container can have its own stack and/or other child containers.
| + | |
| − | * The user should be able to filter and show container nodes or container types.
| + | |
| − | * The user should be able to group and ungroup container nodes or container types.
| + | |
| − | * Filtering and grouping nodes can be both with the involvement of the back end debugger or not.
| + | |
| − | * The user should be able to change the way the contaniers are presented in the debug view without changing the container's hierarchy.
| + | |
| − | * The containers can have types so the user can filter or group containers by container type.
| + | |
| − | | + | |
| − | I believe these features are driven from the use cases of section 4 of the use case page, called [[CDT/MultiCoreDebugWorkingGroup/UseCases | Debug View hierarchy operations.]]
| + | |
| − | | + | |
| − | Currently I know of two Bugzilla entries related to the idea:
| + | |
| − |
| + | |
| − | [https://bugs.eclipse.org/bugs/show_bug.cgi?id=240208 Bug 240208] A single VMNode should represent all execution levels<br>
| + | |
| − | [https://bugs.eclipse.org/bugs/show_bug.cgi?id=306868 Bug 306868] DefaultVMModelProxyStrategy does not generate proper delta with recursive VM nodes<br>
| + | |
| − | | + | |
| − | I think we can reuse the first one to further discussion on the topic.
| + | |
| − | To discuss requirements and use cases we can use [[CDT/MultiCoreDebugWorkingGroup/UseCases | the use case page.]]
| + | |
| − | | + | |
| − | == 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.
| + | |
| − | | + | |
| − | == Debugging with multiple editors visible ==
| + | |
| − | This feature would 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 Pin & Clone feature could be useful when debugging multiple contexts simultaneously, but 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.
| + | |
| − | | + | |
| − | == 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 to 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.
| + | |
| − | | + | |
| − | == 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.
| + | |
| − | | + | |
| − | == (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?
| + | |
| − | #* ''Performance!!!'' - Retrieving stack data for multiple threads at the same time could be very expensive.
| + | |
| − | #* ''Clutter'' - Deep stack traces would still take a lot of space. This view trades clutter in one part of the tree, with clutter in another part. Instead, would stack trace be better placed in a separate window or pane.
| + | |
| − | | + | |
| − | == 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 debugger 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.
| + | |
| − | | + | |
| − | === View Layout ===
| + | |
| − | | + | |
| − | The core purpose of the Debuggers View would be to present the debug model data organized by instances active debuggers. The only universal part of the view layout is that the top-level elements would be the active debuggers. The data hierarchy under each debugger would depend on that specific debugger. The ''debugger'' is a new concept that is currently not clearly defined in the Eclipse debug framework. Examples of debuggers are:
| + | |
| − | * A JVM which is launched from Eclipse with the debugger interface active.
| + | |
| − | * A GDB debugger instance launched from Eclipse.
| + | |
| − | * A debugger agent running on a device that Eclipse is connected to.
| + | |
| − | * A debugger process (like GDB) which is connected to multiple debug agents running on different local and remote systems.
| + | |
| − | | + | |
| − | ==== Stack Frames ====
| + | |
| − | Representing stack frames along with the rest of the process hierarchy is a major contributor to the clutter in Debug view. So to reduce the clutter, stack frames would not be shown in this view. Instead the user would use a separate view for stack frame selection. Although stack frames would not be shown, there is still a "location" associated with each suspended thread. When a suspended thread is selected in the Debuggers view, the editor should be shown pointing to the location where the thread is suspended.
| + | |
| − | | + | |
| − | ==== Launches ====
| + | |
| − | The Debug View shows launches as top-level entries, but the information and the control functions associated with the launch is often duplicated by other elements in the hierarchy. In the debuggers view, the launches would not be presented directly as elements.
| + | |
| − | | + | |
| − | ==== Example: GDB ====
| + | |
| − | In the latest version GDB has introduced support for attaching to multiple targets. This is how the GDB debugger could be presented:
| + | |
| − | * ''GDB process'' - The local GDB process which is communicating with Eclipse over STDIO. This element would also be presented in the console view to allow CLI and MI protocol interaction.
| + | |
| − | ** ''Process'' - The process that is under debugger control. This object could be used both for run control operations as well as routing STDIO to the console.
| + | |
| − | *** ''Thread'' - The threads which are within the process.
| + | |
| − | | + | |
| − | ==== Example: Wind River Debugger ====
| + | |
| − | The Wind River debugger, like GDB is an application which communicates with the Eclipse front end over a single communication channel. However, it is capable of connecting to multiple debug agents running local and remote systems. The hierarchy presented in the Debuggers View would reflect that:
| + | |
| − | * ''Debugger Process'' - The debugger that is running on the local system. It would also be represented in the console, showing the protocol interaction with Eclipse.
| + | |
| − | ** ''Target Connection'' - Represents connection to a given debug target. It could be an agent running on a remote system, a simulator process, etc.
| + | |
| − | *** ''target specific model hierarchy'' - Depending on the connected target, the debug model may vary. It could be as simple as a single execution context of a processor, or as complex as several processor cores running an entire OS under the debugger's control.
| + | |
| − | | + | |
| − | ==== Example: legacy connection ====
| + | |
| − | As mentioned earlier the ''debugger'' is a new concept in the debug model, which would be introduced by this feature. But for backward compatibility we need to have a way to represent the debuggers implementing the existing interfaces.
| + | |
| − | | + | |
| − | * ''Debug Target'' - The current debug target element would represent the debugger. If there are multiple debug targets created by a process, these targets would be separate top-level elements in the view.
| + | |
| − | ** ''Process'' - The process object belonging to a given debug target would be shown as a child of the debug target.
| + | |
| − | ** ''Thread'' - Threads that are within the process.
| + | |
| − | | + | |
| − | === View Mockup ===
| + | |
| − | | + | |
| − | [[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:''
| + | |
| − | # ''A user-mode agent which is attached to a "hello" process.''
| + | |
| − | # ''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 API defined for a "debugger". The <nop>IDebugTarget interface is the closest thing to it, however it has a fixed relation ship with threads and it is not used by non-standard models. A new API would need to be invented to represent debuggers, and this API would need to be backward compatible with the existing debuggers.
| + | |
| − | * ''Debug Context Workflow'' - Just like with the Locations View, inter-operation between this view and the Debug view would be challenging.
| + | |
| − | * ''Details pane (for stack)?'' - One way to show stack without forcing too much clutter. Detail pane could show stack for multiple processes too.
| + | |
| − | * ''Configurability'' - Some flexibility in presentation should be considered to accommodate different working styles. This configurability should include the choice of hierarchy in the view.
| + | |
| − | * ''Expanding stack on demand'' - One cheap option for displaying stack would be to allow displaying in the view, but still allow it to be shown in the view.
| + | |
| − | | + | |
| − | == Debug view ''Modes'' ==
| + | |
| − | | + | |
| − | The above proposals, [[#Proposal:_.28Debug.29_Locations_View|Debug Locations View]] and [[#Proposal:_Debuggers_View_.28another_alternative_to_Debug_View.29|Debuggers View]], would introduce two new views which would have a lot of overlap in functionality with the current Debug View. This in itself would create confusion and add clutter to the UI, as users may want to switch between the different views depending on where they are in the debugging workflow. This proposal would extend the above two new views, by merging them with the existing Debug View. The three views would operate as a single view with an action which would switch between the different modes of presenting data.
| + | |
| − | | + | |
| − | === Mode selection menu ===
| + | |
| − | Switching between different modes would need to be quick and easy. To achieve a toolbar pull-down menu should be used as shown below. Also, it would be very helpful to easily see what is the current view mode, so the pull-down menu icon should change depending on the active mode.
| + | |
| − | | + | |
| − | | + | |
| − | [[Image:DSDP_DD_MultiContext-debug_view_modes_pulldown.png]]
| + | |
| − | | + | |
| − | ''Image: Mockup of a pull-down toolbar menu to switch the Debug View mode.''
| + | |
| | | | |
| − | === Automatic mode switching === | + | = Potential future features = |
| − | The presentation mode from the proposed [[#Proposal:_.28Debug.29_Locations_View|Debug Locations View]] only shows data for suspended threads and processes. When the user resumes all suspended contexts and the Locations View presentation is blank, the view should have the option to automatically switch to one of the other modes. Likewise, when the view is not in the Locations View presentation when a context suspends, the view should have the option to switch to the Locations View for optimal presentation of stack traces.
| + | |
| | | | |
| − | === Multiple instances ===
| + | [[CDT/MultiCoreDebugWorkingGroup/PotentialFeatures | List of features that have been proposed]] and may be addressed in the future. |
| − | One drawback of stuffing the different view presentations into a single view, is that the user would not have the option of viewing the debug model using two different presentations at the same time. For example, the user may want to see the entire debugger hierarchy from the Debuggers View, and have the Locations View shown below it. To solve this problem, the Debug view should have a ''clone'' option. When two instances of Debug View are opened at the same time, one view can be in one presentation mode, while another view is in a different presentation mode. ''To avoid confusion as to which view sets the active debug context in the Window, any Debug view which is not the active debug context provider, should listen to the active debug context and update its own selection accordingly.''
| + | |
| | | | |
| − | == Notes == | + | = Use Cases = |
| | | | |
| − | # Many of the ideas expressed here are taken from the [[CDT/designs/MultiCoreDebug | Original CDT Multi-Core wiki page]]. This page has been replaced with the Multi-Core Working Group pages.
| + | * [[CDT/MultiCoreDebugWorkingGroup/UseCaseKernelDebug | Kernel Debug (also: bare-metal/bootloader debug)]] |
| | + | * [[CDT/MultiCoreDebugWorkingGroup/UseCaseEmbeddedApplicationDebug | Embedded Application Debug]] |
| | + | ** [[CDT/MultiCoreDebugWorkingGroup/UseCaseApplicationDebug | Develop-on-Target (local application debug)]] |
This page documents the activities of CDT's Multi-Core Working Group. This group aims to bring together different people from the community to jointly work on developing multi-core debugging for CDT. The group was first proposed at the CDT Summit 2010 and the suggestion was well received.
Although this effort does cover the debugging of target with multiple cores, we use the term Multi-core debugging in a much wider sense. Multi-core debugging is meant to describe the simultaneous debugging of multiple cores, processes, threads, or other objects which are represented in standard debugger views.
Any one interested in helping in this effort is welcome to follow or join the group. Teleconferences are held on a regular basis to discuss progress, issues, features, tasks, etc.
Every second Tuesday of the month at 11 a.m. Ottawa time
The next one will be on Tuesday November 11th, 2014
The following is a list of features have had some effort invested in them but are not ready for release. The effort might have stopped due to lack of resources, but could be easily revived.
