Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

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

< CDT‎ | Archive
Line 5: Line 5:
  
 
Below is a list of features implemented by Ericsson or with Ericsson's help or sponsorship in 2011-2012.
 
Below is a list of features implemented by Ericsson or with Ericsson's help or sponsorship in 2011-2012.
 
== 2012  ==
 
  
 
=== Multicore Visualizer View  ===
 
=== Multicore Visualizer View  ===
Line 58: Line 56:
  
 
=== OS Resources View  ===
 
=== OS Resources View  ===
 +
 +
Ericsson sponsored a joint CDT/GDB feature to provide the user with OS Resource information.
  
 
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.  
 
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.  
Line 91: Line 91:
 
[[Image:BpFilter.png]]  
 
[[Image:BpFilter.png]]  
  
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++ -&gt; Debug -&gt; GDB -&gt; Use aggressive breakpoint filtering"''.  
+
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++ -&gt; Debug -&gt; GDB -&gt; Use aggressive breakpoint filtering"''.
 +
 
 +
Improvements to GDB were also done by Ericsson to improve the performance of this feature.
  
 
=== Enhanced GDB console support  ===
 
=== 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.  
+
Ericsson is sponsoring a joint CDT/GDB feature synchronize the Eclipse GUI with the GDB state, when changes are caused by user commands.
 +
 
 +
GDB now reports any changes caused by the user, while CDT is being improved to update its views based on these GDB events. 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 and tracepoints  ====
Line 186: Line 190:
 
[[Image:CorePath.png]]  
 
[[Image:CorePath.png]]  
  
=== Enhancements to Tracepoints  ===
+
=== Dynamic Tracepoints  ===
  
With the use of GDB 7.4, some new features are available within Eclipse.  
+
Ericsson sponsored a joint CDT/GDB feature to provide dynamic tracing capabilities.
  
*Live enable/disable of C/C++ Tracepoints
+
In some applications, it is not feasible for the debugger to interrupt the program's execution long enough for the developer to learn anything helpful about its behavior. If the program's correctness depends on its real-time behavior, delays introduced by a debugger might cause the program to change its behavior drastically, or perhaps fail, even when the code itself is correct. It is useful to be able to observe the program's behavior without interrupting it.  
**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.<br>
+
*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.
+
  
 +
Using C/C++ Tracepoints, you can specify locations in the program, called tracepoints, and arbitrary expressions to evaluate when those tracepoints are reached. Later, you can examine the values those expressions had when the program hit the tracepoints. Because tracepoints record these values without interacting with the user, it can be done quickly and unobtrusively, hopefully not disturbing the program's behavior.
 +
 +
'''Creating Tracepoints'''
 +
 +
Tracepoints are handled as a type of breakpoint. There are two differences to note:
 +
 +
#When a tracepoint is created in a debug session, it is not actually planted in the binary code until the user explicitly starts the tracing experiment. This means that creating/modifying/deleting tracepoints does not affect the program until tracing is actually started.
 +
#Simply creating a Tracepoint has very limited value as it won't collect any information by default. It is important to add Actions to the Tracepoint to tell it what to do. This will be detailed below.
 +
 +
[[Image:SelectTracepoint.png]]
 +
 +
Once this is done, double-clicking on the Editor or the Disassembly view margin will set Tracepoints instead of Breakpoints.
 +
 +
Note that Tracepoints and Breakpoints can co-exist in the same workspace, and even debug session.
 +
 +
'''Adding actions to a Tracepoint'''
 +
 +
Once you have created one or more Tracepoint, they need to be told what to do. Access the Tracepoint properties (actually called "Breakpoint Properties..."). You can do this by right-clicking on the editor margin or through the Breakpoints view.
 +
 +
Tracepoint properties currently contain two pages:
 +
 +
#Actions. Used to tell the Tracepoint what to do, such as collecting data.
 +
#Common. To modify other Tracepoint attributes such as the condition, enablement or passcount.
 +
 +
In the Actions page, you will need to define a set of actions that can be re-used for different Tracepoints. This is mirrored on the handling of CDT Breakpoint Actions.
 +
 +
[[Image:TracepointNewAction.png]]
 +
 +
There are three types of Tracepoints actions supported by GDB:
 +
 +
#Collect. This action will tell the tracepoint to collect data.
 +
#Evaluate. This allows to manipulate trace state variables.
 +
#While-stepping. This allows to perform a set of sub-actions more then once, as GDB steps the program after hitting the tracepoint.
 +
 +
[[Image:TracepointAddAction.png]]
 +
 +
 +
'''The TraceControl view'''
 +
 +
The TraceControl view is contributed by CDT and allows you to control the tracing of your application. It provides different buttons to:
 +
 +
#Start/Stop tracing
 +
#Refresh the view. As trace information can change rapidly, the view does not always show the latest information. Pressing the Refresh button will fetch the latest data
 +
#Start/Stop Visualizing data
 +
#Deal with TraceState variables
 +
 +
[[Image:TraceControl.png]]
 +
 +
'''Tracing'''
 +
 +
Once all tracepoints are properly created, press the "Start Tracing" button in the TraceControl view to start tracing your application. Have the application resume execution. As tracepoints are silently hit, data is being collected and the size of the content of the trace buffer can be seen to increase in the TraceControl view.
 +
 +
Until GDB 7.4, once a trace experiment is started, changes to tracepoints would not affect the ongoing experiment. However, starting with GDB 7.4, tracepoints can 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.
 +
 +
Once you feel you have collected enough trace data, press the "Stop Tracing" button in the TraceControl view. The trace data can then be examine directly in your current debug session, or can be saved to a trace file for post-mortem examination, in a manner reminiscent of corefiles.
 +
 +
To optionally save the trace data to a file, use the TraceControl view-menu and select "Save Trace Data"
 +
 +
[[Image:SaveTraceData.png]]
 +
 +
'''Examining the data'''
 +
 +
Once you have stopped your tracing experiment, you can examine the collected data. This can be done in two ways:
 +
 +
#Directly in the debug session used to collect the data. This will put GDB in a mode where it reads the collected data instead of the data of the current running program. This mode will keep your application running.
 +
#Post-mortem from a saved trace file, using a new debug session.
 +
 +
To immediately start looking at collected data, one can simply press the trace selection button (the one pointing down) and it will select the first trace record. Then, using the up/down trace selection buttons, one can navigate the trace records.
 +
 +
[[Image:TraceStartVisualization.png]]
 +
 +
The standard debug views (expressions, variables, registers) can be used to display the data that was collected. Note that if a particular variable or expression was not collected, it will show as empty or with an error in the view; this is fine.
 +
 +
[[Image:TraceVisualization.png]]
  
[[Image:CollectString.png]]
 
  
 
=== Show the actual variable type based on RTTI ===
 
=== Show the actual variable type based on RTTI ===
Line 231: Line 302:
  
 
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.
 
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  ===
 
=== Project-less debugging  ===

Revision as of 17:13, 8 February 2013

This page describes Ericsson's involvement in the C/C++ Development Toolkit (CDT) as well as the GNU Debugger (GDB) for 2011 and 2012. 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 in 2011-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.

VisualizerSnapshot.png

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.

CDT GroupExpr.png

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

Ericsson sponsored a joint CDT/GDB feature to provide the user with OS Resource information.

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.

CDT OSResources.png

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.

BpFilter.png

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

Improvements to GDB were also done by Ericsson to improve the performance of this feature.

Enhanced GDB console support

Ericsson is sponsoring a joint CDT/GDB feature synchronize the Eclipse GUI with the GDB state, when changes are caused by user commands.

GDB now reports any changes caused by the user, while CDT is being improved to update its views based on these GDB events. 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"

CDT-DSF-GDB-RevBPAction-create.png

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

CDT-DSF-GDB-RevBPAction-dialog.png

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.

LargeArray.png

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.

DebugPreferences.png

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

CharsetDebug.png

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.

TimeoutPreferences.png

TimeoutAdvanced.png

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

MultiSelectRunControl.png

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.

CDT Debug WithHiding.png

CDT Debug NoHiding.png

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

CDT Debug HidingPref.png

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.

CorePath.png

Dynamic Tracepoints

Ericsson sponsored a joint CDT/GDB feature to provide dynamic tracing capabilities.

In some applications, it is not feasible for the debugger to interrupt the program's execution long enough for the developer to learn anything helpful about its behavior. If the program's correctness depends on its real-time behavior, delays introduced by a debugger might cause the program to change its behavior drastically, or perhaps fail, even when the code itself is correct. It is useful to be able to observe the program's behavior without interrupting it.

Using C/C++ Tracepoints, you can specify locations in the program, called tracepoints, and arbitrary expressions to evaluate when those tracepoints are reached. Later, you can examine the values those expressions had when the program hit the tracepoints. Because tracepoints record these values without interacting with the user, it can be done quickly and unobtrusively, hopefully not disturbing the program's behavior.

Creating Tracepoints

Tracepoints are handled as a type of breakpoint. There are two differences to note:

  1. When a tracepoint is created in a debug session, it is not actually planted in the binary code until the user explicitly starts the tracing experiment. This means that creating/modifying/deleting tracepoints does not affect the program until tracing is actually started.
  2. Simply creating a Tracepoint has very limited value as it won't collect any information by default. It is important to add Actions to the Tracepoint to tell it what to do. This will be detailed below.

SelectTracepoint.png

Once this is done, double-clicking on the Editor or the Disassembly view margin will set Tracepoints instead of Breakpoints.

Note that Tracepoints and Breakpoints can co-exist in the same workspace, and even debug session.

Adding actions to a Tracepoint

Once you have created one or more Tracepoint, they need to be told what to do. Access the Tracepoint properties (actually called "Breakpoint Properties..."). You can do this by right-clicking on the editor margin or through the Breakpoints view.

Tracepoint properties currently contain two pages:

  1. Actions. Used to tell the Tracepoint what to do, such as collecting data.
  2. Common. To modify other Tracepoint attributes such as the condition, enablement or passcount.

In the Actions page, you will need to define a set of actions that can be re-used for different Tracepoints. This is mirrored on the handling of CDT Breakpoint Actions.

TracepointNewAction.png

There are three types of Tracepoints actions supported by GDB:

  1. Collect. This action will tell the tracepoint to collect data.
  2. Evaluate. This allows to manipulate trace state variables.
  3. While-stepping. This allows to perform a set of sub-actions more then once, as GDB steps the program after hitting the tracepoint.

TracepointAddAction.png


The TraceControl view

The TraceControl view is contributed by CDT and allows you to control the tracing of your application. It provides different buttons to:

  1. Start/Stop tracing
  2. Refresh the view. As trace information can change rapidly, the view does not always show the latest information. Pressing the Refresh button will fetch the latest data
  3. Start/Stop Visualizing data
  4. Deal with TraceState variables

TraceControl.png

Tracing

Once all tracepoints are properly created, press the "Start Tracing" button in the TraceControl view to start tracing your application. Have the application resume execution. As tracepoints are silently hit, data is being collected and the size of the content of the trace buffer can be seen to increase in the TraceControl view.

Until GDB 7.4, once a trace experiment is started, changes to tracepoints would not affect the ongoing experiment. However, starting with GDB 7.4, tracepoints can 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.

Once you feel you have collected enough trace data, press the "Stop Tracing" button in the TraceControl view. The trace data can then be examine directly in your current debug session, or can be saved to a trace file for post-mortem examination, in a manner reminiscent of corefiles.

To optionally save the trace data to a file, use the TraceControl view-menu and select "Save Trace Data"

SaveTraceData.png

Examining the data

Once you have stopped your tracing experiment, you can examine the collected data. This can be done in two ways:

  1. Directly in the debug session used to collect the data. This will put GDB in a mode where it reads the collected data instead of the data of the current running program. This mode will keep your application running.
  2. Post-mortem from a saved trace file, using a new debug session.

To immediately start looking at collected data, one can simply press the trace selection button (the one pointing down) and it will select the first trace record. Then, using the up/down trace selection buttons, one can navigate the trace records.

TraceStartVisualization.png

The standard debug views (expressions, variables, registers) can be used to display the data that was collected. Note that if a particular variable or expression was not collected, it will show as empty or with an error in the view; this is fine.

TraceVisualization.png


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:

CDT Debug VariableTypeBasedOnRtti.png

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:

CDT Debug VariableTypeBasedOnRttiPref.png

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.

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.

Noprojectdebug.png

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:

NoPrettyPrint.png


With pretty-printing:

FullPrettyPrint.png


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.

MultiAttachDialog.png


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.

MultiProducerConsumer.png


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.


AutoAttachOption.png

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.

PinCloneDebug.png

Showing cores in Debug view labels

By using the enhancements of GDB 7.1, DSF-GDB now shows the core on which each thread runs as an extra part of the Debug View label. The list of all cores on which a process is located is also added as a label. The below image shows the new feature.

CoreLabels.png

Showing cores and owner in attach prompter

DSF-GDB now shows the owner of a process as an extra part of the process prompt for an attach session. The owner id will be shown starting with GDB 7.0. For a Remote attach session (using gdbserver --multi), the cores on which a process is located will also be shown. Showing the cores starts with GDB 7.1. The below image shows the new feature.

UserAndCores.jpg

C/C++ Remote Application launch

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

Debugconfig.jpg

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.

RemoteDelegates.jpg

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.

Multiselect.png

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.

FastTracepointSelection.png

Back to the top