the system call number

[Da Zheng]

Hello,

On 07/25/11 02:51, Mark Wielaard wrote:
> 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.
Thanks a lot. I found `name' is also mentioned in the Beginners Guide.

Da