You should already be comfortable with plain command-line GDB — breakpoints, step, next, continue — since TUI and DDD are layers on top of that same command set, not replacements for it.

GDB exposes a structured, machine-readable protocol called the GDB Machine Interface (GDB/MI). Every front end — TUI, DDD, IDE plugins — ultimately talks to GDB either directly through its command-line interpreter or through GDB/MI. Knowing this matters practically: if a graphical tool misbehaves, you can usually fall back to plain GDB and issue the identical commands by hand, because nothing the front end does is magic — it is just automating commands you could type yourself.

TUI ships inside standard GDB — there is nothing extra to install on most distributions, and because it runs in plain text mode it works perfectly over an SSH session to a target board, which makes it the practical default for embedded work where a GUI display isn’t available.

Launch GDB with TUI enabled

$ gdb -tui ./ep_crashdemo

This splits the terminal into a source-code pane on top and the familiar command prompt below. You can also flip TUI on and off inside an already-running session:

(gdb) tui enable
(gdb) tui disable

A few TUI navigation keys are worth memorizing:

Every command you already know — break, next, print, bt — still works exactly the same in TUI mode; the only difference is that the current line and any breakpoints stay visible as you step, instead of having to re-run list after every step.

DDD is a separate, standalone graphical application that drives GDB underneath — it doesn’t replace GDB, it wraps it. Its standout feature is the data window: when you display a pointer, DDD draws it as a box, and double-clicking that pointer expands the structure it references into a new linked box with an arrow connecting them — genuinely useful when you’re chasing a corrupted linked list or tree and want to see the shape of the data rather than reading addresses off a text dump.

Point DDD at a cross toolchain’s GDB

$ ddd --debugger arm-none-linux-gnueabihf-gdb ./ep_crashdemo

Inside a session, the data window is driven by the same graph display command you could type into plain GDB — DDD is simply rendering the result visually:

(gdb) break ep_bump
(gdb) run
(gdb) graph display *n
(gdb) graph display n->next dependent on -1

The second line links the displayed node to the one before it, so as you step through a list-walking function DDD keeps redrawing the chain of nodes and their pointer connections automatically.

Default to TUI for remote embedded sessions since it needs zero extra setup. Reach for DDD only when you’re actively untangling a data structure and have a local display or X forwarding available — it adds real value there but is unnecessary overhead for a simple step-through session.

TUI and DDD are both front ends over the same GDB engine and the same GDB/MI protocol — TUI adds a live source window inside your terminal with zero setup, while DDD adds a graphical, clickable view of your data structures. Picking the right one for the situation, rather than always reaching for a GUI, is a habit worth building early in any free linux kernel development course track.