DSDP Device Debugging 1.1 New and Noteworthy



Debugger Services Framework (DSF)

The Debugger Services Framework is a new API for integrating debuggers into Eclipse.  It is an alternative to the Standard Debug Model API in Platform and it leverages the new Flexible Hierarchy API that allows extensive control over the debugger views' contents.  It is also designed to help achieve better performance when debugging applications on slow or remote targets.

From the user's perspective, debuggers based on DSF should appear, for the most part, identical to debuggers based on the standard API.  This is one of the goals of DSF: to preserve the existing workflows and user paradigms.  Most DSF features are targeted towards the developers of debugger integrations and are designed to help achieve better performance and maintainability, however there are some user-facing features which are described here.

Smooth Stepping

 As stepping through code is one of the key functions of a debugger, a lot of energy in DSF development went into perfecting the user experience of this feature.  DSF stepping uses the following optimizations:
  • Step actions are always enabled - This means that the user can click on the step toolbar button and each click is executed as soon as the target is ready.  Similarly, the user can press and hold a short-cut key for a step operation and step either as fast as the target is capable, or as fast as the keyboard repeat rate will allow.
  • Instruction Pointer icon in editor is updated after each step - The stepping speed is controlled to make sure that the editor is able to keep up with the target.  This gives the user continuous visual feedback of stepping progress.
  • Debug view update after a step is delayed - There is an almost invisible delay (200ms) in updating the stack frames in the Debug view. This delay prevents the refreshing of the Debug view from taking up system CPU time and delaying stepping.  The top stack frame is excepted from this delay and is updated after every step.
  • Changing selection in the editor is also delayed - It turns out that changing the selection in the editor takes a lot of CPU time (because all the actions which act on the current selection need to be updated).  Therefore, when user is stepping fast enough, DSF also avoids changing the selection until the stepping stops.
The net result of all these optimizations is that on a modern system, and when debugging a local process,  the user can step as fast as the keyboard repeat rate. There are cases, however, where this is not desirable.  Therefore DSF provides a preference where the user can force a minimum delay between each step.


Performance preference settings for DSF

Limited Stack Trace Length

 A program with a deep stack trace can make the Debug view difficult to use and can degrade performance.  DSF offers a simple feature to deal with this problem.  When a program first suspends, only a limited set of stack frames is shown to the user.  A special last element in the stack trace, labeled <...more frames...> is shown if there are more stack frames available.  When the user double-clicks on this element, the next chunk of the stack trace is shown.  The initial stack frame limit is set via a preference, and the size of the next chunk doubles with each double-click.

Debug view containing a limited stack trace.  Double-clicking on "<...more frames...>" causes more frames to be retrieved.

Synchronizing stepping with view updates

 Stepping with a DSF-based debugger is optimized to achieve maximum speed while still giving user feedback about the location of the instruction pointer in the code.  However, in certain scenarios the user also needs to monitor a particular variable or register until it reaches a certain value, while stepping.  DSF offers a mode where the stepping speed is controlled so that the visible debugger views are also updated after every step.  This mode is controlled by a preference setting.

Update Policies

 When debugging a process running on a slow target, it is often desirable to restrict the amount of data that is retrieved by the debugger.  One way to achieve this is to close or hide some of the the debug views, but this is not convenient because it forces the user to constantly re-arrange his views.  Instead, DSF allows the user to disable automatic updating of debugger views and to update them on request only. 


Update Policy sub-menu in the Variables view.

There are three components of this feature:

  • Update Policy selection menu - The Variables, Registers, Expressions, and the Debug view each have an Update Policy sub-menu in their view menu.  This menu let's the user choose between three different update policies:
    • Automatic - The view is updated with every event.  This is the standard view behavior.
    • Manual - The view is updated only upon user request (i.e. using the Refresh action)
    • Breakpoint Hit - The view is updated only when a breakpoint is hit, or upon user request.
  • Refresh actions - The user can request that a view be updated using the refresh action appearing on that view's toolbar.  This action is linked to the generic File->Refresh menu action, and its associated keyboard binding.  Also there is a Refresh All action added to the Window menu and toolbar which refreshes all the views.
  • Debug Update Modes action set - In order to avoid unnecessary clutter in the UI for applications that do not use update policies, all of the aforementioned menu and toolbar contributions are enabled using this action set.  I.e. users can show/hide the Update Policy menu and the refresh actions using the Window->Customize Perspective dialog.

Debug Update Modes action set selection.

Expressions View

 DSF takes advantage of new APIs in Debug Platform to enable additional features in the Expressions view.

Column-Based Display

Variables, registers, register groups, etc, are all displayed in the Expressions view identically to how they are shown in their native views.  This also means that the user may use in-line editing to change the values of those variables and registers.  The Expressions view is still based on text expressions, which are parsed to determine the element (variable, register, bit field, etc.) that they represent. 

Expressions view showing a variable value being edited.

Editing Expressions In-Line

 Just as values can be edited in-line, the column based display also allows the expressions to be edited without opening a new dialog.  Simply select the expression to change and type in the new name.

Editing an expression name.

Creating New Expressions In-Line

 Finally, just as editing existing expressions can be done in-line, adding a new expression can be accomplished by selecting the Add new expression entry, and typing in the new expression name.

Number Format

 Viewing variables, registers, and expressions in different formats is a typical debugging use case. DSF provides a couple of generic mechanisms for doing this. 

Selection Menu

 Each of Variables, Registers, and Expressions views allows the user to select the default format to use in displaying the elements in the given view. 

Note: changing the number format for individual elements is not yet supported.

Menu in Expressions view for selecting the default number format to use.

Detail Pane

 DSF also provides a detail pane for viewing a given element using different formats.  Simply selecting a variable, register, etc., causes the selection to be shown in the detail pane in the different available formats.

Details pane showing the result of evaluating "1+1" expression in different number formats.

GDB Debugger

The Device Debugging project is using the GDB debugger integration as a reference implementation of the DSF API.  The goal of this effort is to provide a debugger that has feature parity with the GDB debugger which is already part of the CDT project, while taking advantage of the unique features that DSF affords.  The following sections given an overview of the DSF-GDB debugger features and its main differences with CDI-GDB. 

Note: This document will use the term CDI-GDB to refer to the curren t GDB debugger integration in the CDT project.

For GDB users, the most important limitation of DSF-GDB implementation may be the fact that it only supports GDB versions 6.7 and newer, and is tested only on the Linux platform.  Meanwhile, the CDI-GDB integration is known to work with GDB versions as old as 5.2.1.

Launching

 There are three types of launches that are supported:
  • C/C++ Local Application - Starts a new process under the debugger's control, on the local system.
  • C/C++ Attach to Running Application - Attaches the debugger to one or more running processes on the local system or a remote system.
  • C/C++ Remote Application - Starts a new process under the debugger's control, on a remote system.

In the launch configuration dialog, each of these launch types (shown below) has a star overlay in the icon and the (Experimental - DSF) postfix in the label, in order to distinguish them from the CDI-GDB debugger.  The user can edit the launch configuration parameters using the launch configuration tabs described below.


Different C/C++ launch configuration types in launch dialog.

Main Tab

Allows the user to specify the executable used for debugging.  It is almost identical to the one used in CDI-GDB except:

  • The Input/Output of the debugged process is always connected to a terminal and therefore, the relevant option is no longer available.
  • In the case of the launch attaching to a running application, the project and executable are optional, as they can be detected automatically by GDB.

Arguments Tab

 Allows the user to specify parameters for the new process being launched in the debugger.  It is used only for the "C/C++ Local Application" launch, and it is identical to the tab used by CDI-GDB.

Debugger Tab

 This tab follows the same format as the corresponding tab in CDI-GDB but works a little differently:
  • In the Debugger drop-down, user can only select "gdb/mi" for local debugging, and "gdbserver" for remote debugging.
  • There is no set of Advanced options to automatically track variables and/or registers. This ability is provided by Update Policies. See also the Update Policies section.
  • There is no option to select a GDB command set or protocol version.  These are calculated automatically.
  • There is no option to set verbose console mode.
  • There is no option to specify to use full file paths to set breakpoints.
  • The Non-stop mode check box allows user to enable the non-stop multi-threading feature in GDB 7+ (still in development).  See also the Non-Stop Multi-Threaded Debugging section.
  • There is no option to stop on shared library events.
  • The Use shared library symbols for debugged applications check box is used in specific attach scenarios where GDB should use the Shared Libraries directories to find the executable.


Debugger Tab - Used for specifying options specific to the debug engine.

Source Tab

 This is a standard debugger tab and it allows the user to configure how the sources locations in the executable file are mapped to the file system.    The source lookup options are identical to CDI-GDB.

Common Tab

 This tab is shared by all Eclipse-based debuggers and it allows the user to configure additional standard debugger features (e.g. console output and launch configuration storage location).

Debug View

Layout

 The layout in the Debug view follows the standard conventions and there are only minor differences with CDI-GDB with respect to features:
  • The Show full paths option in the view menu is not supported.
  • When a program runs to completion the GDB process remains active to allow the user to interact with the debugger through the console.


Layout of elements in Debug view.

Commands
The debugger supports the same run control actions and program control actions as CDI-GDB, with the exception of the Run to line action
  • Resume
  • Suspend
  • Step Into, Step Over, Step Out
  • Terminate
  • Disconnect
  • Set Instruction Stepping Mode
  • Restart (reloads current program without terminating and relaunching)
Additionally  the DSF-GDB integration supports the Connect action (), where the user can repeatedly attach to other running processes using the multi-process support in GDB 7+ (still in development).  See also the Multi-Process Debugging section.

Non-Stop Multi-Threaded Debugging

The upcoming release of GDB (version 7.0) will support a new mode for debugging multi-threaded applications.  In this mode, called "non-stop", some threads can be suspended while other threads remain running.  DSF-GDB developers have been working closely with the GDB community to support this feature even as the release is still being finalized.


Debug view showing Thread[3] running while the other two process threads are suspended.

Multi-Process Debugging

The upcoming release of GDB (version 7.0) will support the debugging of multiple processes at once.  This will allow the same DSF-GDB launch to control and debug more than one process at the same time.  DSF-GDB developers are working closely with the GDB community to support this feature even as it is being added to GDB.


Debug view showing three processes being debugged at the same time.

Disassembly

 The disassembly view is somewhat different from the disassembly available in the CDI-GDB debugger.  To open the disassembly view the user must select the DSF Disassembly from the Window->Show View menu.  The main difference from CDI-GDB is that the disassembly view has an infinite scrolling range.  As the user scrolls up and down, new section of memory is disassembled.  Also the user can use the Go to Address action to disassemble any location in memory.


Disassembly view showing mixed source and disassembly.

Variables

 This view is also similar to CDI-GDB, but it has some differences and is missing some key features:
  • The Address column is supported to show the address of a given variable.
  • Elements of large arrays are shown in a flat list and are not broken down into chunks.
  • Showing global variables is not yet supported.
  • Casting variables to a different type is not yet supported.
  • Icons corresponding to variable type are not yet supported.
  • Showing variable information without columns is not yet supported.


Variables view.

Registers

 The Registers view is similar to CDI-GDB with the following differences:
  • The user cannot define custom register groups.  By convention all registers are shown to be in the General Registers group.
  • The Type column indicates whether the register is Unsigned or Float, rather than using the type returned by the expression evaluator.
  • Vector registers do not have sub-elements which show the register value subdivided into different sizes.  Instead, the register value text has this information.


Registers view.

Memory

 The memory view supports the same features as CDI-GDB but also the Traditional Memory Rendering. See the Traditional Memory Rendering section.

Breakpoints

 DSF-GDB uses the same breakpoint objects as the CDI-GDB integration.  This means that the same breakpoint created in a CDT editor will work with either debugger.  However, there are a couple of CDI-GDB features which are not supported:
  • Reapplying breakpoints when shared libraries are loaded is not supported.  CDI-GDB can suspend the debugger after each shared library is loaded to try to insert any breakpoints that previously failed. 
  • Event breakpoints are not yet supported.

Modules

 The Modules view allows the user to see what executable images and shared libraries are currently loaded in the debugger.  The detail pane shows additional information including the address and size of each module. 


Modules view

CDI-GDB has a a couple of features which are not yet supported:
  • Loading symbols for selected or all modules.
  • Browsing symbol data parsed from the Executable by binary parsers in CDT.  This feature is also available through CDT's Executables view.

Executables view

CLI Console

 The GDB debugger is a command line debugger and supports a rich interactive Command Line Interface (CLI).  This feature is available through the console view and can be used in conjunction with the graphical debugger views.  The user needs to select the gdb process in the Debug view or on the Console toolbar in order to access the CLI console. The option to show MI commands and responses that the IDE sends and receives from GDB is not yet supported.


Console view showing user's CLI commands and responses.

Signals

 CDI-GDB supports a Signals view where the user can configure how signals are handled and to resume the process with a given signal.  DSF-GDB does not yet support this feature.

Traditional Memory Rendering

The Traditional Memory rendering, available as an independent feature from the Device Debugging project, is an alternative representation of memory in Eclipse.  It combines the numerical representation of memory on the left side with the text-decoding on the right side, which is the traditional layout of the memory view in many other IDEs.


Traditional Memory Rendering

IP-XACT Editor

The IP-XACT Editor is a tool for editing and validating IP-XACT documents.  This tool was contributed to Device Debugging project by the ARM Corp. and as of 1.0 release supports the IP-XACT v1.4  specification.