Re: Using sys_enter sys_exit trace point in place of syscall.*{.return} probes where possible

[David Smith <dsmith@redhat.com>]

In testsuite/systemtap.examples/profiling/container_check.stp, you
used _stp_syscall_nr(). I wouldn't do that, I'd use $id. I'm not 100%
sure that _stp_syscall_nr() is going to work on every arch at that
point.

I also wonder if you shouldn't use the old code as a fallback,
something like the following:

====
probe kernel.trace("sys_exit")!, nd_syscall.*.return {
    # probe that doesn't do anything with the syscall info
}
====

That gets trickier if the probe does something with the syscall info.
On Tue, Sep 18, 2018 at 8:58 AM William Cohen <wcohen@redhat.com> wrote:
>
> Hi,
>
> The syscall tapsets have been under a lot of change lately due to the changes in the linux syscall mechanism.  The syscall tapset updates are still in progress and a number of the examples still fail as a result.  Using the kernel.trace("sys_enter") in place of the syscall.* and kernel.trace("sys_exit") in place of the syscall.*.return can improve this situation.  The WIP attached patch changes 9 FAIL and 8 UNSUPPORTED into PASSES.  It does result in faster compilation of the instrumentation and smaller kernel modules.
>
> There are a couple issues with the patch right now.  The direct use of kernel.trace("sys_enter") and kernel.trace("sys_exit") might not be that clear to readers of the script, but using the raw tracepoints will allow some of the examples to work with older versions of systemtap.  For the kernel.trace("sys_exit") is quite common to need the syscall number or name.  There is an internal function _stp_syscall_nr() that provides that information.  It would be good to have an official user visible function for this value.
>
> What comments and feedback do people have about the patch?
>
> -Will
>
>


-- 
David Smith
Associate Manager
Red Hat