This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Some functional test examples
- From: Kevin Stafford <kevinrs at us dot ibm dot com>
- To: systemtap at sources dot redhat dot com
- Date: Fri, 02 Sep 2005 13:55:30 -0700
- Subject: Some functional test examples
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).
Almost every probe test case operates on the sys_open kernel function
found in fs/open.c. All hardcoded line numbers are in reference to
RHEL kernel 2.6.9-17.ELsmp.
Comments please.
___________________________________________________________________
# 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")
}
___________________________________________________________________
# 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.
probe kernel.function("sys_open")
%{
printk("I am embedded C\n");
%}
___________________________________________________________________
# This works as expected.
# Generates and loads .ko. I guess you can _only_
# delegate work to auxilary embedded C functions,
# rather than probe functions. This is no problem.
# If this is true, however, I do not think that
# this is explicitly spelled out in the man page.
function do_embedded()
%{
printk("Hello from embedded C\n");
%}
probe kernel.function("sys_open")
{
do_embedded();
}
___________________________________________________________________
# This works as expected.
function do_int_pass(param)
{
return param - 5;
}
function do_string_pass(param)
{
return param . " World"
}
probe kernel.function("sys_open")
{
log(string(do_int_pass(5)));
log(do_string_pass("Hello"))
}
___________________________________________________________________
# 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);
%}
probe kernel.function("sys_open")
{
log(embed_param_pass($filename));
}
___________________________________________________________________
# This works too.
function embed_param_pass(param)
%{
THIS->__retvalue = THIS->param - 5;
%}
probe kernel.function("sys_open")
{
log(string(embed_param_pass(5)));
}
___________________________________________________________________
# This works too.
function embed_param_pass(param)
%{
printk("SystemTap param = %Ld\n",THIS->param);
%}
probe kernel.function("sys_open")
{
embed_param_pass(5000);
}
___________________________________________________________________
# This I am sure is a cockpit error. I
# do not know how to properly return a
# string from an embedded C function to
# a regular probe script function. I
# highly doubt the translator has anything
# to do with this. Some help on how to do
# this would be nice.
function embed_param_pass(param)
%{
THIS->__retvalue = THIS->param;
%}
probe kernel.function("sys_open")
{
log(embed_param_pass("Hello"));
}
___________________________________________________________________
# 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. Perhaps something more can be
# provided: [i.e. ERROR: cannot resolve variable
# '$fd']
probe kernel.function("sys_open")
{
log(string($fd))
}
___________________________________________________________________
# Why is this not working??? I think this is
# a bug. Param resolution should not fail.
probe kernel.function("sys_close")
{
log(string($fd))
}
___________________________________________________________________
# Hmmm...this isn't working for me. I think
# it should, according to the stap man page:
#
# "The .return variant places a probe at
# the moment of return from the named
# function, so the return value is
# available as the "$retvalue"
# context variable."
probe kernel.function("sys_open").return
{
log(string($retvalue))
}
___________________________________________________________________
# I didn't expect this to work. It may be
# useful to have access to the registers.
# Maybe as a built in (like get_pid()).
probe kernel.function("sys_open").return
{
log(string($regs->eax))
}
___________________________________________________________________
# 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"){ }
___________________________________________________________________
# This example attempts to place probes by specifying
# line numbers which are outside of the sys_open
# definition. This should, and does fail.
#
# Note: This probe should be run on 2.6.9-17.ELsmp
probe kernel.function("sys_open@fs/open.c:945"){ }
probe kernel.function("sys_open@fs/open.c:975"){ }
___________________________________________________________________
# This is an example of how to place a probe in at
# an arbitrary location (i.e. within a function)
probe kernel.statement("*@fs/open.c:959")
{
log($tmp . " " . string($flags) . " " . string($mode))
}
___________________________________________________________________
# 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
#
# These are invalid fd's
probe kernel.statement("*@fs/open.c:958")
{
log(string($fd) . " " . $tmp)
}
___________________________________________________________________
# 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?
#
# Note: This probe should be run on 2.6.9-17.ELsmp
probe kernel.statement("*@fs/open.c:959") { log($tmp) }
probe kernel.statement("sys_open@fs/open.c:959") { log($tmp) }
___________________________________________________________________
# 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 time reference to $tmp seg faults
# & I am unsure why it is resolved in the first
# place. See above.
#
# Note: This probe should be run on 2.6.9-17.ELsmp
probe kernel.statement("sys_open@fs/open.c:942") { log($tmp) }
___________________________________________________________________
# This is more appropriate behavior. Line 974 is outside
# the definition of sys_open. The script fails to compile.
#
# Note: This probe should be run on 2.6.9-17.ELsmp
probe kernel.statement("sys_open@fs/open.c:975") { log($tmp) }
___________________________________________________________________
--
Kevin Stafford
DES 2 | MS 2M3
Beaverton - OR
Linux Technology Center
IBM Systems & Technology
Phone: 1-503-578-3039
Email: kevinrs@us.ibm.com