Making Do without Debugging Information

One of the great things about SystemTap is its ability to exploit the debugging information ("dwarf") that accompanies your kernel and modules. Like gdb, SystemTap understands dwarf, and so knows the names and types of variables, and (to the extent possible) which code addresses in the kernel refer to which functions and source lines. Documents such as SystemTapFAQ provide information on how to ensure that the debugging information is available for SystemTap's use.

Sometimes, however, you might want to use SystemTap even though there's no debugging information available for your kernel. In the absence of dwarf, SystemTap can still do quite a bit for you by enabling probing of entry & exit points of kernel & module functions. This is achieved by deferring symbol resolution to runtime & utilizing kprobes to do the same. This page tells you how to use this feature.

Stap Constructs

The stap command supports a new probe family, called "kprobes.function" for dwarfless tracing. Following constructs are supported:

These options are described in the stapprobes man page, which also contains a section ,"DWARFLESS" on this topic.

What Can I Do without Dwarf?

Using above constructs SystemTap can probe function entries and returns -- for example,

probe kprobe.function("printk") { ... }
probe kprobe.module("xyz").function("xyz_reset").return { ... }

It is to be noted that wildcards in function / module names are NOT supported.

It can also probe elsewhere if you specify an absolute address -- for example,

probe kprobe.statement(0xc0112a1f).absolute { ... }

Note that statement probes can be used under guru-mode only.

When you're stopped at the entry to a function, you can refer to the function's arguments by number. For example, when probing the function declared

asmlinkage ssize_t sys_read(unsigned int fd, char __user * buf, size_t count)

you can obtain the values of fd, buf, and count, respectively, as uint_arg(1), pointer_arg(2), and ulong_arg(3). (But in this case, your probe code must first call asmlinkage(), because on some architectures the asmlinkage attribute affects how the function's arguments are passed.)

When you're in a return probe, $return isn't supported without dwarf, but you can call returnval() to get the value of the register in which the function value is typically returned, or returnstr() to get a string version of that value.

And at any code probepoint, you can call register("regname") to get the value of the specified CPU register when the probe point was hit. u_register("regname") is like register("regname"), but interprets the value as an unsigned integer.

The stapfuncs(5) man page describes all the functions mentioned in this section.

The nd_syscalls.stp tapset -- still under construction -- is a version of the syscall tapset that can be used in the absence of dwarf ("nd" = "no dwarf"). It obtains the values of the system-call arguments using functions such as long_arg() and pointer_arg(), and makes these values available as named local variables.

What Doesn't Work without Dwarf?

Without debugging information, SystemTap can't support the following types of language constructs:

None: MakeDoWithoutDebugInfo (last edited 2009-05-25 05:29:32 by 59)