On Sun, 2011-07-24 at 01:11 +0200, Turgis, Frederic wrote:
Hi,
I think all syscalls in tapset have "name" variable defined to the correct name.
Yes, that is the most convenient way to refer to the syscall matched by
a probe. See also the comment at the top of tapset/syscall.stp for some
of the other generic probe syscall.*[.return] convenience variables:
/* Each syscall returns the calls parameters. In addition, the following
* variables are set:
*
* name - generally the syscall name minus the "sys_".
*
* argstr - a string containing the decoded args in an easy-to-read format.
* It doesn't need to contain everything, but should have all the
* important args. Set in entry probes only. Values enclosed in
* square brackets are user-space pointers. Values in curly
* braces are decoded structs.
*
* retstr - a string containing the return value in an easy-to-read format.
* Set in return probes only.
*/
An alternative way to intercept syscalls using numbers is the
process[(pid|name)].syscall probe. This exposes a $syscall variable
which is just the architecture specific number. I find this one less
convenient to use, but it has as advantage that it automatically
restricts itself to the target process. Example:
stap -e 'probe process.syscall
{ printf("%s called %d\n", execname(), $syscall) }' -c /bin/ls
nd_syscall.stp provides even another way to intercept syscalls, using
non-dwarf kprobe, but that tapset isn't fully finished and needs more
cross-architecture work to be really useful.