RE: the system call number

[Mark Wielaard <mjw at redhat dot com>]

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.

Cheers,

Mark