<?xml version='1.0'?>
<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
]>

<section id="scriptconstructions">
<title>Basic SystemTap Handler Constructs</title>
<indexterm>
<primary>handlers</primary>
<secondary>SystemTap handler constructs</secondary>
</indexterm>

<indexterm>
<primary>SystemTap handlers</primary>
<secondary>SystemTap handler constructs</secondary>
</indexterm>

<!-- next 2 indexterms for syntax and format -->

<indexterm>
<primary>handlers</primary>
<secondary>SystemTap handler constructs</secondary>
<tertiary>syntax and format</tertiary>
</indexterm>

<indexterm>
<primary>SystemTap handlers</primary>
<secondary>SystemTap handler constructs</secondary>
<tertiary>syntax and format</tertiary>
</indexterm>

<indexterm>
<primary>syntax and format</primary>
<secondary>SystemTap handler constructs</secondary>
<tertiary>handlers</tertiary>
</indexterm>
	<para>SystemTap supports the use of several basic constructs in handlers. The syntax for most of these handler constructs are mostly based on C and <command>awk</command> syntax. This section describes several of the most useful SystemTap handler constructs, which should provide you with enough information to write simple yet useful SystemTap scripts.</para>

<section id="variablesconstructs">
	<title>Variables</title>
<!-- next 3 indexterms for variables -->
<indexterm>
<primary>handlers</primary>
<secondary>SystemTap handler constructs</secondary>
<tertiary>variables</tertiary>
</indexterm>

<indexterm>
	<primary>SystemTap statements</primary>
<secondary>SystemTap handler constructs</secondary>
<tertiary>variables</tertiary>
</indexterm>

<indexterm>
<primary>variables</primary>
<secondary>SystemTap handler constructs</secondary>
<tertiary>handlers</tertiary>
</indexterm>

<indexterm>
	<primary>format and syntax</primary>
	<secondary>SystemTap handler constructs</secondary>
	<tertiary>handlers</tertiary>
</indexterm>
	<para>Variables can be used freely throughout a handler; simply choose a
name, assign a value from a function or expression to it, and use it in an expression. SystemTap automatically identifies whether a variable should be typed as a string or integer, based on the type of the values assigned to it. For instance, if you use set the variable <command>foo</command> to <command>gettimeofday_s()</command> (as in <command>foo = gettimeofday_s()</command>), then <command>foo</command> is typed as a number and can be printed in a <command>printf()</command> with the integer format specifier (<command>%d</command>).</para>

<!-- next 2 indexterms for <command>global</command> -->

<indexterm>
<primary>handlers</primary>
<secondary>SystemTap handler constructs</secondary>
<tertiary><command>global</command></tertiary>
</indexterm>

<indexterm>
	<primary>SystemTap statements</primary>
<secondary>SystemTap handler constructs</secondary>
<tertiary><command>global</command></tertiary>
</indexterm>

<indexterm>
<primary><command>global</command></primary>
<secondary>SystemTap handler constructs</secondary>
<tertiary>handlers</tertiary>
</indexterm>
<para>Note, however, that by default variables are only local to the probe they are used in. This means that variables are initialized, used and disposed at each probe handler invocation. To share a variable between probes, declare the variable name using <command>global</command> outside of the probes. Consider the following example:</para>

<example id="timerjiffies">
	<title>timer-jiffies.stp</title>
<programlisting>global count_jiffies, count_ms
probe timer.jiffies(100) { count_jiffies ++ }
probe timer.ms(100) { count_ms ++ }
probe timer.ms(12345)
{
  hz=(1000*count_jiffies) / count_ms
  printf ("jiffies:ms ratio %d:%d => CONFIG_HZ=%d\n",
    count_jiffies, count_ms, hz)
  exit ()
}</programlisting>
</example>

<indexterm>
<primary><command>CONFIG_HZ, computing for</command></primary>
</indexterm>

<para><xref linkend="timerjiffies"/> computes the <command>CONFIG_HZ</command> setting of the kernel using timers that count jiffies and milliseconds, then computing accordingly. The <command>global</command> statement allows the script to use the variables <command>count_jiffies</command> and <command>count_ms</command> (set in their own respective probes) to be shared with <command>probe timer.ms(12345)</command>.</para>

<note>
	<title>Note</title>
	<para>The <command>++</command> notation in <xref linkend="timerjiffies"/> (that is, <command>count_jiffies ++</command> and <command>count_ms ++</command>) is used to increment the value of a variable by 1. In the following probe, <command>count_jiffies</command> is incremented by 1 every 100 jiffies:</para>
<screen>probe timer.jiffies(100) { count_jiffies ++ }</screen>
	<para>In this instance, SystemTap understands that <command>count_jiffies</command> is an integer. Because no initial value was assigned to <command>count_jiffies</command>, its initial value is zero by default.</para>
</note>
<!--
<note>
	<title>Note</title>
	<para>In some cases, such as in <xref linkend="timerjiffies"/>, a variable may be declared without any specific value as yet. You need to declare such values as integers using the notation <command>++</command>.</para>
</note>
	-->
</section>

<section id="targetvariables">
	<title>Target Variables</title>

<indexterm>
<primary>handlers</primary>
<secondary>target variables</secondary>
</indexterm>

<indexterm>
<primary>target variables</primary>
</indexterm>

<para>
The probe events that map to actual locations in the code (for example
<command>kernel.function("<replaceable>function</replaceable>")</command>  and
<command>kernel.statement("<replaceable>statement</replaceable>")</command>)
allow the use of <emphasis>target variables</emphasis> to obtain the value of
variables visible at that location in the code.
You can use the <command>-L</command> option to list the target variable available at a
probe point.
If the debug information is installed for the running kernel,
you can run the following command to find out what target variables
are available for the <command>vfs_read</command> function:
</para>

<screen>stap -L 'kernel.function("vfs_read")'</screen>

<para>
This will yield something similar to the following:
</para>

<screen>kernel.function("vfs_read@fs/read_write.c:277") $file:struct file* $buf:char* $count:size_t $pos:loff_t*</screen>

<para>
Each target variable is proceeded by a <quote><command>$</command></quote> and 
the type of the target variable follows the <quote><command>:</command></quote>.
The kernel's <command>vfs_read</command> function has
<command>$file</command> (pointer to structure describing the file),
<command>$buf</command> (pointer to the user-space memory to store the read data),
<command>$count</command> (number of bytes to read),
and <command>$pos</command> (position to start reading from in the file)
target variables at the entry to the function.
</para>

<para>
When a target variable is not local to the probe point, like a global
external variable or a file local static variable defined in another file
then it can be referenced through
<quote><command>@var("<replaceable>varname</replaceable>@<replaceable>src/file.c</replaceable>")</command></quote>.
</para>

<para>
It is also supported to specify an executable or library file path as the
second argument, as in
<quote><command>@var("<replaceable>varname</replaceable>", "<replaceable>/path/to/exe/or/lib</replaceable>")</command></quote>
</para>

<para>
SystemTap tracks the typing information of the target variable and can
examine the fields of a structure with the <command>-></command> operator.
The <command>-></command> operator can be chained to look at data structures
contained within data structures and follow pointers to other data structures.
The <command>-></command> operator will obtain the value in the field of the
structure.
The <command>-></command> operator is used regardless whether accessing a field
in a substructure or accessing another structure through a pointer.
</para>

<para>
For example to access a field of the static files_stat target variable
defined in fs/file_table.c (which holds some of the current file system
sysctl tunables), one could write:
</para>

<screen>
stap -e 'probe kernel.function("vfs_read") {
           printf ("current files_stat max_files: %d\n",
                   @var("files_stat@fs/file_table.c")->max_files);
           exit(); }'
</screen>

<para>
Which will yield something similar to the following:
</para>

<screen>
current files_stat max_files: 386070
</screen>

<para>
For pointers to base types such as integers and strings
there are a number of functions listed below to access kernel-space data.
The first argument for each functions is the pointer to the data item.
Similar functions are described in <xref linkend="utargetvariable"/> for
accessing target variables in user-space code.
</para>

<variablelist>

<varlistentry>
<term>kernel_char(<replaceable>address</replaceable>)</term>
<listitem>
<para>
Obtain the character at <replaceable>address</replaceable> from kernel memory.
</para>
</listitem>
</varlistentry>

<varlistentry>
<term>kernel_short(<replaceable>address</replaceable>)</term>
<listitem>
<para>
Obtain the short at <replaceable>address</replaceable> from kernel memory.
</para>
</listitem>
</varlistentry>

<varlistentry>
<term>kernel_int(<replaceable>address</replaceable>)</term>
<listitem>
<para>
Obtain the int at <replaceable>address</replaceable> from kernel memory.
</para>
</listitem>
</varlistentry>

<varlistentry>
<term>kernel_long(<replaceable>address</replaceable>)</term>
<listitem>
<para>
Obtain the long at <replaceable>address</replaceable> from kernel memory
</para>
</listitem>
</varlistentry>

<varlistentry>
<term>kernel_string(<replaceable>address</replaceable>)</term>
<listitem>
<para>
Obtain the string at <replaceable>address</replaceable> from kernel memory.
</para>
</listitem>
</varlistentry>

<varlistentry>
<term>kernel_string_n(<replaceable>address</replaceable>, <replaceable>n</replaceable>)</term>
<listitem>
<para>
Obtain the string at <replaceable>address</replaceable> from the kernel memory
and limits the string to <replaceable>n</replaceable> bytes.
</para>
</listitem>
</varlistentry>

</variablelist>

<section id="targetprettyprinting">
	<title>Pretty Printing Target Variables</title>
<indexterm>
<primary>target variables</primary>
<secondary>pretty printing</secondary>
</indexterm>

<para>
	SystemTap scripts are often used to observe what is happening within
	the code.
	In many cases just printing the values of the various context variables
	is sufficient.
	SystemTap makes a number operations available that can generate
	printable strings for target variables:
</para>

<variablelist>
	<varlistentry>
	  <term>$$vars</term>
	  <listitem>
	    <para>
	      Expands to a character string that is equivalent to
	      <command>sprintf("parm1=%x ... parmN=%x var1=%x ... varN=%x",
	      parm1, ..., parmN, var1, ..., varN)</command>
	      for  each  variable  in  scope  at the probe point.
	      Some values may be printed as <quote><command>=?</command></quote>
	      if their run-time location cannot be found.
	    </para>
	  </listitem>
	</varlistentry>


	<varlistentry>
	  <term>$$locals</term>
	  <listitem>
	    <para>
              Expands to a subset of <command>$$vars</command>
	      containing only the local variables.
	    </para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term>$$parms</term>
	  <listitem>
	    <para>
              Expands to a subset of <command>$$vars</command>
	      containing only the function parameters.
	    </para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term>$$return</term>
	  <listitem>
	    <para>
              Is available in return probes only.  It expands to a string that
              is equivalent to 
	      <command>sprintf("return=%x",  $return)</command> if the probed
              function has a return value, or else an empty string.
	    </para>
	  </listitem>
	</varlistentry>
      </variablelist>

<para>
	Below is a command-line script that prints the values of the
	parameters passed into the function <command>vfs_read</command>:
</para>

<programlisting>stap -e 'probe kernel.function("vfs_read") {printf("%s\n", $$parms); exit(); }'</programlisting>

<para>
	There are four parameters passed into <command>vfs_read</command>:
	<command>file</command>, <command>buf</command>,
	<command>count</command>, and <command>pos</command>.
	The <command>$$parms</command> generates a string for the parameters
	passed into the function. In this case all but the
	<command>count</command> parameter are pointers. The following
	is an example of the output from the previous command-line script:
</para>

<programlisting>file=0xffff8800b40d4c80 buf=0x7fff634403e0 count=0x2004 pos=0xffff8800af96df48</programlisting>

<para>
	Having the address a pointer points to may not be useful.
	Instead the fields of the data structure the pointer points to may be of more use.
	Use the <quote><command>$</command></quote> suffix to pretty print
	the data structure.
	The following command-line example uses the pretty printing suffix to
	print more details about the data structures passed into the function
	<command>vfs_read</command>:
</para>

<programlisting>stap -e 'probe kernel.function("vfs_read") {printf("%s\n", $$parms$); exit(); }'</programlisting>

<para>
	The previous command line will generate something similar to the
	following with the fields of the data structure included in the output:
</para>

<programlisting>file={.f_u={...}, .f_path={...}, .f_op=0xffffffffa06e1d80, .f_lock={...}, .f_count={...}, .f_flags=34818, .f_mode=31, .f_pos=0, .f_owner={...}, .f_cred=0xffff88013148fc80, .f_ra={...}, .f_version=0, .f_security=0xffff8800b8dce560, .private_data=0x0, .f_ep_links={...}, .f_mapping=0xffff880037f8fdf8} buf="" count=8196 pos=-131938753921208</programlisting>

<para>
	With the <quote><command>$</command></quote> suffix fields that are composed of 
	data structures are not expanded.
	The <quote><command>$$</command></quote> suffix will print the values contained within
	the nested data structures.
	Below is an example using the <quote><command>$$</command></quote> suffix:
</para>

<programlisting>stap -e 'probe kernel.function("vfs_read") {printf("%s\n", $$parms$$); exit(); }'</programlisting>

<para>
	The <quote><command>$$</command></quote> suffix, like all strings,
	is limited to the maximum string size.
	Below is a representative output from the previous command-line script,
	which is truncated because of the string size limit:
</para>

<programlisting>file={.f_u={.fu_list={.next=0xffff8801336ca0e8, .prev=0xffff88012ded0840}, .fu_rcuhead={.next=0xffff8801336ca0e8, .func=0xffff88012ded0840}}, .f_path={.mnt=0xffff880132fc97c0, .dentry=0xffff88001a889cc0}, .f_op=0xffffffffa06f64c0, .f_lock={.raw_lock={.slock=196611}}, .f_count={.counter=2}, .f_flags=34818, .f_mode=31, .f_pos=0, .f_owner={.lock={.raw_lock={.lock=16777216}}, .pid=0x0, .pid_type=0, .uid=0, .euid=0, .signum=0}, .f_cred=0xffff880130129a80, .f_ra={.start=0, .size=0, .async_size=0, .ra_pages=32, .</programlisting>

</section>

<section id="typecasting">
	<title>Typecasting</title>
<indexterm>
<primary>target variables</primary>
<secondary>typecasting</secondary>
</indexterm>

<para>
	In most cases SystemTap can determine a variable's type
	from the debug information.
	However, code may use void pointers for variables
	(for example memory allocation routines) and typing information is
	not available.
	Also the typing information available within a probe handler is not
	available within a function;
	SystemTap functions arguments use a long in place of a typed pointer.
	SystemTap's <command>@cast</command> operator (first available in 
	SystemTap 0.9) can be used to indicate
	the correct type of the object.
</para>

<para>
	The <xref linkend="casting"/> is from the
	<command>task.stp</command> tapset.
	The function returns the value of the <command>state</command>
	field from a <command>task_struct</command> pointed to by
	the long <command>task</command>.
	The first argument of the <command>@cast</command> operator,
	<command>task</command>, is the pointer to the object.
	The second argument is the type to cast the object to,
	<command>task_struct</command>.
	The third argument lists what file that the type definition
	information comes from and is optional.
	With the <command>@cast</command> operator the various fields of
	this particular  <command>task_struct</command> <command>task</command>
	can be accessed; in this example the <command>state</command> field
	is obtained.
</para>

<example id="casting">
	<title>Casting Example</title>
<programlisting><xi:include parse="text" href="extras/cast_example.stp" xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
</example>

</section>

<section id="targetavailable">
	<title>Checking Target Variable Availability</title>
<indexterm>
<primary>target variables</primary>
<secondary>variable availability</secondary>
</indexterm>

<para>
	As code evolves the target variables available may change.
	The <command>@defined</command> makes it easier to handle
	those variations in the available target variables.
	The <command>@defined</command> provides a test to see if a particular
	target variable is available. The result of this test
	can be used to select the appropriate expression.
</para>

<para>
	The <xref linkend="available"/> from the
	<command>memory.stp</command> tapset provides an probe event alias.
	Some version of the kernel functions being probed have an argument
	<command>$flags</command>. When available, the
	<command>$flags</command> argument is used to generate
	the local variable <command>write_access</command>.
	The versions of the probed functions that do not have the
	<command>$flags</command> argument have a <command>$write</command>
	argument and that is used instead for the local variable
	<command>write_access</command>.
</para>

<example id="available">
	<title>Testing target variable available Example</title>
<programlisting><xi:include parse="text" href="extras/defined_example.stp" xmlns:xi="http://www.w3.org/2001/XInclude" /></programlisting>
</example>

</section>

</section>

<section id="handlerconditionalstatements">
	<title>Conditional Statements</title>
<indexterm>
<primary>handlers</primary>
<secondary>conditional statements</secondary>
</indexterm>

<indexterm>
	<primary>SystemTap statements</primary>
<secondary>conditional statements</secondary>
</indexterm>
<para>
In some cases, the output of a SystemTap script may be too large. To address this, you need to further refine the script's logic in order to delimit the output into something more relevant or useful to your probe.
</para>
<!-- </formalpara> -->
<para>
Do this by using <emphasis>conditionals</emphasis> in handlers. SystemTap accepts the following types of conditional statements:
</para>

<variablelist>
<varlistentry>
	<term>If/Else Statements</term>
	<listitem>
<!-- next 3 indexterms for if/else -->
<indexterm>
<primary>handlers</primary>
<secondary>conditional statements</secondary>
<tertiary>if/else</tertiary>
</indexterm>

<indexterm>
	<primary>SystemTap statements</primary>
<secondary>conditional statements</secondary>
<tertiary>if/else</tertiary>
</indexterm>

<indexterm>
<primary>if/else</primary>
<secondary>conditional statements</secondary>
<tertiary>handlers</tertiary>
</indexterm>

		<para>Format:</para>
<programlisting>if (<replaceable>condition</replaceable>)
  <replaceable>statement1</replaceable>
else
  <replaceable>statement2</replaceable></programlisting>

<para>
The <command><replaceable>statement1</replaceable></command> is executed if the
<command><replaceable>condition</replaceable></command> expression is
non-zero. The <command><replaceable>statement2</replaceable></command> is
executed if the <command><replaceable>condition</replaceable></command>
expression is zero. The <command>else</command> clause
(<command>else</command> <replaceable>statement2</replaceable>) is optional. Both
<command><replaceable>statement1</replaceable></command> and
<command><replaceable>statement2</replaceable></command> can be statement
blocks.
</para>

<example id="simpleifelseexample">
	<title>ifelse.stp</title>
<programlisting>global countread, countnonread
probe kernel.function("vfs_read"),kernel.function("vfs_write")
{
  if (probefunc()=="vfs_read")
    countread ++
  else
    countnonread ++
}
probe timer.s(5) { exit() }
probe end
{
  printf("VFS reads total %d\n VFS writes total %d\n", countread, countnonread)
}</programlisting>
</example>

<para><xref linkend="simpleifelseexample"/> is a script that counts how many virtual file system reads (<command>vfs_read</command>) and writes (<command>vfs_write</command>) the system performs within a 5-second span. When run, the script increments the value of the variable <command>countread</command> by 1 if the name of the function it probed matches <command>vfs_read</command> (as noted by the condition <command>if (probefunc()=="vfs_read")</command>); otherwise, it increments <command>countnonread</command> (<command>else {countnonread ++}</command>).</para>

	</listitem>
</varlistentry>

<varlistentry>
	<term>While Loops</term>
	<listitem>
<!-- next 2 indexterms for while loops -->

<indexterm>
<primary>handlers</primary>
<secondary>conditional statements</secondary>
<tertiary>while loops</tertiary>
</indexterm>

<indexterm>
	<primary>SystemTap statements</primary>
<secondary>conditional statements</secondary>
<tertiary>while loops</tertiary>
</indexterm>

<indexterm>
<primary>while loops</primary>
<secondary>conditional statements</secondary>
<tertiary>handlers</tertiary>
</indexterm>
		<para>Format:</para>
<programlisting>while (<replaceable>condition</replaceable>)
  <replaceable>statement</replaceable></programlisting>
<para>
So long as <command><replaceable>condition</replaceable></command> is non-zero
the block of statements in
<command><replaceable>statement</replaceable></command> are executed. The
<command><replaceable>statement</replaceable></command> is often a statement
block and it must change a value so
<command><replaceable>condition</replaceable></command> will eventually be zero.
</para>
<!--
<example id="simplewhileexample">
	<title>while.stp</title>
<programlisting>global foo
probe timer.s(1) {
foo ++
while (foo&lt;6) {printf("hello world\n")}
printf("goodbye world\n")</programlisting>
</example>

<para><xref linkend="simplewhileexample"/> is a script that prints <computeroutput>hello world</computeroutput> while less than 6 seconds has passed (<command>while (foo&lt;6)</command>). Once the <command>while</command> condition no longer applies, the script prints out <computeroutput>goodbye world</computeroutput>.</para>

	--></listitem>
</varlistentry>

<varlistentry>
	<term>For Loops</term>
	<listitem>
<!-- next 2 indexterms for for loops -->

<indexterm>
<primary>handlers</primary>
<secondary>conditional statements</secondary>
<tertiary>for loops</tertiary>
</indexterm>

<indexterm>
	<primary>SystemTap statements</primary>
<secondary>conditional statements</secondary>
<tertiary>for loops</tertiary>
</indexterm>

<indexterm>
<primary>for loops</primary>
<secondary>conditional statements</secondary>
<tertiary>handlers</tertiary>
</indexterm>
		<para>Format:</para>
<programlisting>for (<replaceable>initialization</replaceable>; <replaceable>conditional</replaceable>; <replaceable>increment</replaceable>) <replaceable>statement</replaceable></programlisting>
<para>
The <command>for</command> loop is shorthand for a while loop. The
following is the equivalent <command>while</command> loop:
</para>
<programlisting><replaceable>initialization</replaceable>
while (<replaceable>conditional</replaceable>) {
   <replaceable>statement</replaceable>
   <replaceable>increment</replaceable>
}</programlisting>
	</listitem>
</varlistentry>

<!--<para>Each conditional statement must be enclosed in <command>{ }</command>.</para>-->
<!--
<varlistentry>
	<term></term>
	<listitem>
		<para></para>
	</listitem>
</varlistentry>
-->

</variablelist>
<!--
<para>These constructs are better illustrated in the different examples available in <xref linkend="useful-systemtap-scripts"/>.</para>-->

<remark>need simple, simple examples for FOR and WHILE</remark>

<formalpara>
	<title>Conditional Operators</title>
<!-- next 2 indexterms for conditional operators -->

<indexterm>
<primary>handlers</primary>
<secondary>conditional statements</secondary>
<tertiary>conditional operators</tertiary>
</indexterm>

<indexterm>
	<primary>SystemTap statements</primary>
<secondary>conditional statements</secondary>
<tertiary>conditional operators</tertiary>
</indexterm>

<indexterm>
<primary>conditional operators</primary>
<secondary>conditional statements</secondary>
<tertiary>handlers</tertiary>
</indexterm>

<para>Aside from <command>==</command> ("is equal to"), following operators can also be used in conditional statements:</para>
</formalpara>

<variablelist>

<varlistentry>
	<term>>=</term>
	<listitem>
		<para>Greater than or equal to</para>
	</listitem>
</varlistentry>

<varlistentry>
	<term>&lt;=</term>
	<listitem>
		<para>Less than or equal to</para>
	</listitem>
</varlistentry>

<varlistentry>
	<term>!=</term>
	<listitem>
		<para>Is not equal to</para>
	</listitem>
</varlistentry>

</variablelist>
</section>
<section id="commandlineargssect">
	<title>Command-Line Arguments</title>
<indexterm>
<primary>handlers</primary>
<secondary>SystemTap handler constructs</secondary>
<tertiary>command-line arguments</tertiary>
</indexterm>

<indexterm>
	<primary>SystemTap statements</primary>
<secondary>SystemTap handler constructs</secondary>
<tertiary>command-line arguments</tertiary>
</indexterm>

<indexterm>
<primary>command-line arguments</primary>
<secondary>SystemTap handler constructs</secondary>
<tertiary>handlers</tertiary>
</indexterm>
	<para>A SystemTap script can also accept simple command-line arguments using a  <command>$</command> or <command>@</command> immediately
followed by the number of the argument on the command line. Use <command>$</command> if you are expecting the user to enter an integer as a command-line argument, and <command>@</command> if you are expecting a string.
</para>
<!-- </formalpara> -->


<example id="commandlineargs"><title>commandlineargs.stp</title>
<programlisting>probe kernel.function(@1) { }
probe kernel.function(@1).return { }</programlisting>
</example>

<para><xref linkend="commandlineargs"/> is similar to <xref linkend="wildcards"/>, except that it allows you to pass the kernel function to be probed as a command-line argument (as in <command>stap commandlineargs.stp <replaceable>kernel function</replaceable></command>). You can also specify the script to accept multiple command-line arguments, noting them as <command>@1</command>, <command>@2</command>, and so on, in the order they are entered by the user.</para>
 <!-- next 2 indexterms for variable notations -->

<indexterm>
<primary>handlers</primary>
<secondary>SystemTap handler constructs</secondary>
<tertiary>variable notations</tertiary>
</indexterm>

<indexterm>
	<primary>SystemTap statements</primary>
<secondary>SystemTap handler constructs</secondary>
<tertiary>variable notations</tertiary>
</indexterm>

<indexterm>
<primary>variable notations</primary>
<secondary>SystemTap handler constructs</secondary>
<tertiary>handlers</tertiary>
</indexterm>
	</section>

<!-- endsection	 -->
</section>