CDT/Archive/20112012EricssonInvolvement

2013

Enhanced GDB console support

CDT is being improved to update its views with any change made to GDB by the user from the GDB console. Updates are being added gradually and the final goal is to allow the user to perform any command from the GDB console, and have CDT stay synchronized with the changes.

Debugging multiple processes within one debug session

Debugging a new executable in the same debug session has been improved for GDB versions starting from 7.2. "Debug New Executable" action has been added to the context menu of the Debug view.

The dialog for specifying an executable to debug for local sessions has been changed.

The ability to debug a remote executable using gdbserver has been added.

Memory and variables

Memory and variables modified from the GDB console are now updated in the Memory, Memory Browser, Variables and Expressions views. This feature requires GDB 7.6 or higher.

Reverse debugging state

CDT will now properly update the status of reverse debugging if its state is modified through the GDB console. This feature requires GDB 7.6 or higher.

2012

Enhanced Expressions

The Expressions view has been extended to allow the user to manually create enhanced-expressions. Enhanced-expressions define a set of expressions which can be easily described using glob-pattern matching. The user specifies an enhanced-expression by prefixing it with '='. For example:

• pattern-matched sorted groups of local variables, where the symbols * [] ? can be used e.g.,

=v?r     -- Will show local variables starting with a 'v' and ending with 'r' with a single character in between
=*       -- Will show all local variables of the selected stack frame in sorted order (the '=' is optional for this expression, i.e., '*')
=*x      -- Will show local variables ending with 'x'

• array ranges including glob-expressions

=array[30-40]        -- Will show array elements from 30 to 40
=array[1-5,20,30-31] -- Will show array elements from 1 to 5, 20 and 30 to 31
=array?[1-5]         -- Will show array elements from 1 to 5 for any array starting with 'array' followed by a single character

• pattern-matched sorted registers groups, where the symbols * [] ? can be used e.g.,

=$e?x     -- Will show all registers starting with 'e' and ending with 'x' with a single character in between
=$*       -- Will show all registers (the '=' is optional for this expression, i.e., '$*')
=$*x      -- Will show registers ending with 'x'
=$st[3-5] -- Will show registers $st3, $st4, $st5

• semi-colon-separated, individually sorted groups of expressions, e.g,

var1; var2 -- Will create a group containing both var1 and var2 
$eax; var1 -- Will show a group containing register $eax and variable var1
var1; $e*  -- Will show a group containing variable var1 as well as all registers starting with 'e'

This feature allows to quickly define multiple expressions that interest the user. Because groups are created from these special expressions, they can be collapsed when uninteresting and re-expanded later, without having to be re-entered by the user.

Note that the comma (,) is not allowed as a group separator as it is used within valid expressions that use templates (e.g., ((((((class std::_Vector_base<int, std::allocator<int> >) v))._M_impl))._M_start)).

OS Resources View

CDT has a new view called "OS Resources". This view will display different information about the resources of the operating system. For example, it can give a list of all processes running on the target. The view will display the information as provided by GDB.

As of writing, GDB supported the following information:

Processes             - Listing of all processes
Process groups        - Listing of all process groups
Threads               - Listing of all threads
File descriptors      - Listing of all file descriptors
Sockets               - Listing of all internet-domain sockets
Shared-memory regions - Listing of all shared-memory regions
Semaphores            - Listing of all semaphores
Message queues        - Listing of all message queues
Kernel modules        - Listing of all loaded kernel modules

Notes:

• For performance reasons, the view is not automatically refreshed. Press the Refresh button on the the view toolbar to fetch the latest information. Hovering over this Refresh button will display the time at which the information was last obtained.
• Columns can be re-sized.
• Columns can be removed or added using the view menu.
• Entries can be ordered by column by pressing on the column header.
• When doing debugging of a remote target, the information in the view pertains to the remote target.

This feature requires GDB 7.5 and higher. Furthermore, as of GDB 7.5, this feature only works for Linux.

Breakpoint Filtering

The CDT has enhanced the standard behavior of the "Show Breakpoints Supported by Selected Target" option of the Breakpoints view. Using this option with the CDT will now only show breakpoints that are actually applicable to the current debug session. Therefore, when debugging a C/C++ application, the user will not be bothered with the breakpoints set in the code of an another C/C++ application.

For backwards-compatibility, a preference is provided to revert this new behavior to the original one. The original behavior of this option is to have the Breakpoints view show all breakpoints that are of the same type as the current debug session. For example, if debugging Java, only Java breakpoints would be shown, and if debugging C/C++ only C/C++ breakpoints would be shown. This preference can be found under "C/C++ -> Debug -> GDB -> Use aggressive breakpoint filtering".

Enhanced GDB console support

CDT is being improved to update its views with any change made to GDB by the user from the GDB console. Updates are being added gradually and the final goal is to allow the user to perform any command from the GDB console, and have CDT stay synchronized with the changes.

Breakpoints, watchpoints and tracepoints

Breakpoints, watchpoints or tracepoints set from the GDB console are now shown in the Breakpoints view. All breakpoint related GDB commands are supported and synchronized with the UI. No support for catchpoints yet. This feature requires GDB 7.4 or higher.

Breakpoint actions to control reverse debugging

It's now possible to control the enabling, disabling and toggling of the reverse debugging mode, through breakpoint actions. The reverse debugging mode can be useful to debug, but has a significant performance cost when enabled. Using the new breakpoint action to enable the reverse debug mode, one can program a breakpoint to enable that mode in the vicinity of the suspected source code. That way, until that point is reached, no performance impacts are felt.

To use this feature, right-click on a breakpoint and select "Breakpoint Properties". Then in the left page, chose "Actions". Then click "New". In the new dialog, select the Action Type "Reverse Debug Action". Then chose if the action should enable, disable or toggle the reverse debug mode. Finally chose a name for the action. When done, click "Ok"

The newly created action will appear in the list of available actions, that can be attached to any breakpoint To attach it to the current breakpoint, click on "Attach".

Note: For the reverse debug breakpoint actions to work, reverse debugging must be available in the current debug session. For instance, it will not work if "non-stop" mode is active.

2011

Multicore Visualizer View

CDT now optionally includes a Multicore Visualizer View. This view displays a graphical representation of the state of the current application. It allows one to click- and drag-select groups of processes/threads, and apply debugging commands to them directly from the visualizer. Selections made in the Visualizer View are reflected automatically in the Debug View, and vice versa. The Multicore Visualizer View is designed to scale to large numbers of cpus and cores-per-cpu on both current and future multicore hardware.

The Multicore Visualizer View is meant to serve as a high-level visual overview of the current application, and can be used in tandem with the Debug View, which provides more in-depth detail.

The Multicore Visualizer View is just one example of a visualizer based on the underlying Visualizer Framework plugin. This provides a pluggable, extensible platform for developing visual development tools of this kind.

Note that the Multicore Visualizer will only work using a Linux target; it will not work debugging on a Windows or Mac target. This is a current limitation of GDB which does not provide information about cores, for those targets (at writing, GDB is at version 7.4).

This feature was completed on February 10th, 2012. For details see Bug 335027

The Multicore Visualizer is an optional feature of the CDT and must be installed manually. The feature is called "C/C++ Multicore Visualizer". Installing it will install both the Multicore Visualizer and the Visualizer Framework. If you only want to install the Visualizer Framework (to build your own visualizer), you can install that feature by itself; it is called "CDT Visualizer Framework". Once the features are installed, you can access the Multicore Visualizer (or any other visualizer) by opening the view called "Visualizer".

Partitioning of large arrays

CDT now displays large arrays as collections of partitions.

This feature was completed on January 26th, 2012 as part of Bug 365541

Edit Breakpoint on Create

It is no longer necessary to first create a CDT breakpoint, then edit its properties. Properties such as enabled, ignore count, condition, temporary, can be set while creating the breakpoint.

There are several methods to open the properties dialog before creating the breakpoint:

• Add Breakpoint action.
  1. In the editor or the disassembly view, bring up the popup menu on the gutter.
  2. Select the Add Breakpoint... menu item.
  3. This brings up the breakpoint properties dialog for a line breakpoint pre-filled with the breakpoints location.
• Control-Double Click
  1. Hold the Control key while double-clicking on the editor gutter.
  2. This brings up the breakpoint properties dialog for a line breakpoint pre-filled with the breakpoints location.
• Control key with Toggle Method Breakpoint
  1. Open the editor's Outline view.
  2. Right-click on a method to bring up the popup menu.
  3. Hold the control key while selecting the Toggle Method Breakpoint action.
  4. This brings up the function breakpoint dialog pre-filled with the method name.
• Add Watchpoint (C/C++)
  1. In the Breakpoints view, open the view menu.
  2. Select the Add Watchpoint (C/C++)... action.
  3. This brings up the watchpoint properties dialog.
  4. User must enter the watchpoint expression.
• Add Function Breakpoint (C/C++)
  1. In the Breakpoints view, open the view menu.
  2. Select the Add Function Breakpoint (C/C++)... action.
  3. This brings up the function breakpoint properties dialog.
  4. User must enter the function expression.

Image: The breakpoint properties dialog for a line breakpoint about to be created.

Breakpoint Toggle Short-Cuts

The Toggle Breakpoint action in the editor and disassembly view menu now supports new behaviors when used with modifier keys:

• Hold the Shift key while double-clicking on an existing breakpoint in order to enable or disable the breakpoint.
• Hold the Control key while double-clicking on an existing breakpoint in order to bring up the breakpoint properties dialog to edit the existing breakpoint.
• Hold the Control key while double-clicking on a location with no breakpoints, in order to bring up the breakpoint properties dialog to create a new breakpoint.

Image:The editor gutter popup menu with the hints for the new accelerators.

Function Breakpoint Manual Entry

There is a new option for creating a function breakpoint:

1. Open the Breakpoints view menu.
2. Select Add Function Breakpoint C/C++.
3. Fill in the function name or expression and select OK to create breakpoint.

Advanced character encoding support

CDT now supports the handling of different character encodings for strings and wide character strings while debugging. This includes full support for Unicode encodings and many other popular encodings as well. You can select the character and wide character encoding within the Debug preferences.

CDT will then correctly display strings according to the selected encoding while debugging.

Note that this feature requires GDB version 7.0 or later. This feature was completed on March 7th, 2012 as part of Bug 307311, Bug 367456 and Bug 370462.

Timeout support for GDB commands in DSF/GDB

Timeouts for GDB commands are now supported in DSF/GDB. The feature is optional and disabled by default. The timeout values are configurable. When the feature is enabled, custom values can be assigned to some commands, all other commands use the default value. This feature was completed on April 17th, 2012 as part of Bug 361934.

Multi-select Resume/Suspend operations

CDT now allows to perform a Resume or Suspend operation on multiple selections of the same debug session. Because such a concept only adds value in a Non-Stop debug session, it is only supported in such a session (see Non-Stop Debugging). The behavior of a multi-selection Resume/Suspend is as follows:

• Any selected stack frames implies a selection of their corresponding thread.
• If one or more threads are selected (not processes) and the resume/suspend operation is triggered, each selected thread on which the operation is currently valid will be resumed/suspended.
• If one or more processes are selected (not threads) and the resume/suspend operation is triggered, each selected process will be resumed/suspended. Resuming/suspending a process implies resuming/suspending each one of its threads on which the operation is currently valid.
• If both thread(s) and process(es) are selected, and the resume/suspend operation is triggered, each selected process will be resumed/suspended, and each selected thread which is not part of any selected process will be resumed/suspended. The idea is that if a process is being resumed/suspended, each of its threads will be automatically resumed/suspended, and therefore, should not be resumed/suspended a second time because it is also selected.

As hinted above, CDT takes a permissive approach to multi-select resume/suspend. This means that if a multi-selection includes both stopped and running threads, a resume operation is still allowed, and only the suspended threads will be resumed; similarly, on such a multi-selection, a suspend operation is allowed, and only the running threads will be suspended.

Example

In the above screenshot if the user were to press the Resume button with the current multi-selection the following would happen:

1. The Consumer process node is selected, therefore the entire process will be resumed. This means that the suspended threads 7 and 9 will be resumed, while threads 6, 8 and 10 will be ignored, as they are already running.
2. Note that the fact that threads 9 and 10 are selected is ignored, as those threads are part of the selected Consumer process, which will be resumed.
3. Stack frames doWork() and work() are selected and belong to thread 4, which becomes implicitly selected in their place. Thread 4 will therefore be resumed.
4. Thread 2 is selected and suspended, and will be resumed.
5. Thread 5 is selected but running, so it will be ignored.

Show only suspended threads in Debug view

CDT now has an global preference that allows to only show the suspended threads within the Debug view. When dealing with a large number of threads, a user is typically interested by the threads that are being inspected (suspended ones) and does not care about the running ones. Using this preference, all running threads will not be shown in the Debug view. Note that when a thread is stepping it will remain visible, although it is technically running. The process element of the Debug view will show how many threads are currently being filtered from view.

The below example shows the exact same debugging session. The first screenshot only shows suspended threads, while the second shows all threads.

Below shows how to access the preference, which is disabled by default.

Default Postmortem file location

CDT now allows the user to specify a default directory for the location of core files for a postmortem launch when the prompt is triggered. Since a postmortem launch can easily be re-used for different core files of the same binary, this feature helps reduce the amount of navigation needed to select a core file. Note that specifying the actual core file is still supported, as well as leaving the entire field blank, which will also trigger the prompt, but use the default directory for its starting location.

Note that this 'core file' field supports the use of variables such as ${workspace_loc}.

This feature applies to both core files and trace files.

Enhancements to Tracepoints

With the use of GDB 7.4, some new features are available within Eclipse.

• Live enable/disable of C/C++ Tracepoints
  • Tracepoints can now be enabled and disabled at any time after a trace experiment has been started, and will immediately take effect within the ongoing experiment.
  • Note: Although GDB 7.4 seems to allow a tracepoint to be created during a trace experiment and will add it to the ongoing experiment, this behavior seems to have some issues. One of which is that deleting a tracepoint during an experiment will not remove that tracepoint from the ongoing experiment. Until this is fixed in GDB, it is recommended that the user stick to enable/disable operations during a tracing experiment.
    
• Smaller Fast tracepoints
  • On 32-bit x86-architectures, fast tracepoints can now be placed at locations with 4-byte instructions, when they were previously limited to locations with instructions of 5 bytes or longer.
• Tracepoint collecting of Strings
  • The tracepoint Collect action now has an option to request to collect character pointers as strings. It tells GDB to effectively dereference pointer-to-character types and collect the bytes of memory up to a zero byte. An optional integer limit sets a bound on the number of bytes that will be collected.

Show the actual variable type based on RTTI

With GDB 7.5.1 or higher CDT could show the actual variable type (not the declared one) in Variables and Expressions Views. Consider the following example:

   struct SuperInterface {
       virtual ~SuperInterface() {}  // enable RTTI for Interface class
   };
   
   struct TheImplementation : public SuperInterface {
       TheImplementation(int _v1, float _v2)
           : someField(_v1), anotherField(_v2) {}
   
       int someField;
       float anotherField;
   };
   
   
   int main() {
       SuperInterface* i = new TheImplementation(42, 4.2);
       return 0;     // [Launch debug until here]
   }

Launch the debugging session and run until return statement:

This feature is enabled by default and will work if you have the proper GDB version (7.5.1 or higher) and RTTI generation enabled (enabled by default in gcc), however it could be turned off in preferences:

Note that a bug was found in GDB 7.5 which could affect the display of other variables or registers. GDB 7.5.1 should be used with this feature.

2011

Multi-select attach dialog

CDT now allows selecting more than one process to attach to in a single user operation. The bottom pane is used to see which processes have been selected. If multi-process debugging is not supported with your debug session (needs GDB >= 7.2 and NonStop enabled), only the first process will be attached to.

Support for Fast Tracepoints

CDT now allows the user of fast tracepoints, as supported by GDB. Fast tracepoints use an instruction jump instead of a trap for efficiency. Fast tracepoint need a minimum of space to be inserted in the program and therefore, may fail to be set at certain locations. For fast tracepoints to work, a special library called the in-process agent (IPA), must be loaded in the inferior process. This library is built and distributed as an integral part of gdbserver. Please see the GDB documentation for more details.

The user can select between three tracepoint modes in the launch:

1. Fast: Only use fast tracepoints. No tracepoint will be planted if a fast tracepoint cannot be used.
2. Normal: Only use normal tracepoints.
3. Automatic: Attempt to use fast tracepoints. If a fast tracepoint cannot be used, automatically use a normal tracepoint.