CDT/Archive/cdt-debug-default-integration

This page is meant to collect information about the different debugging solutions of the CDT, to help choose the one that will be the default. The three open-source debugging solutions currently available are:

• CDI-GDB - An integration of GDB using the CDI framework
• DSF-GDB - An integration of GDB using the DSF framework
• EDC - Debugging solution using the DSF framework that does not require a 'back-end' debugger

CDI-GDB

Up to and including the Galileo release of Eclipse (3.5), CDI-GDB is the default debugging integration that is chosen when setting up a debug session.

The CDI framework is currently deprecated and the community has chosen to put its efforts towards a DSF-based solution. This makes the case that the time has come where CDI-GDB should no longer be the default CDT debugging solution.

DSF-GDB

The integration of the GNU debugger (GDB) using DSF is meant to replace the deprecated CDI integration by providing the same level of functionality, while adding many more features. Below is a list of features provided by DSF-GDB to the open-source community.

Standard debugging

• Breakpoints and single-stepping
• Support for multi-threaded programs
• Looking at user defined expressions
• Examining and modifying variables
• Examining and modifying registers
• Examining and modifying memory
• Listing modules

Types of debugging supported

• Local debugging
• Remote debugging
• Post-mortem debugging (core file)
• Post-mortem tracing (trace file)
• Debugging any binary on the file system (no need to import the code as an Eclipse project)
• Debugging using a Simulated or Emulated target

Supported platforms

• Linux
• Windows (MinGw or Cygwin)
• Macintosh
• Any platform that supports GDB 6.6 or higher (can still work with minor issues using even older GDBs)

Advanced features

• All-stop Multi-thread support (all threads are stopped when a breakpoint is hit)
• Non-stop Multi-thread support (only the thread where the breakpoint is hit is stopped)
• Multi-process support (debugging multiple processes at the same time)
• Global breakpoints (on some platforms, breakpoints can be set even we are not attached to the process)
• Freely and repeatedly attaching and detaching from running processes
• Reverse debugging (on local or remote Linux)

• Extensible Pretty-printing using Python scripting
• Advanced Disassembly view
• Choice of Memory view and/or Memory Browser view
• Traditional memory rendering
• Always-present gdb traces for easy troubleshooting

• Fast smooth stepping (user can step as fast as the keyboard repeat rate)
• Gradual stack trace length display
• Update policies
• Detail pane usage for data displays

• Dynamic tracepoints
• Static tracepoints with LTTng

Access the very large set of GDB features through the console

non-blocking interaction with GDB

GDB supports _many_ different targets Single binary GDB for many different targets

Flexible-hierachy breakpoints Core-awareness (showing on which core a thread is running) Checkpoints Code patching ("hot swap")

Services factory allows to easily extend to new platforms or GDB versions