GDB

Manages multiple independent GDB debugging sessions concurrently through a singleton GDBManager that maintains a HashMap of session objects, each wrapping a separate GDB process. Sessions are isolated and can debug different programs simultaneously without interference, with each session maintaining its own execution state, breakpoints, and variable context. The manager handles process lifecycle (spawn, monitor, terminate) and routes MCP tool calls to the correct session via session ID.

Translates high-level MCP tool requests into low-level GDB/MI (Machine Interface) protocol commands by generating properly-formatted MI syntax strings that GDB understands. The command generation layer constructs MI commands for operations like breakpoint setting, execution control, and variable inspection, then sends them to the GDB process via stdin. This abstraction allows AI assistants to use natural tool semantics while the server handles the complexity of GDB's machine-readable protocol.

Isolates debugging state (breakpoints, execution state, variables, registers) per session, ensuring that operations on one session do not affect other concurrent sessions. Each session maintains its own GDB process, breakpoint list, execution state, and variable context. The MCP tool layer routes requests to the correct session via session_id parameter, and responses are scoped to that session only. This isolation enables true concurrent debugging without state corruption.

Handles GDB process failures, command errors, and protocol violations with structured error responses that include error type, message, and recovery suggestions. The implementation catches GDB process crashes, timeouts, and invalid command responses, then returns detailed error objects to clients. Error handling includes automatic process restart on crash and graceful degradation when GDB features are unavailable. Clients receive actionable error information to diagnose and recover from failures.

Enables AI assistants to orchestrate multi-step debugging workflows by exposing debugging operations as discrete MCP tools that can be chained together. AI assistants can call tools in sequence (set breakpoint → start debugging → inspect variables → continue → inspect stack) to perform complex debugging tasks. The server maintains session state across tool calls, allowing assistants to build debugging strategies without manual state management. This capability bridges the gap between AI reasoning and low-level debugging operations.

Allows clients to configure program arguments and environment variables when creating debugging sessions, enabling debugging of programs with specific runtime configurations. The implementation accepts program arguments as an array and environment variables as key-value pairs, then passes them to the GDB exec-run command. This capability enables debugging of programs that require specific command-line arguments or environment setup without manual GDB configuration.

Detects GDB version and available features at server startup, enabling graceful degradation when certain GDB features are unavailable. The implementation queries GDB for version information and feature support, then disables or adapts tools that depend on unavailable features. This capability enables the server to work with a range of GDB versions (7.0+) without requiring exact version matching. Clients receive information about available features to adapt their debugging workflows.

Parses raw GDB/MI protocol output (text-based machine-readable format) into strongly-typed Rust data models representing debugging state. The parser extracts structured information from GDB responses including breakpoint metadata, stack frames, variable values, register contents, and memory dumps. This parsing layer converts unstructured text output into JSON-serializable data structures that MCP clients can reliably consume, with error handling for malformed or unexpected GDB responses.

Manages the complete lifecycle of breakpoints through MCP tools that set breakpoints at file:line locations, retrieve all active breakpoints with metadata, and delete breakpoints by ID. The implementation generates GDB/MI commands (-break-insert, -break-list, -break-delete) and parses responses to extract breakpoint IDs, hit counts, and enable/disable status. Breakpoints are session-specific and persist across execution pauses but are cleared when a session terminates.

Controls program execution flow through MCP tools that start debugging (exec-run), pause execution (exec-interrupt), continue from breakpoint (exec-continue), step into functions (exec-step), and step over functions (exec-next). Each command generates the corresponding GDB/MI instruction and monitors execution state changes. The server tracks whether the program is running, stopped at a breakpoint, or exited, and returns state transitions to clients.

Retrieves and parses the current call stack (stack frames) from a stopped program, exposing frame metadata including function name, file location, line number, and argument values. The implementation uses GDB/MI stack-list-frames command to fetch all frames and stack-list-arguments to extract parameter values. Clients can inspect the call stack to understand how execution reached the current breakpoint and trace function call chains.

Retrieves and parses local variables in the current stack frame, including variable names, types, and current values. The implementation uses GDB/MI stack-list-variables command to fetch all locals and var-create/var-evaluate-expression for detailed value inspection. Variables are parsed into typed data models that represent primitive types, pointers, arrays, and structures. Clients can inspect variable state at any breakpoint to understand program behavior.

Retrieves CPU register names and current values from the stopped program, enabling low-level debugging of register state. The implementation uses GDB/MI data-list-register-names to fetch available registers and data-list-register-values to read current values. Registers are returned as key-value pairs with register names (eax, rax, rip, etc.) and their current values in hexadecimal format. This capability is useful for assembly-level debugging and understanding CPU state.

Reads raw memory from the debugged program at specified addresses, returning memory contents in hexadecimal format. The implementation uses GDB/MI data-read-memory command to fetch memory ranges and parses the output into byte arrays. Clients can inspect memory at arbitrary addresses to understand heap state, examine data structures, or verify memory contents. Memory reads are bounded by size limits to prevent excessive data transfer.

Abstracts the underlying transport mechanism for MCP protocol communication, supporting both Stdio (local process communication) and SSE (Server-Sent Events for remote/network communication). The server implements the MCP protocol layer that handles tool registration, request routing, and response serialization. Clients connect via either transport and receive identical MCP tool interfaces, enabling both local and remote debugging scenarios without code changes.