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]

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




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