CDT/Archive/cdt-debug-default-integration

Note: The contents of this page refer to planning documents of past Eclipse CDT releases. See CDT/planning for current information.

This page is meant to detail the features of DSF-GDB to document any decision to make it the default debugger of the CDT.

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.

There is a lot of value is using GDB for CDT debugging:

• Access to the extremely large set of features provided by GDB
• Access to an expert and very active GDB community working to constantly improve GDB
• Access to all new GDB features, often with very little work needed in the CDT

Below is a list of features provided by DSF-GDB to the open-source community.

Standard debugging

• Run Control
• Support for multi-threaded programs
• Examining and modifying data (variables, memory, registers)
• Listing modules

Supported debugging

• Local debugging
• Remote debugging
• Post-mortem debugging (core file)
• Post-mortem tracing (trace file)

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

• Debugging a Simulated or Emulated target
• Debugging a Virtual Machine target
• Debugging any binary on the file system (no need to import the code as an Eclipse project)

Advanced features

• Hardware breakpoints and watchpoints
• 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)
• Support for programs that fork
• 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
• Support of different targets with the same GDB binary and the same Eclipse binary:

• Multi architecture -> GDB target description <architecture> e.g. x86
• Multi operating systems -> GDB target description <osabi> e.g. linux
• Simulator, Emulator -> Same protocol, MI, Eclipse button e.g. Simics
• Unit test infrastructures -> Normal host base debug
• Real target -> GDB stub for RTOS (e.g. gdbserver on linux)
• JTAG -> many JTAG devices work with GDB

Extra

• Access the very large set of GDB features through the console
• Non-blocking interaction with GDB
• Single binary GDB for many different targets

2010 Planned features

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