path: root/doc/SystemTap_Beginners_Guide/en-US/Scripts.xml

<?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="scripts">
	<title>SystemTap Scripts</title>
	
	<para>
		For the most part, SystemTap scripts are the foundation of each SystemTap session. SystemTap scripts instruct SystemTap on what type of information to trap, and what to do once that information is trapped.
	</para>
	
	<para>
		As stated in <xref linkend="understanding-how-systemtap-works"/>, SystemTap scripts are made up of two components: <emphasis>events</emphasis> and <emphasis>handlers</emphasis>. Once a SystemTap session is underway, SystemTap monitors the operating system for the specified events and executes the handlers as they occur. 
	</para>
	
<note>
	<title>Note</title>
	<para>An event and its corresponding handler is collectively called a <emphasis>probe</emphasis>. A SystemTap script can have multiple probes.</para>
</note>	
	
	<para>
		In terms of application development, using events and handlers is similar to inserting <command>print</command> statements in a program's sequence of commands. These <command>print</command> statements allow you to view a history of commands executed once the program is run. 
	</para>	
	
	<para>
		SystemTap scripts go one step further by allowing you more flexibility with regard to handlers. Events serve as the triggers for handlers to run; handlers can be specified to trap specified data and print it in a certain manner. 
	</para>
	
<formalpara id="scriptformats">
	<title>Format</title>
	<para>
		SystemTap scripts use the file extension <filename>.stp</filename>, and are written in the following format:
	</para>
</formalpara>	
<programlisting>
probe	<replaceable>[event]</replaceable>,
<replaceable>[another event]</replaceable>

{
	<replaceable>[handler]</replaceable>

	exit()
}
</programlisting>		
	<para>The <replaceable>exit()</replaceable> condition is optional, but it is recommended since it safely terminates the session once the script successfully traps the required information.</para>	
	
<important>
	<title>Important</title>
	<para>
		<xref linkend="scripts"/> is designed to introduce readers to the basics of SystemTap scripts. To understand SystemTap scripts better, it is advisable that you refer to <xref linkend="useful-systemtap-scripts"/>; each section therein provides a detailed explanation of the script, its events, handlers, and expected output.
	</para>
</important>	
	<section id="systemtapscript-events">
		<title>Events</title>
	
<para>
	SystemTap supports multiple events per probe; as shown in <xref linkend="scriptformats"/>, multiple events are delimited by a comma (<command>,</command>). Sample <replaceable>[event]</replaceable>s include:</para>

<variablelist>
	
<varlistentry>
	<term>begin</term>
	<listitem>
		<para>The startup of a SystemTap session; i.e. as soon as the SystemTap script is run.</para>
	</listitem>	
</varlistentry>	

<varlistentry>
	<term>end</term>
	<listitem>
		<para>The end of a SystemTap session.</para>
	</listitem>	
</varlistentry>

<varlistentry>
	<term>kernel.function("<replaceable>[function]</replaceable>")</term>
	<listitem>
		<para>The entry to the kernel function <replaceable>function</replaceable>. For example, <command>kernel.function("sys_open")</command> refers to the "event" that the kernel function <command>sys_open</command> is used. To specify the <emphasis>return</emphasis> of the kernel function <command>sys_open</command>, append the <command>return</command> string to the event statement; i.e. <command>kernel.function("sys_open").return</command>.</para>
		
		<para>When defining functions, you can use asterisk (<command>*</command>) for wildcards. You can also trace the entry/exit of a function in a kernel source file. Consider the following example:</para>
<example id="wildcards"><title>Wildcards and Kernel Source Files in an Event</title>
<programlisting>
probe kernel.function("*@net/socket.c") { }
probe kernel.function("*@net/socket.c").return { }
</programlisting>	
</example>	

<para>In the previous example, the first probe's event specifies the entry of ALL functions in the kernel source file <filename>net/socket.c</filename>. The second probe specifies the exit of all those functions. Note that in this example, no handler was specified; as such, no information will be displayed.</para>
	</listitem>	
</varlistentry>

<varlistentry>
	<term>syscall.<replaceable>[system_call]</replaceable></term>
	<listitem>
		<para>The entry to the system call <replaceable>[system_call]</replaceable>. Similar to <command>kerne.function</command>, appending a <command>return</command> to the statement specifies the exit of the system call. For example, to specify the entry of the system call <command>close</command>, use <command>syscall.close.return</command>.</para>
		
		<para>To identify what system calls are made by a specific program/command, use <command>strace <replaceable>command</replaceable></command>.</para>
	</listitem>	
</varlistentry>
<!--	
<varlistentry>
	<term></term>
	<listitem>
		<para></para>
	</listitem>	
</varlistentry>
-->
	
</variablelist>

<important>
	<title>Important</title>
	<para>
	SystemTap supports the use of a large collection of probe events. For more information about supported events, refer to <command>man stapprobes</command>. The <citetitle>SEE ALSO</citetitle> section of <command>man stapprobes</command> also contains links to other <command>man</command> pages that discuss supported events for specific subsystems and components.
	</para>	
</important>

<remark>is reference appropriate? too advanced for readers (it seems so to me)? please advise.</remark> 
	</section>
	
	<section id="systemtapscript-handlers">
		<title>Handlers</title>

<para>
Consider the following sample script:
</para>

<example id="helloworld"><title>Hello World</title>
<programlisting>
probe begin
{
  printf ("hello world\n")
  exit ()
}
</programlisting>	
</example>

<para>
	In <xref linkend="helloworld"/>, the event <command>begin</command> (i.e. the start of the session) triggers the handler enclosed in <command>{ }</command>, which simply prints <command>hello world</command>, then exits.
</para>	

<formalpara id="printf">
	<title>printf ( ) Statements</title>
<para>
	The <command>printf ()</command> statement is one of the simplest handler tools for printing data. <command>printf ()</command> can also be used to trap data using a wide variety of SystemTap handler functions using the following format:
</para>

</formalpara>
<remark>is "handler tool" appropriate?</remark>


<programlisting>
printf ("<replaceable>[format string]</replaceable>\n", <replaceable>[argument]</replaceable>)
</programlisting>

<para>
	The <replaceable>[format string]</replaceable> region specifies how <replaceable>[argument]</replaceable> should be displayed. The format string of <xref linkend="helloworld"/> simply instructs SystemTap to print <command>hello world</command>, and contains no arguments. 
</para>

<para>
	You can use the variables <command>%s</command> (for strings) and <command>%d</command> (for numbers) in format strings, depending on your list of arguments. Format strings can have multiple variables, each matching a corresponding argument; multiple arguments are delimited by a comma (<command>,</command>) and space.
</para>

<para>
	To illustrate this, consider the following probe example:
</para>

<example id="syscall-open">
	<title>Using Variables In printf ( ) Statements</title>
<programlisting>
# This probe will need to be manually terminated with Ctrl-C
probe syscall.open
{
  printf ("%s(%d) open\n", execname(), pid())
}
	
</programlisting>	
</example>

<para>
<xref linkend="syscall-open"/> instructs SystemTap to probe all entries to the system call <command>open</command>; for each event, it prints the current <command>execname()</command> (which is a string) and <command>pid()</command> (which is a number), followed by the word <command>open</command>. A snippet of this probe's output would look like:
</para>

<remark>editorial review: does a clarification that "variable1" is to "argument1", "variable2" is to "argument2", or is this clear enough?</remark>

<screen>
vmware-guestd(2206) open
hald(2360) open
hald(2360) open
hald(2360) open
df(3433) open
df(3433) open
df(3433) open
hald(2360) open
</screen>

<formalpara>
	<title>Handler Functions</title>	
	<para>SystemTap supports a wide variety of handler functions that can be used as <command>printf ()</command> arguments. <xref linkend="syscall-open"/> uses the handler functions <command>execname()</command> (current process name) and <command>pid()</command> (current process ID).</para>
</formalpara>		

<remark>is "handler function" an appropriate term?</remark>

	<para>The following is a list of commonly-used handler functions:</para>	
<variablelist>

<varlistentry>
	<term>tid()</term>
	<listitem>
		<para>The ID of the current thread.</para>
	</listitem>	
</varlistentry>	

<varlistentry>
	<term>uid()</term>
	<listitem>
		<para>The ID of the current user.</para>
	</listitem>	
</varlistentry>

<varlistentry>
	<term>cpu()</term>
	<listitem>
		<para>The current CPU number.</para>
	</listitem>	
</varlistentry>

<varlistentry>
	<term>gettimeofday_s()</term>
	<listitem>
		<para>The number of seconds since UNIX epoch (January 1, 1970).</para>
	</listitem>	
</varlistentry>

<varlistentry>
	<term>get_cycles()</term>
	<listitem>
		<para>A snapshot of the hardware cycle counter.</para>
	</listitem>	
</varlistentry>

<varlistentry>
	<term>pp()</term>
	<listitem>
		<para>A string describing the probe point currently being handled.</para>
	</listitem>	
</varlistentry>

<varlistentry>
	<term>probefunc()</term>
	<listitem>
		<para>If known, the name of the function in which the probe was placed.</para>
	</listitem>	
</varlistentry>
<!--	
<varlistentry>
	<term></term>
	<listitem>
		<para></para>
	</listitem>	
</varlistentry>
-->	
</variablelist>		

<para>For more information about supported handler functions, refer to <command>man stapfuncs</command>.</para>

<remark>will need a complete listing of supported handler functions? also, handler function descriptions seem ambiguous, please advise.</remark>

<!--	
<para>
	<replaceable>[variable]</replaceable> can be either <command>%s</command> for strings, or <command>%d</command> for numbers, depending on the <replaceable>[handler function]</replaceable> used. Each <command>printf ()</command> statement can contain multiple <replaceable>[variable]</replaceable>s, with each one corresponding to a matching <replaceable>[handler function]</replaceable>. Multiple <replaceable>[handler function]</replaceable>s are delimited by comma (<command>,</command>). 
</para>	

	<command>printf ()</command> is a SystemTap-supported C statement, and can also trap data using a wide variety
	
	SystemTap supports a wide variety of handler functions that can trap data when triggered by events. One way to display these functions is to use the <command>print()</command>   
</para>	
		
		
<para>
	<xref linkend="wildcards"/> illustrates an example of a SystemTap script that contains no handlers. SystemTap will still be able to run the script, but no information will be displayed. 	
</para>
-->


	</section>
	
	<!--	<section id="SystemTap_Beginners_Guide-Test-Section_2_Test">
		<title>Section 2 Test</title>
		<para>
			Test of a section
		</para>
	</section>-->

</section>