Re: Some functional test examples

[fche at redhat dot com (Frank Ch. Eigler)]

kevinrs wrote:

> Here are some SystemTap useability test cases that I have compiled.
> I would like to eventually check these into CVS (when I get write
> access).

Please use the "handy dandy little form" link on the project web page
for CVS access.

> [...]
> # Line 975 in open.c is a whitespace between
> # two function definitions. Maybe it would
> # be more appropriate to simply not allow a
> # user to probe an address that will never be
> # executed.
> #
> # Note: This is seen in 2.6.9-17.ELsmp
> probe kernel.statement("*@fs/open.c:975")
> {
>    log("This text will never appear")
> }

If this line number is not included in any function definition, then
systemtap should signal an error.


> # I guess you cannot embed C code in a
> # probe or probe alias. If this is true,
> # I do not think that this is explicitly
> # spelled out in the man page. [...]

See the "EMBEDDED C" section in stap(1).  It says that %{ %} is
acceptable in two places: at the top level, and as function bodies.


> [...]
> # This will error out. I suppose this is
> # expected as $filename is a pointer to a
> # string rather than a string literal. Not
> # to mention the userspace pointer compli-
> # cations.
> 
> function embed_param_pass(param)
> %{
>         THIS->__retvalue = getname(THIS->param);
> %}

This detail is covered in the man page also.  As hunt wrote, strings
are passed by value (as a fixed-size array).

> probe kernel.function("sys_open")
> {
>         log(embed_param_pass($filename));
> }

As a consequence of bug #1187-prime, this will have to look like:
         log( ...  (user_string($filename)) ... )
to express an explicit user-to-kernel string copy.


> [...]
> # This probe attempts to access local var 'fd'
> # which should fail. (fd is a local declared
> # after the entry point) 'Segmentation fault',
> # however seems like an inapropriate error
> # message. [...]
>
> probe kernel.function("sys_open")
> {
>    log(string($fd))
> }

This may be the same as bug #1257.  If not, please send a new bug
report, preferably with a stack traceback.


> [...]
> # Hmmm...this isn't working for me. I think
> # it should, according to the stap man page:
> [...]
> probe kernel.function("sys_open").return
> {
>    log(string($retvalue))
> }

See bug #1132, blocked on an elfutils extension.


> [...]
> # This works. The four lines are functionally
> # equivalent (they all put the probe in the
> # exact same place)
> # Note: This probe should be run on 2.6.9-17.ELsmp
> 
> probe kernel.function("sys_open@fs/open.c:946"){  }
> probe kernel.function("sys_open@fs/open.c:974"){  }
> probe kernel.function("sys_open@fs/open.c"){  }
> probe kernel.function("sys_open"){  }

Adding test cases like this to the test suite will be tricky.
It'd have to include a test against kernel version.


> [...]
> # This produces some bogus results:
> # [...]
> #  4 include/linux/vermagic.h
> #  -232923136 include/linux/version.h
> #  4 include/linux/version.h
> #  -157716480 /tmp/stapWlhyz9/.stap_0_1125682998.mod.o.d

This is a bug somewhere.  A new bugzilla entry, with "stap -v" output,
would be great.


> [...]
> # It is interesting that all of these are equivalent
> # statements (they all place the probe at the same
> # address). Is there an advantage to using one syntax
> # over the other? [...]
> probe kernel.statement("*@fs/open.c:959") { log($tmp) }
> probe kernel.statement("sys_open@fs/open.c:959") { log($tmp) }

I can't think of any interesting implications of one choice
vs. another.


> # This does not seem right, as line 942 contains
> # the closing brace of a different function
> # definition (fd_install() to be exact). Why then
> # is this matching sys_open? Why does this compile?
> #
> # Note: This probe should be run on 2.6.9-17.ELsmp
> 
> probe kernel.statement("sys_open@fs/open.c:942") { }
> [...]

This is a bug. 


- FChE