Architecture: The Translation Loop

From Script to Kernel Module

SystemTap works very differently from standard interpreters or even eBPF. When you run a script (script.stp), a complex five-step pipeline executes before a single probe fires:

1. Parse: The stap frontend reads and validates your .stp script syntax.
2. Elaborate: It resolves your probe points (e.g., kernel.function("sys_open")) against the Kernel Debug Symbols (debuginfo). This step maps human-readable function names to exact memory addresses in the running kernel. Without debuginfo, this step fails entirely.
3. Translate: It converts your script into C code — a .c file that implements the probe logic as kernel-compatible functions.
4. Compile: It invokes gcc to compile that C code into a Linux Kernel Module (.ko file), linking against the kernel headers from kernel-devel.
5. Run: It calls insmod to load the module into the live kernel. The module attaches to kernel hooks (via kprobes or uprobes under the hood), collects data, and streams results back to your terminal via a relay buffer.

Latency Warning: Because it compiles C code on every invocation, a SystemTap script typically takes 10–30 seconds to start. This is not a tool for instant ad-hoc queries the way tcpdump or strace is. Plan for this startup cost in production runbooks.

The dependency problem in practice: The debuginfo packages for a kernel are large — often 300–500 MB. On a minimal production server, they are almost never pre-installed. This means your first step in any SystemTap investigation on a new host is a package installation, which may require internet access or an internal mirror. This operational friction is a primary reason eBPF with CO-RE (Compile Once, Run Everywhere) and BTF (BPF Type Format) eventually displaced SystemTap — eBPF programs can carry their own type information and don't require matching debuginfo on the target host.