Re: Kernel 4.4.0 support

[David Smith <dsmith at redhat dot com>]

On Tue, Jul 4, 2017 at 2:35 AM, Arkady <arkady.miasnikov@gmail.com> wrote:
> Hi,
>
> I am building an STAP  driver  for
>
> Linux ubuntu 4.4.0-83-generic #106~14.04.1-Ubuntu SMP Mon Jun 26
> 18:10:19 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
>
> I have build the latest STAP (original STAP is 2.3 and fails to
> compile Hello, world)
>
> $ stap --version
> Systemtap translator/driver (version 3.2/0.158, commit
> release-3.1-121-g1c753c3afb0e + changes)
> Copyright (C) 2005-2017 Red Hat, Inc. and others
> This is free software; see the source for copying conditions.
> tested kernel versions: 2.6.18 ... 4.11
> enabled features: NLS
>
> These single liners work fine
>
> sudo stap -e 'probe begin { printf("Hello, World!\n"); exit() }'
> stap -p4 -e 'probe syscall.open {printf("%s %u %u\n", filename, flags, mode);}'
>
> In this script
> stap -p4 -e 'probe kprocess.exec {printf("%u %u %u\n", $filename,
> $name, $argv);}'
> $name (Name of the system call) is not found:
>
> semantic error: unable to find local 'name', [man error::dwarf]
> dieoffset 0x1e67307 in kernel, near pc 0xffffffff81209110 in
> SyS_execve /build/linux-lts-xenial-ep3zLI/linux-lts-xenial-4.4.0/fs/exec.c
> (alternatives: $filename, $ret, $argv, $envp)): identifier '$name' at
> <input>:1:55

There are (in general) 2 kinds of variables in systemtap. Target (or
context) variables, in this case dwarf variables, that are prefixed
with '$', and systemtap language variables.

probe kernel.function("foo")
{
    systemtap_language_variable = $context_variable
}

Our systemtap tapset probes provide systemtap language variables for
each tapset probe. We call these convenience variables, since we try
to 'conveniently' provide the values you need already processed. You
used the tapset convenience variables 'filename', 'flags', and 'mode'
in your syscall.open example above. One advantage to using tapset
convenience variables is that we try to keep them updated when the
underlying kernel api changes. Using syscall.open for an example, if
the underlying syscall changed '$filename' to '$fname' the
syscall.open probe alias would hide that detail from the user and he
could keep using 'filename' and not have to worry that the underlying
dwarf variable changed names from '$filename' to '$fname'.

In your kprocess.exec problem above I'm not 100% sure what you were
trying to do. You may have been trying to use convenience variables
but accidentally put a '$' in front of them. The following should work
fine:

stap -p4 -e 'probe kprocess.exec { printf("%s, %s, %s\n", filename,
name, args) }'

If that isn't what you were trying to do let me know.

> The following line fails for $pid
>
> stap -p4 -e 'probe scheduler.process_exit {printf("%u %s %u\n", $pid,
> $name, $priority);}'
> semantic error: while processing probe __scheduler.process_exit.tp
> from: scheduler.process_exit from: scheduler.process_exit
> semantic error: unable to find tracepoint variable '$pid'
> (alternatives: $p, $$name, $$parms, $$vars): identifier '$pid' at
> <input>:1:52
>         source: probe scheduler.process_exit {printf("%u %s %u\n",
> $pid, $name, $priority);}
>                                                                    ^
> semantic error: unable to find tracepoint variable '$pid'
> (alternatives: $p, $$name, $$parms, $$vars): identifier '$pid' at
> :1:52
>         source: probe scheduler.process_exit {printf("%u %s %u\n",
> $pid, $name, $priority);}

Once again it looks like you mistakenly put a '$' in front of the
tapset convenience variable names. I think you meant to do the
following (which works just fine):

stap -p4 -e 'probe scheduler.process_exit {printf("%u %s %u\n", pid,
name, priority);}'


-- 
David Smith
Principal Software Engineer
Red Hat