2 ms·

FWIW, I managed to compile SystemTap with DWARF debug info (using a kernel with CONFIG_DEBUG_INFO, CONFIG_KPROBES and CONFIG_UPROBES) on my Slackware-current bo

FWIW, I managed to compile SystemTap with DWARF debug info (using a kernel with CONFIG_DEBUG_INFO, CONFIG_KPROBES and CONFIG_UPROBES) on my Slackware-current box just recently, and have been using to write process probes on shared libraries with success. It's somewhat slow, the UI is clunky and I had to comment out a rather anal sanity check related to module timestamps from the source, but it works. By far the biggest drawback is it has no formal API, instead you have to wrangle with subprocesses to automate it. It's pretty ugly to see things like the SystemTap initscript or SystemTap toolkits which execute scripts as interpolated strings with a template engine, though that's reality. It has certainly improved from its former reputation as a routine kernel panic trigger, though fiddling with guru mode haphazardly will still hang or crash your system perhaps a bit too easily.

brendangregg 11y ago
Yes, SystemTap is much better nowadays, but people are still spooked from the panics of years ago. (And I'm partly to blame, as I wrote about its panics in 2011.) SystemTap has a grammar and extensive tapsets, so one interesting possibility would be for SystemTap to use eBPF as a backend: compile to eBPF bytecode. You'd then get safety, a grammar, and all the tapsets, which include many tracing odds and ends that you sometimes run into, which SystemTap has solved years ago. Although at times I think the tapsets have gone too far, and become too big and untested (one of the reasons I started writing lightweight tools https://github.com/brendangregg/systemtap-lwtools https://github.com/brendangregg/systemtap-lwtools).