Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

CDT/Archive/cdt-debug-default-integration

< CDT‎ | Archive
Revision as of 13:10, 4 February 2010 by Unnamed Poltroon (Talk)

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 - Eclipse Debugger for C/C++


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

  • 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 Eclipse and 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)
  • 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

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

EDC

<To be filled>

Back to the top