D7net
Home
Console
Upload
information
Create File
Create Folder
About
Tools
:
/
proc
/
3
/
task
/
3
/
root
/
usr
/
share
/
doc
/
systemtap-runtime-4.0
/
Filename :
README
back
Copy
systemtap: a linux trace/probe tool Visit the project web site at <http://sourceware.org/systemtap>, for documentation and mailing lists for developers and users. This is free software. See the COPYING file for redistribution/modification terms. See the INSTALL file for generic build instructions. See the HACKING file for contribution advice. Prerequisites: - linux kernel - kernel module build environment (kernel-devel rpm) and/or dyninst - optionally, debugging information for kernel/user-space being instrumented - C compiler (same as what kernel was compiled with), to build kernel modules - C++11 compiler such as gcc 4.8+, to build systemtap itself - elfutils 0.151+ with libdwfl for debugging information parsing - root privileges Installation steps: - Install any debuginfo packages you need, for kernel and/or userspace. On modern Fedora, # debuginfo-install kernel [...] (Beware of confusion between kernel vs. kernel-debug vs kernel-PAE etc. variants. Each likely has a corresponding development and debuginfo package.) - Install the systemtap package. On modern Fedora, # yum install systemtap systemtap-runtime Build steps: - Consider installing the kernel-debuginfo, kernel-devel, gcc and dependent packages (or see below if you are building your own kernels from source). If using only the pure-userspace dyninst backend, install gcc and dyninst-devel. - If available, install your distribution's copy of elfutils and its development headers/libraries. Or if desired, download an elfutils source release to build in "bundled mode" (below), and untar it into some new directory. Or if desired, build elfutils separately one time, and install it to /usr/local. See http://elfutils.org/ Version 0.151 is recommended for i386 hosts probing prelinked programs. (PR12141) - On modern Fedora, install general optional build-requisites: # yum-builddep systemtap On modern Debian/Ubuntu, similarly: # apt-get build-dep systemtap - Download systemtap sources: http://sourceware.org/systemtap/ftp/releases/ http://sourceware.org/systemtap/ftp/snapshots/ (or) git clone git://sourceware.org/git/systemtap.git (or) http://sourceware.org/git/systemtap.git - Build systemtap normally: % .../configure [other autoconf options] Or, with build it with a bundled internal copy of elfutils: % .../configure --with-elfutils=ELFUTILS-SOURCE-DIR [other autoconf options] (Ensure decompression library headers/libraries are installed for elfutils' use.) Consider configuring with "--enable-dejazilla" to automatically contribute to our public test result database. Consider configuring with "--prefix=DIRECTORY" to specify an installation directory other than /usr/local. It can be an ordinary personal directory. % make all # make install To uninstall systemtap: # make uninstall Alternately, on a Fedora-like system: % make rpm # rpm -i /path/to/rpmbuild/.../systemtap*rpm - Run systemtap: To run systemtap after installation, add $prefix/bin to your $PATH, or refer to $prefix/bin/stap directly. If you keep your build tree around, you can also use the "stap" binary there. Some samples should be available under $prefix/share/doc/systemtap/examples. For the normal linux-kernel-module based backend, run "stap" as root. If desired, create "stapdev" and "stapusr" entries in /etc/groups. Any users in "stapdev"+"stapusr" will be able to run systemtap as if with root privileges. Users in "stapusr" only may launch (with "staprun") pre-compiled probe modules (created by "stap -p4 ...") that a system administrator copied under /lib/modules/`uname -r`/systemtap. "stapusr" may also be permitted to create arbitrary unprivileged systemtap scripts of their own. See README.unprivileged for additional setup instructions. To run a simple test. # stap -v -e 'probe vfs.read {printf("read performed\n"); exit()}' To run the full test suite from the build tree, install dejagnu, then run with root privileges: # make installcheck For the prototype dyninst pure-userspace backend, run "stap" as any user. % stap --runtime=dyninst -e 'probe process.function("*") { println(pn(), ":", $$parms) }' -c 'ls' For the prototype bpf backend, run "stap" as "root" # stap --runtime=bpf -e 'probe kernel.function("do_exit") { printf("bye %d\n", pid()) }' Tips: - By default, systemtap looks for the debug info in these locations: /boot/vmlinux-`uname -r` /usr/lib/debug/lib/modules/`uname -r`/vmlinux /lib/modules/`uname -r`/vmlinux /lib/modules/`uname -r`/build/vmlinux Building a kernel.org kernel: - Consider applying the utrace kernel patches, if you wish to probe user-space applications. http://sourceware.org/systemtap/wiki/utrace Or if your kernel is near 3.5, apply the uprobes and related patches (see NEWS). Or if your kernel is >= 3.5, enjoy the built-in uprobes. - Build the kernel using your normal procedures. Enable CONFIG_DEBUG_INFO, CONFIG_KPROBES, CONFIG_RELAY, CONFIG_DEBUG_FS, CONFIG_MODULES, CONFIG_MODULE_UNLOAD, CONFIG_UTRACE if able - % make modules_install install headers_install - Boot into the kernel. - If you wish to leave the kernel build tree in place, simply run % stap -r /path/to/kernel/build/tree [...] You're done. - Or else, if you wish to install the kernel build/debuginfo data into a place where systemtap will find it without the "-r" option: % ln -s /path/to/kernel/build/tree /lib/modules/RELEASE/build - Instead of using the "-r" option, you can also use the environment variable SYSTEMTAP_RELEASE to direct systemtap to the kernel data.