Difference between revisions of "CDT/Obsolete/MultiCoreDebugWorkingGroup/PotentialFeatures"

Latest revision as of 16:06, 16 January 2020

This page describes different features that have been proposed for Multi-Core Debugging. They may be addressed in the future.

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:

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.

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:

1. Full selection in context - The debug context is a selection object, usually a tree selection, which could contain paths to multiple elements.
2. The type of objects in context - Launch, debug target, stack frame, etc.
3. 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: 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: 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: 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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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: 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 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, Debug Locations View and 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: Mockup of a pull-down toolbar menu to switch the Debug View mode.

Automatic mode switching

The presentation mode from the proposed 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

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.

Debugging 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. Halt execution when another thread accesses shared address.
  9. 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.)

  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.

General enhancements proposed for Multicore Debugging

Below is a general list of enhancements that could improve multicore debugging for the CDT. If clarifications are needed, please contact marc.khouzam at ericsson dot com.

Stability of the Debug View

Ability to keep the debug view display as stable as possible for the user to quickly see what has changed. We want things to stay in the same place.

1. Stack list should have the ability to be fixed to a user-specified number to keep the display stable. For example if the list is fixed at 5, we would always show 5 lines for the stack frames even if there are e.g., 2 frames only, or if there are e.g., 8 frames. This feature would optional.
2. This idea may not easily apply to threads.
3. When a new thread stops, do we want to expand the new thread automatically? Need a user-option for this.
4. A good option would be to add the function name on the thread context, and keep everything collapsed. So, a preference could be to choose between expanding nothing automatically but rely on label of thread node, or expand everything (limited by max stack frame to display) or a smart behavior as we do now. The label could match the preference of if we expand automatically or not; we may want a separate preference for how much info is in the label.
5. When a new thread stops, do we switch focus to the new thread or not. It may be annoying to have it switch focus, in fact if lots of threads keep stopping, it will be unworkable. We could simply never allow switching, but it would be better to have a user preference for this. Having a user-preference to allow switching, not allow switching.

Grouping and hiding

The CDT community is currently working on a feature that would allow to group elements of the debug view into user-defined groups. These groups would be used to reduce the amount of information displayed at the same time, but also to perform operations on a set of debug entities (e.g., a group of cores). Below is the list of discussed requirements.

1. Expansion state of the groups should be preserved based on the last user decision. However, this should be a user-preference because it may not be the right thing is particular situations.
2. It should be possible to create many groups but not display all of them at the same time. The user should have access to all the groups and be able to choose which ones are shown in the Debug view. This could be a pull-down menu which lists all available groups, and the user can choose the ones to display.
   1. So we would have the following group management operations:
      1. Create (GUI and backend)
      2. Delete (GUI and backend)
      3. Show (GUI only, not backend)
      4. Hide (GUI only, not backend)
      5. Edit
   2. It should possible to create/edit a group based on already existing groups, where the content of the selected groups would also be made part of the new group. The existing groups would not be changed or removed.
3. GDB will soon support PTC sets (Process/Thread/Core sets). Eclipse grouping should be mapped to GDB PTC sets. Creating a group in the GUI should also create it in GDB to make it available in the command line.
   1. Need a way to keep the names of PTC sets synchronized between Eclipse and GDB so that the same sets can be used in the GUI and in the command-line.
   2. Creating a group in the GUI will make the group visible in the Debug view. On the other hand, creating a group in the command-line probably should not automatically be shown in the GUI. This will create the group in the GUI also, but not automatically show it.
4. Need an option for the user to decide if the console focus should follow the UI focus: should the PTC selected in the UI automatically become in focus in the console, and vice versa.
5. In the debug view, the basic entities should automatically be part of a first “default group”. This group could be collapsed or even hidden, but cannot be modified. This makes the debug entities always available to be added to different groups.
6. A debug entity can be part of different groups at the same time, just like for PTC sets.
   • When an entity is part of multiple groups, the expansion/selection should be done for the instance that the user is currently focused on. If a thread stops and the user was looking at it, that is the one that should expand. If a threads stops and is part of a group that the user was looking, that is the one that should expand.
7. Predefined hardware related groups (from HW definitions) shall be possible to use in the GUI.
   • Groups can be specified from some configuration file. For example a project could provide a list of pre-defined groups. This applies to static concepts such as cores, but not threads.
8. Groups should somehow be persisted across debug sessions.
   1. If the content of a group is not available when the new debug session is started, we could let the group fill itself gradually as things appear.
   2. If things disappear (e.g., threads) the group will continue to exist with a smaller content.
   3. Persistence should be per launch.
   4. Need support for import/export.

Synchronous operations

CDT should support the concept of synchronous operations. Synchronous operations have the following requirements:

1. Start, stop, step any number of debug entities (e.g, cores) synchronously
2. For step, next, finish operations only, one entity (e.g., core) acts as “group leader”, defining the stop condition for the operation. All other entities execute the same number of cycles/instructions. The leader should be the one for which the source code is in focus, i.e. the source code that the user wants to step. E.g., -exec-next --synchronous <ptc> --thread 6, should step thread 6 and all other threads in the ptc set based on when thread 6 really stops. Note that step, next, finish operations are only allowed when a thread/stack frame is selected.
3. Need for an option to decide if the threads should be synchronized with the others of the group, or should not. This option could be shown in the Debug view using the little icon of a chain to show that the group has the synchronized option enabled (they are linked together). What we hope for is to be able to click on the chain icon directly in the debug view instead of having a context menu or a toolbar menu.
4. When selecting an element (e.g., thread) within a group and doing an operation (e.g., step) we can do two things:
   1. step the entire group with the selected thread as the leader (sync option on)
   2. only step the selected thread leaving others stopped (sync option off)
5. In non-stop mode, if there are threads running in a group, allow the synchronous operation and we let the backend filter the running threads out of the command, or let the backend decide what it wants to do (e.g., like an error). CDT must allow performing the operation even though there are some elements running.
6. We should have soft groups based on multi-selection, where the user could select multiple elements and then the operation would apply to only those elements. To select the leader in this case, it could be the last element that was selected; the leader should be indicated in a different color within the selection. Potentially using an Alt-key modifier would provide a way to add things to a soft-group without changing the selected leader

Enhancements to Register view

The register view is currently limited and does not lend itself well to multi-core debugging. Below are some requirements for the Registers view.

1. Need for filtering. Registers shown should be controlled using regular expressions
2. The view should have two modes:
   • Showing the content of the real registers (i.e., top stack frame)
   • Showing the content of the real registers (i.e., top stack frame) and also show the value of each register that was pushed on the stack, kind of like a stack frame display, or a hover, or …
3. Symbol matching on pointer registers, so if a register points to a variable/symbol, the view will show the name of the symbol.
4. Compact presentation of registers to save space.
   • This could use a multi-column display to have the list of registers be in a ‘square-type’ display instead of a long list.
5. If supported by GDB, Eclipse should make use of MI commands that read/write multiple registers in single operation for better performance.
6. Different display format for each entry
7. Bit registers should be shown with their different parts, even with a hover to show what each part affects

Pin & Clone

Pin and Clone is a new feature of CDT which allows to ‘clone’ the different debugging views and ‘pin’ or ‘lock’ each one of them to a particular context. This allows looking at the data of different debugging contexts at the same time.

1. It should be possible to pin to a specific core/thread/current-thread
2. In the Expressions view, a different approach could also be used. We could use a 'path' to define the context of an expression. For example 'myvar' would be for the current selected thread/frame, but 'thread2/frame0/myvar' would refer to ‘myvar’ for thread 2 and frame 0, no matter what the current selection was. This could be way to pin a single expression instead of pinning an entire view. The path should allow for the chip to be specified.

Enhancements to the Expressions View

1. The Expressions view can currently be used to show registers. It would be nice to be able to use regular expressions in the Expressions view to help create many entries. For example, 'r*' would create an entry for all the registers that start with 'r'. To support this, the regular expression would need to specify the type of the entities to be created, e.g., registers, variables; Eclipse could then use the entire list of registers or current variables to find the ones that match the regular expression.
2. Import/Export of expressions
3. Different display format for each entry
4. Symbol matching for an expression

Enhancements to the Memory View

CDT currently offers two memory views: the standard Eclipse Memory view and a simpler Memory Browser. The requirements below could apply to one or both of these views, depending on what makes more sense.

1. Concept of ‘memory regions’
   • For example: the current stack, some protected memory regions, the legal stack space, some hardware circular buffers, etc. These regions can be shown in the memory view: One way to show it is to have a colored line over the region; having such a line allows multiple regions that overlap to still have their corresponding line be shown, one on top of the other. The real requirement is to be able to distinguish between such overlapping regions. These regions will need to be defined somehow, some from hardware for example.
   • If we want to have user-program-defined regions, like circular buffers, this may also require user-definitions. Regions could also be defined by the user based on different variables of the program. For example showing a region that describes an array, and showing the visual cue for the index variable passing through the array.
2. Visual cues for different aspect of the data.
   • show such things as the start and end of the stack.
   • show where registers point within the memory. This does not mean that any register that happens to point to memory should be shown. Instead we want to show the registers that are meant to point to memory, such as the stack pointer register. The list of such register is target-specific
   • show memory regions
   • Showing where user-selected variables point to. If a variable is selected in variables view, the memory view would highlight the corresponding region.
3. Context-menu for variables that allows to choose in which memory it should be shown. The existing “View Memory” could have a sub-menu listing the different memory spaces which the user can choose from
4. Support for different physical memories with the same addresses. There must be a way to tell which memory to look at when showing the memory view. To support different memory spaces (logical or physical) the memory view will need to indicate which memory is being shown. The logical memory spaces would be provided from the backend (most probably statically).
5. Memory views showing different memories could have different background shades of color, to make it easier to distinguish the different memories. Colors should be automatically assigned based on the configuration of the memories
6. Multiple memory ranges within the same address space should be possible to display. Although this can currently be done using multiple memory views, it would be nice to be able to show multiple ranges in the same view, with a visual divider. This is for space efficiency.

Breakpoint enhancements

The breakpoint handling in the CDT (and Eclipse in general) is currently very limited. The Breakpoints view has recently been enhanced to allow for a richer set of features, which are not yet being used by the CDT. Below is a list of requirements for the Breakpoints view and for the general handling of breakpoints.

1. Need to show target(s) to which the breakpoint applies
   • An example of this can be seen on page 17 of this presentation
2. Need to see all bps of the system in the view, but we should be able to filter based on a core, etc
   • One way to achieve this would be to use the breakpoint grouping feature, and provide a group for core/thread/process
3. Maybe show other breakpoint properties in the view (like JDT now does)
   • This could be done in the details pane
4. Should be possible to group watchpoints per memory space for systems that have multiple memory spaces i.e. group by resource
5. Should support breakpoints synchronization from the target for breakpoints that already exists on the target. This is exactly like tracepoints and disconnected tracing, where we need to 'load' the existing tracepoints/breakpoints from the target
   • DONE as long as GDB provide events to indicate the existence of such breakpoints, please see the breakpoint synchronization feature
6. Need ability to filter bps applicability based on cores, processes, groups, like we currently do for threads
7. Breakpoint hover in editor should be richer. It could at least show the targets where the breakpoint is currently installed.
   1. Need to handle the hover if there are multiple breakpoints at the same line
   2. Have an icon handling for up to two breakpoints but then need to fall back on the hover.
8. In the view, need an option to show all breakpoints or to show only bps relevant to the current context
   • DONE please the breakpoint filtering feature
9. It is possible that the installation of a breakpoint has failed for a subset of its targets. To avoid having to delete the breakpoint and re-create it on all targets, we need a "re-install" action (e.g., a right-click menu) for each target of a breakpoint. This action would allow the user to request a re-install attempt for breakpoint for a single (or multiple) selected target. The re-install could be smart and automatically only affect targets where installation failed.
10. The editor should always show the breakpoint in the code, as is done now, but the installation state should be context aware i.e., the installation icon should change depending on the current context and if the breakpoint is installed for that context.
11. We should be able to set different breakpoints at the same source line so that we can have one breakpoint with one condition for one thread/core, and another with another condition for another thread/core. With this support, the enabled state, condition and other attributes can all be global to all targets of a particular breakpoint instance. So, if the user wants to have different attributes for different cores or threads, it can be achieved by creating different bps at the same source line.
12. Even though we want to support multiple breakpoints for the same location, we still want to support that a single breakpoint will apply to multiple cores, but those will share the attributes (condition, state)
13. Should show breakpoint counters as provided by the backend, like number of hits. GDB actually shows the number of times a breakpoint was hit as part of ‘-break-list’ output.
14. When a breakpoint applies to multiple targets (threads/cores), there will be different hit counts, but this could still be shown in the same eclipse breakpoint, with a value for each target. We don't want to do this for such things as conditions because there is no point in showing the same condition multiple times, it takes too much space; for counters, since they are almost always different, it makes sense to show them per target.
15. Some targets only support a limited set of breakpoint conditions. Therefore eclipse should ask the target if the conditions are limited and if so, it should show a list of available conditions for the user to choose from. This should be extended to general breakpoint capabilities which can be more than conditions.
16. Pin&Clone can become relevant to the breakpoints view once it supports the multicore features.
17. Support for configuring HW breakpoint features such as counters, address ranges, masks, values, trigger action, etc. The backend will specify what is supported. Eclipse does not need to know if such capabilities are supported by HW or not.
18. When loading existing breakpoints from a target, breakpoints at the same location will either be kept separate in eclipse, or will be merged into one breakpoint, depending on what the backend specifies. The backend should take care of deciding if bps should be reported separately or joined, based on the fact that if there is different data on different breakpoints, then they cannot be merged into one. This is a backend requirement.
19. Support for breakpoint changes triggered by the target. Some targets can have their breakpoint state change ‘automatically’, and Eclipse should reflect those changes. For example, a hardware breakpoint can be removed by the target due to a chip reset. This could be handled with GDB events.
    • DONE please see the breakpoint synchronization feature
    1. When a breakpoint is automatically removed we show the breakpoint as uninstalled for the target, and then have a right-click action in breakpoints view that does "Re-install breakpoint ", which would allow the user to force a re-installation of the breakpoint. The re-install should be either on all targets that need it, or on the currently selected target.
    2. Re-install would be available in both the breakpoint view and the editor. In the editor we need “re-install on all targets” and “re-install for current target”.
    3. The reason for the removal of the breakpoint should be communicated to the user. We need some kind of notification to make sure the user notices.

Enhancements to Visualizer view

1. The Multicore Visualizer shall allow to display different debugging information. Such information could be:
   • PC content for each core
   • The new GDB PTC set concept
   • Memory locations
   • Variables/Expressions
   • Source code line number for a thread
   • Processor load
   • If possible some kind of generic info that can be customized for specific debugger/target concepts

     [WRS] Some of this information (processes, threads, variables, line number, load, etc.) makes sense to add to the "generic" MulticoreVisualizer. Some of this sounds like fodder for a custom visualizer or a custom extension to the MulticoreVisualizer, which we should certainly facilitate if we can.

     [Khouzam] Here we need to implement the 'layers' idea to provide extra information in the Visualizer. We should choose a couple of layers to start with and then add more layers based on real-world needs.

2. The Multicore Visualizer shall allow to perform different debugging operations. Such operations could be:
   • Run control operations (DONE)
   • Breakpoints operations
   • Modification of memory, registers, variables
3. The Multicore Visualizer should handle other hardware than CPUs/Cores such as Memory/Caches and I/O.
   • The information needed to know what to display beyond CPUs/Cores will often be chip-specific. We could have the concept of chip-definition files. Such a description of a particular chip would provide static information that cannot be obtained automatically using the target agent (currently GDB/gdbserver).

     [Khouzam] As we discussed once at the multicore debug conference call, companies could contribute their chip-definition files to the CDT. This would allow CDT users to visualize many different chips out-of-the-box. Tilera's set of chips is a good example.

4. Representation/layout should be configurable, to allow a user to define how the view should look like, based on the current system.

   [WRS] Certainly we should make colors, fonts, etc. configurable. Beyond that, we should request that people quantify the configuration support they want, and decide whether that is best handled as extensions of the Multicore Visualizer, or as alternate views/layers, instead. We should take care not to go down the slippery slope of over-featuring the Multicore Visualizer -- instead, we should provide mechanisms/support for making custom visualizations easier.

   [Khouzam] I agree. We can easily go too far and waste time with low-value customizability. We can add customizable aspects as they are requested for real-world use-cases.

5. The Visualizer view representation should be persisted between Eclipse sessions.
   • If the user can configure the view, then it would be nice to be able to export the resulting layout to load later or send to someone

     [WRS]Obviously we'd persist preferences (fonts, colors, etc.) in the normal way. We'd need more specific examples of what folks are looking for beyond that to understand what would be useful/important to make exportable/importable.

     [Khouzam] This point is very general and is simply meant to remind us that all configurations done by the user should be persisted in the normal Eclipse fashion.

6. The Multicore Visualizer should support Grouping/Hiding very much like the debug view will, as well as Pin&Clone.
   • Groups of the Visualizer should be synchronized with the debug view.

     [WRS] Assuming there's a way to manage and communicate grouping between the views, as there is with managing of the selection, this makes sense.

   • When selecting a group in the debug view, the Visualizer view could highlight the set of cores/threads/processes in that group for more visual feedback.

     [WRS] We're already doing something like this for threads belonging to the same process; maybe we just need to generalize this "enhanced" highlighting behavior to user-defined groups.

     [Khouzam] Yes, this is probably an obvious thing for groups, now that we have it for the current Multicore Visualizer.

7. The Multicore Visualizer should have the ability to zoom, and based on the zoom level, the view could automatically add more information because there is more space available. So the level of detail will increase with the zoom level

   [WRS] True -- the Multicore Visualizer already handles being made too small by omitting text labels and other detail. We can also go in the other direction and add more detail if we are given more real-estate. I wouldn't go too far in this direction, though, because then you'll wind up with people complaining about having to keep zooming in and out to see more and less detail. We might want to consider instead putting some information on separate, selectable "overlays" or "layers", so that one can select what's needed without having to make the visualizer bigger to accommodate it.

   [Khouzam] Valid point. I thought automatically adding more information as the user zoomed-in could be user-friendly. The "layer" concept should come first. Automatically turning on layers is something we could then discuss.

   • A concept of grid-in-grid would allow separating each Multicore Visualizer element into sub-elements like a box for each register, or variable. As an example, this could be applied to the zoom level, where we could zoom out of the Multicore Visualizer of a single chip and then show a Visualization of many chips, each one showing a grid of cores as a sub-element.

     [WRS] We might also allow multiple Visualizer views, as someone suggested at the EclipseCon talk, and then have a "Processor Visualizer" view, so that one can click around in the Multicore Visualizer, and see more detail about the currently selected cpu/core in the processor visualizer -- again, as a way to avoid the user having to constantly zoom in and out to see the necessary detail.

     [Khouzam] That sounds good. I'm a little worried that people wouldn't realize they could do this by using multiple views though. But I like that one view could show a higher level, and then using the synchronization with the debug view, a second view could be 'zoomed' on the currently selected core. Then, with Pin&Clone, you could even have multiple views, zoomed on different cores at the same time.

8. Synchronized resume and step must be supported in the Visualizer view. A synchronized resume or step is performed on multiple cores/processes/threads while keeping the progression in lock-step where each entity progresses at the exact same ratio.

   [WRS] If it's like synchronized resume of multiple threads, that might be a back-end/debugger feature, and below the visualizer's radar.

   [Khouzam] You are right that the actual implementation of the synchronized resume/step must be performed by the back-end. But CDT will need to provide UI to support this operation.

   • The concept of a leader for a synchronized operation is necessary. The leader is the entity part of the synchronized operation that will indicate when the operation has completed. For example, if two threads are stepped in a synchronized manner, the selected leader thread is the one for which the step must finish to indicate the operation is done.
   • The Visualizer view should support soft-groups. A soft-group is a group that is defined for a single operation; for example, a drag-selection or a multi-selection define a soft-group. Soft-groups needs a way to select a leader for synchronized operations. For multi-select, the last selection could be the leader. For drag-selection, the user could specify the leader by un-selecting an entity and then re-selecting it, making it the last one part of the selection.
9. Building blocks of the view should not be limited to cores, but should be a generic building block that the user can name, set the size, specify the content. The content needs to be based on what the backend knows: “fundamental building blocks”, i.e., threads, cores, chips, etc.
   • The Visualizer view could have a concept of widgets which already exists or can be created.
   • Configuration may need to be done at different levels. This means that some configuration would be done by the chip provider, e.g., the number of cores to show, other hardware entries to show; while other configuration could be done by the installer, e.g., which subset of cores to actually show the team of developers; and even more configuration at the user-level, e.g., which register to show

     [WRS] Again, is this extending the Multicore Visualizer, or providing "building block" support for custom views in the framework? We'd need some examples of what people would like to achieve to know where this building block / configuration support should properly live.

     [Khouzam] This is an ambitions and vague requirement. I suggest we revisit it once we have better support for customizations and layers.

10. When doing drag-selection, it would be convenient to also drag-deselect (DONE)

Comments above from:

• [WRS] Bill Swanson, Tilera Corporation
• [Khouzam] Marc Khouzam, Ericsson

Multi-chip debugging

The CDT community is mostly focused in enabling multi-core debugging to the CDT. However, support for multi-chip debugging would also be interesting where you have chips->cores->processes->threads. Current solution will be to use multiple debug sessions (multiple GDBs). We will need GDB support to have a better integrated solution using a single GDB; using a single GDB would allow, for example, to support synchronous control of different chips.

Watch view

A new 'Watch' view would be a good addition to the CDT. This view (see ‘watch’ command in unix) would provide a way for the user to request that a console command or set of commands be executed at specific times such as:

• after every state-changing operation
• at a periodic interval
• on particular events (suspend, running)
• based on filters (when thread1 stops)
• watchpoints
• catchpoints
• breakpoints
• etc

It may be good to look at what is provide by the IAR Debugger where it is apparently possible to have a watch window which can be used to watch expressions which are updated in a specifiable interval.

1. This concept could be extended to eclipse operations, like refreshing a view automatically on those triggers
2. We could mimic a breakpoint condition/commands to allow the user to 'run a script' whenever one of the above triggers occurs. This script could be a gdb python script
3. The view should always refresh if the context changes, unless it is pinned
4. This watch view would handle its output in the following way:
   1. There should be a standard scrolling mode
   2. There should also be a fixed size output that only shows the last output.We could then “page up” to jump to the previous output repeatedly.
   3. We should have a toggle to choose between the two modes
5. Another enhancement would be to highlight the changes from the new output compared to the previous output. This would allow the user to quickly see what changes. A nice way of showing change dynamically is firefox’ javascript debugger who shows the new html code written in red to indicate what the single step actually created in html. This could be disabled by the user if the data is too different.

Enhancements to the Modules view

The modules view is used to show the list of currently used dynamically linked libraries. The view is updated whenever a new library is loaded or an existing one is unloaded (although there is currently a bug that makes the update not happen). The view also shows information about the libraries such as file location, base address and size. Below are some requirements for the Modules view.

Note that the Watch view described above may be more valuable than the below enhancements

1. The view should be context-aware and show what is currently loaded based on the current context (process/core)
2. Although modules can change when a process/core is running, it only needs to be refreshed once the process/core stops, just like for variables and such.
3. Refresh of the view should be based on GDB's new MI events: =lib-loaded and =lib-unloaded
4. Since the modules view is so simple for GDB, as to repeatedly issue the 'info sharedlib' command, the current behavior of the view could be replaced by the

new proposed Watch view which would send the ‘info sharedlib’ command upon the proper triggers.

Enhancements to Disassembly view

The Disassemby view shows the running code as disassembled by GDB. The view allows navigating through that disassembled code, to set breakpoints/tracepoints, and to show the disassembled code interleaved with source code. Below are some requirements relevant to the Disassembly view.

1. Should support different memory spaces and allow the user to choose which memory space to show the disassembly for.
2. Instructions that correspond to the same source code line should be identified. An example is shading them to the same color, and/or a vertical bar in the margin (see ARM product http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0446d/BABEIJHB.html)
3. From editor it should be possible to open the disassembly view for the currently selected line in the editor (maybe a context-menu).
4. We should have an optional synchronization mechanism that would keep the disassembly view showing the matching source line as the editor when the editor cursor moves. All instructions corresponding to the source line should be shown if possible, with priority given to the first instruction
5. Support for parallel instructions in the disassembly view
   1. If all // instructions are on the same line, Eclipse can probably handle it already
   2. If we want to show // instructions on different
      1. PC highlighting should highlight all the // instructions lines
      2. Address should only be shown for the first of the // instructions
      3. Setting a breakpoint could be ok to limit to the // instruction that has an address if necessary
6. Syntax highlighting for Disassembly code. This may already be available through CDT extension points

Assembly in the Editor

It would be nice to be able to use the Editor to display the assembly code as generated by the compiler and to step and perform the different debugging operations in that editor. Maybe this would fit in the Disassembly view, but showing the assembly code instead. The assembly code is valuable beyond the disassembly code because it contains more information given by the compiler. A way to show the instruction manual for an assembly instruction would be valuable.