In the absence of debugging information, you can still use the kprobe family of probes to examine the entry and exit points of kernel and module functions. You cannot look up the arguments or local variables of a function using these probes. However, you can access the parameters by following this procedure:
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
You can obtain the values of
count, respectively, as
ulong_arg(3). 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 call
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.
SystemTap supports the following constructs:
.function probes for kernel functions and
.module probes for probing functions of a specified module. If you do not know the absolute address of a kernel or module function, use
.statement probes. Do not use wildcards in
MODULE names. Wildcards cause the probe to not register. Also, run statement probes in guru mode only.