Cross-compiling probes
Problem
Sometimes, one wants to run systemtap scripts on machines that for logistical or policy reasons cannot have the full systemtap translator / compiler toolchain installed. No worry, there is now some support for cross-compiling scripts. Like any other cross-compilation concept, this splits compilation from execution. Similarly, installation dependencies are split.
On the host machine, one needs the compiler environment:
systemtap |
kernel development headers |
kernel debuginfo files |
gcc and rest of toolchain |
On the target, just one piece:
systemtap-runtime (the staprun / stapio programs) |
The host and target machines may be the same box, at different points in time: for example, running a different kernel version, or running different sets of kernel modules.
Session
This example uses ssh tools to communicate between host and target. Any other method that can copy the compiled .ko file to the target and run staprun there is of course workable.
HOST% ssh TARGET uname -r
2.5.18
HOST% rpm -q kernel-devel-2.5.18 kernel-debuginfo-2.5.18
[...installed...]
HOST% ssh TARGET rpm -q systemtap-runtime
systemtap-runtime-a.b.c
HOST% stap -r 2.5.18 -e 'probe begin { log ("hello " . k) exit () } global k="world" '
/home/you/.systemtap/cache/xx/xxyyzz.ko
HOST% scp /home/you/.systemtap/cache/xx/xxyyzz.ko TARGET:
HOST% ssh TARGET sudo staprun xxyyzz.ko
hello world
HOST% ssh TARGET sudo staprun xxyyzz.ko k=mom
hello mom
Lessons
It's a natural application of the script caching logic added to systemtap in late 2006. Cross-compiling to a different CPU architecture may also be possible with the -a ARCH flag, if the kernel-devel installation is capable of running cross-compilers. Rerunning a cached module multiple times is easy, and global scalar variables may be initialized via module parameters.
If you just want to pre-compile the script for the same host you're on, use -p4 instead of -r VERSION on the systemtap command line, and omit all the ssh/scp razzmatazz.