The overall design is based on an "object model". The object model is a collection of abstractions, each modeling an artifact involved in debugging a program. Example of such artifacts include: Thread, BreakPoint, Symbol, SymbolTable; these abstractions are expressed in C++ as abstract classes. Abstract classes are the C++ way of coding interfaces. The object model is a collection of interfaces, each modeling an artifact related to debugging. The supported symbol format is ELF (Executable and Linkable Format), used by the Linux operating system. The ELF format supports core files, created by the operating system when a program crashes. Consequently, the debugger supports loading core files, and post-mortem examination of crashed programs.

The debugger has a modular, component-based architecture. The central part is a layered engine core that provides basic debugger functionality, such as execution control, breakpoint management, and symbol table management. The three layers of the engine core implement most of the abstract classes in the object model. The engine core provides minimal support for interaction with the user, via a command line interface, manages breakpoints (inserted by both the user and the debugger itself for internal purposes) and controls the execution of the debuggee threads. Additional functionality is provided by plug-in components.

The implementation makes heavy use of the STL and boost libraries.

The engine notifies all plug-ins about crucial events such as the loading of a dynamic library, the creation of a new thread inside of the debugged program, or the receipt of a signal. When the debugged program receives a signal, the event is broadcasted to the plug-ins. Normally, after the plugins have been notified about the signal, the engine displays a prompt at the console and waits for the user to type a command. A plug-in can however override this user interaction, and implement either a custom prompt (possibly extended with a scripting language) or a GUI.