Difference between revisions of "CDT/Archive/20112012EricssonInvolvement"

Revision as of 16:31, 8 February 2013

This page describes Ericsson's involvement in the C/C++ Development Toolkit (CDT) as well as the GNU Debugger (GDB). Ericsson's involvement has multiple facets:

1. New features are developed directly by Ericsson's employees
2. New features are contributed by other companies with the help of committers working for Ericsson
3. New features are implemented by companies sponsored by Ericsson

Below is a list of features implemented by Ericsson or with Ericsson's help or sponsorship.

2013

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.

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.

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

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).

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".

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.

Partitioning of large arrays

CDT now displays large arrays as collections of partitions.

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.

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

Project-less debugging

CDT can now be used to debug any binary, without needing to specify or even create a project in Eclipse. This is supported for all types of debugging (local, remote, attach, and post-mortem sessions).

Furthermore, for an attach session (local or remote), there is even no need to specify the binary; for a local attach, GDB can find the binary automatically, while for a remote attach, CDT will prompt for it when it needs it.

Support for full pretty-printing of complex structures

With the proper setup of GDB, DSF-GDB will now print complex structures such as Maps, Lists and Vectors, in a user-friendly fashion, within the Variables and Expressions views, as well as the advanced Debug hover of the Editor. See below on how to setup GDB for this feature to work.

Without pretty-printing:

With pretty-printing:

Configuring GDB for pretty-printing:

• You will need to have python installed on your machine

• If you want to pretty-print STL structures, you will need the Python pretty-printers for STL. Check-out the latest Python libstdc++ printers to a place on your machine. (Note that you can create your own pretty-printers for any complex-structure). In a local directory, do:

   svn co svn://gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/python

• You will need to create a gdbinit file to tell GDB where the pretty-printers are. Create a gdbinit file with the following 6 lines. The path needs to match where the python module above was checked-out. So if checked out to: /home/marc/gdb_printers/, the path would be as written in the example:

 python
import sys
sys.path.insert(0, '/home/marc/gdb_printers/python')
from libstdcxx.v6.printers import register_libstdcxx_printers
register_libstdcxx_printers (None)
end

• You will need GDB 7.0 or later. GDB 7.2 is recommended because it has some bug fixes for the pretty-printing.

• In your DSF-GDB launch, make sure you use the right GDB and the right gdbinit file

Multi-process Debugging

CDT now supports debugging multiple processes in a single debug session. It allows to attach/detach and start/stop processes repeatedly and easily.

Requirements:

• GDB 7.2 or greater
• Currently, only Non-Stop debugging sessions support multiple processes.
• Note that this feature was developed and tested on Linux systems, and may not work on Windows.

To use multi-process debugging, simply launch an application as you normally would, locally or remotely, using gdbserver, and make sure to select Non-stop mode in the Debugger tab. Then, use the Debug View's "Connect" button to trigger a dialog with allows you to either attach to a running process, or to create a new process using the "New..." button. Currently, the "New..." button is only supported for Local debug sessions.

You will then have the newly selected process added to your debug session, where you can control it and examine it. You can use the "Disconnect" button to remove processes from your debug session, or you can use the "Connect" button to add new ones.

An option to automatically attach to a forked process is also available. This means that whenever any process you are currently debugging forks a new process, that new process will be added to your debug session.

Pin & Clone

Variables, Expressions, Registers, Disassembly, and Memory Browser now supports opening multiple instances, and pin the view input to the selected debug context(s) in the Debug view. This can be used, for example, to easily compare the data of different threads.

C/C++ Remote Application launch

The optional "C/C++ Remote Application" launch configuration type has been made permanent for CDT.

The "GDB (DSF) Remote System Process" launch delegate has been renamed to "GDB (DSF) Manual Remote Debugging" and has been moved from "C/C++ Application" to "C/C++ Remote Application". As was the case for CDT 7.0, the optional RSE Remote Launch delegate of org.eclipse.cdt.launch.remote, is still part of "C/C++ Remote Application".

This optional remote launch now provides a new DSF-GDB-based launch delegate called "GDB (DSF) Automatic Remote Debugging". This launch is very similar to the existing "GDB (DSF) Manual Remote Debugging" delegate, except that the automatic one will automatically download the application to the remote target and start gdbserver with the application.

By default, the user will be shown the "GDB (DSF) Manual Remote Debugging". However, if the optional feature of Remote Launch is installed, the default will automatically become the more feature-rich "GDB (DSF) Automatic Remote Debugging".

Finally, the run-mode RSE Remote Launch delegate no longer shows the Debugger or Source tabs, since they were not relevant, in run-mode.

Non-stop attach does not interrupt the process

Attaching to a process in non-stop mode will no longer interrupt the process.

Support for pending breakpoints

When a breakpoint is set in a dynamically-linked library that was not loaded yet, the breakpoint will now work, once the library is loaded. This feature is currently only supported when using GDB 6.8 or later.

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.