This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 0/5] Synchronize nd_syscalls.stp with syscalls.stp


On 05/22/2009 08:46 AM, Przemyslaw Pawelczyk wrote:
> Hi,
> 
> Here are a few patches for nd_syscalls.stp to sync it with syscalls.stp.
> 
> Fourth patch is problematic. From a theoretical viewpoint it isn't flawed.
> Though applying it causes my strace-like script almost inoperative.
> http://research.pawelczyk.it/systemtap/scripts/strace-nd.stp
> 
> Typical use case:
> ./strace-nd.stp -vc /bin/ls
> 
> It hangs after reporting many probe registration errors (rc -22), the last
> one is kprobe.function("SyS_epoll_create").return!
> After typing Ctrl-C script is stopped, but no data was collected and
> process /bin/ls probably wasn't started -- there is no output from it.
> 
> Other scenario:
> ./strace-nd.stp -v
> 
> Now only fstat hits the probe.
> 
> Any ideas where is the source of problem?

kprobe.function can't resolve whether the function actually exists until
runtime.  So when the translator sees a kprobe.function("foo")!, we
assume that it will work, and so the rest of the alternatives aren't
tried.  Notice you have:

> +probe nd_syscall.accept = kprobe.function("SyS_accept") !,
> +                          kprobe.function("sys_accept") ?

and

>  probe nd_syscall.fstat = kprobe.function("sys_fstat") ?,
> +                         kprobe.function("SyS_fstat64") ?,
>                           kprobe.function("sys_fstat64") ?,
>                           kprobe.function("sys32_fstat64") ?,
> +                         kprobe.function("SyS_newfstat") ?,
>                           kprobe.function("sys_newfstat") ?,
>                           kprobe.function("sys_oabi_fstat64") ?,
>                           kprobe.function("compat_sys_newfstat") ?

So for nd_syscall.accept, the translator will only output a probe on
SyS_accept, since it has a '!', but for nd_syscall.fstat the translator
will output them all.

Therefore, using '!' on kprobe.function is currently useless, since the
translator always considers them resolved.  For the same reason, the '?'
isn't really doing anything here either.

We could try to suppress the registration warning at runtime for probes
marked with a '?' though.  Then you could just mark all of these as
optional, and while every one would be attempted, the user won't be
bothered with the failures.

Josh


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]