Delve — Dependencies#

Module info#

• Module: github.com/go-delve/delve
• Go version: 1.24
• Direct dependencies: 15
• Indirect dependencies: 7 (go.mod) / ~32 unique modules in go.sum (65 lines)

Dependency categories#

Core infrastructure#

• github.com/spf13/cobra v1.10.2 — CLI framework for the dlv command and all its subcommands (debug, attach, exec, dap, etc.)
• github.com/spf13/pflag v1.0.9 — POSIX-style flag parsing, required by cobra
• github.com/cosiner/argv v0.1.0 — Shell argument tokenization; used to parse expressions entered interactively in the terminal (e.g., splitting dlv exec ./binary -- --flag value)
• go.yaml.in/yaml/v3 v3.0.4 — YAML parser for .delverc config files (user-defined initialization and settings)
• go.starlark.net v0.0.0-20231101134539-556fd59b42f6 — Starlark scripting language embedded in Delve’s init-file support, allowing users to script debugger interactions

Terminal / interactive UI#

• github.com/go-delve/liner v1.2.3-0.20231231155935-4726ab1d7f62 — A Delve-maintained fork of the liner line-editor library; provides readline-like editing, history, and tab completion for the interactive terminal (pkg/terminal)
• github.com/mattn/go-colorable v0.1.13 — Cross-platform colored output; makes ANSI color codes work on Windows
• github.com/mattn/go-isatty v0.0.20 — TTY detection; used to decide whether to emit colors and enable interactive mode
• github.com/derekparker/trie/v3 v3.2.0 — Trie data structure for fast tab-completion of debugger commands and symbol names in the terminal

Debug protocol#

• github.com/google/go-dap v0.12.0 — Official Google library for the Debug Adapter Protocol; provides the typed message structs and serialization used by service/dap/ to support IDE integration (VS Code, GoLand, etc.)

Low-level / OS#

• github.com/cilium/ebpf v0.11.0 — eBPF program loading and management library; the foundation of Delve’s non-stop tracing backend (pkg/proc/internal/ebpf/) which uses Linux uprobes to trace functions without halting the target process
• github.com/creack/pty v1.1.20 — Pseudo-terminal allocation; used in headless/server mode and in integration tests to attach to processes that require a controlling terminal
• golang.org/x/arch v0.11.0 — CPU architecture instruction set libraries (x86/x86asm, arm64/arm64asm, ppc64/ppc64asm, riscv64/riscv64asm, loong64/loong64asm); powers Delve’s multi-architecture disassembler
• golang.org/x/sys v0.26.0 — Low-level OS interfaces (unix, windows); used throughout pkg/proc/native/ for ptrace calls, signal handling, memory mapping, and Windows debugging APIs
• golang.org/x/telemetry v0.0.0-20241106142447-58a1122356f5 — Go toolchain opt-in telemetry; Delve participates in Go toolchain telemetry reporting as part of the official Go tooling ecosystem

Indirect (transitive only)#

• github.com/cpuguy83/go-md2man/v2 — Markdown-to-man-page conversion; pulled in by cobra for dlv man page generation
• github.com/inconshreveable/mousetrap v1.1.0 — Windows-only cobra helper that prevents accidental double-click execution from Explorer
• github.com/mattn/go-runewidth v0.0.13 — Unicode display width; required by liner for correct cursor positioning
• github.com/rivo/uniseg v0.2.0 — Unicode grapheme cluster segmentation; required by go-runewidth
• github.com/russross/blackfriday/v2 — Markdown rendering; pulled in by cobra for doc generation
• golang.org/x/exp — Pre-generics generic utilities (constraints, maps, slices); used internally for ordered data structures before stdlib equivalents landed
• golang.org/x/sync — errgroup for coordinating goroutine groups; used in the service and proc layers

Stdlib reliance#

Delve is heavily stdlib-reliant, especially in its core packages. Key stdlib packages observed:

The ratio of stdlib usage to third-party is notably high. The core debugger engine (pkg/proc, pkg/dwarf) uses zero third-party imports — it is built entirely on stdlib. Third-party dependencies are confined to the outer layers: CLI (cobra, liner), protocol (go-dap), OS interfaces (x/sys), and the eBPF backend (cilium/ebpf).

Shared dependencies#

Dependencies Delve shares with other projects in the Go ecosystem’s 50-project set:

• github.com/spf13/cobra — The dominant CLI framework; shared with Kubernetes, Helm, Hugo, and virtually every CLI-first Go project
• golang.org/x/sys — Near-universal for any project needing POSIX or Windows syscalls beyond stdlib coverage
• golang.org/x/sync (errgroup) — Common goroutine coordination utility
• github.com/mattn/go-isatty / go-colorable — Shared by any project with colored terminal output
• go.yaml.in/yaml/v3 — Common YAML config parsing (note: uses the newer go.yaml.in namespace rather than gopkg.in/yaml.v3)
• golang.org/x/arch — More specialized; likely shared only with projects that do binary analysis or disassembly

Vendoring#

Yes, Delve vendors all dependencies. The vendor/ directory is present and vendor/modules.txt is the source of truth for what is vendored. This is a deliberate choice appropriate for a debugger:

1. Reproducibility: Debuggers must work reliably across Go releases; vendoring eliminates upstream breakage risk
2. Self-sufficiency: Users building from source don’t need network access or module proxy
3. Security surface: A debugger that runs as root (for ptrace/eBPF) needs trustworthy, audited dependencies — vendoring enables full inspection and review

Notable dependency decisions#

• Custom liner fork instead of readline: Rather than chzyer/readline or the standard liner, Delve maintains its own fork (go-delve/liner) to control the readline behavior precisely, including integration with Delve’s own tab-completion for symbol names and debugger commands.

• go-dap from Google: Using the official google/go-dap library (maintained by the Go team at Google) rather than implementing DAP serialization in-house signals the project’s alignment with the official Go toolchain ecosystem. This is the same library used by gopls.

• Starlark for scripting: Choosing Starlark (the Python-like scripting language used in Bazel) over Lua or JavaScript for init-file scripting is architecturally interesting. Starlark is deterministic, has no I/O by default (safe for sandboxing), and is familiar to Go ecosystem users who work with Bazel/Gazelle. The go.starlark.net package is maintained by the Google Go team.

• cilium/ebpf instead of custom eBPF loading: The eBPF backend leverages cilium’s high-quality, well-maintained library rather than writing raw bpf() syscall wrappers. This gave Delve full eBPF program loading, BPF-to-BPF map management, and ring buffer support without reinventing the wheel, while keeping the eBPF backend focused on Delve-specific uprobe logic.

• golang.org/x/telemetry signals ecosystem integration: Including x/telemetry means Delve participates in the Go toolchain’s opt-in usage telemetry program. This is unique among third-party debuggers and confirms Delve’s status as a semi-official part of the Go toolchain rather than just a community project.

• Extremely lean dependency graph (22 total): For a project of this complexity — multi-platform, multi-protocol, binary analysis, OS-level process control — 22 total dependencies is remarkably minimal. The core debugger engine has zero external dependencies, reflecting a deliberate philosophy: the hard parts (DWARF parsing, process control, type evaluation) are trusted only to stdlib and Delve’s own code.