2 .TH STAP 1 @DATE@ "Red Hat"
4 stap \- systemtap script translator/driver
53 program is the front-end to the Systemtap tool. It accepts probing
54 instructions (written in a simple scripting language), translates
55 those instructions into C code, compiles this C code, and loads the
56 resulting kernel module into a running Linux kernel to perform the
57 requested system trace/probe functions. You can supply the script in
58 a named file, from standard input, or from the command line. The
59 program runs until it is interrupted by the user, or if the script
60 voluntarily invokes the
62 function, or by sufficient number of soft errors.
64 The language, which is described in a later section, is strictly typed,
65 declaration free, procedural, and inspired by
67 It allows source code points or events in the kernel to be associated
68 with handlers, which are subroutines that are executed synchronously. It is
69 somewhat similar conceptually to "breakpoint command lists" in the
73 This manual corresponds to version @VERSION@.
76 The systemtap translator supports the following options. Any other option
77 prints a list of supported options.
78 .\" undocumented for now:
82 Increase verbosity. Produce a larger volume of informative (?) output
83 each time option repeated.
92 Keep the temporary directory after all processing. This may be useful
93 in order to examine the generated C code, or to reuse the compiled
97 Guru mode. Enable parsing of unsafe expert-level constructs like
101 Prologue-searching mode. Activate heuristics to work around incorrect
102 debbugging information for $target variables.
105 Unoptimized mode. Disable unused code elision during elaboration.
108 Suppressed warnings mode. Disable warning messages for elided code in user script.
111 Use bulk mode (percpu files) for kernel-to-user data transfer.
114 Collect timing information on the number of times probe executes
115 and average amount of time spent in each probe.
118 Use NUM megabyte buffers for kernel-to-user data transfer. On a
119 multiprocessor in bulk mode, this is a per-processor amount.
122 Stop after pass NUM. The passes are numbered 1-5: parse, elaborate,
123 translate, compile, run. See the
128 Add the given directory to the tapset search directory. See the
129 description of pass 2 for details.
131 .BI \-D " NAME=VALUE"
132 Add the given C preprocessor directive to the module Makefile. These can
133 be used to override limit parameters described below.
136 Look for the systemtap runtime sources in the given directory.
139 Build for given kernel release instead of currently running one.
142 Use the given name for the generated kernel object module, instead
143 of a unique randomized name. The generated kernel object module is
144 copied to the current directory.
147 Send standard output to named file. In bulk mode, percpu files will
148 start with FILE_ followed by the cpu number.
151 Start the probes, run CMD, and exit when CMD finishes.
154 Sets target() to PID. This allows scripts to be written that filter on
159 Any additional arguments on the command line are passed to the script
160 parser for substitution. See below.
164 The systemtap script language resembles
166 There are two main outermost constructs: probes and functions. Within
167 these, statements and expressions use C-like operator syntax and
171 Whitespace is ignored. Three forms of comments are supported:
174 .BR # " ... shell style, to the end of line, except for $# and @#"
176 .BR // " ... C++ style, to the end of line"
178 .BR /* " ... C style ... " */
180 Literals are either strings enclosed in double-quotes (passing through
181 the usual C escape codes with backslashes), or integers (in decimal,
182 hexadecimal, or octal, using the same notation as in C). All strings
183 are limited in length to some reasonable value (a few hundred bytes).
184 Integers are 64-bit signed quantities, although the parser also accepts
185 (and wraps around) values above positive 2**63.
187 In addition, script arguments given at the end of the command line may
190 for insertion unquoted,
192 for insertion as a string literal. The number of arguments may be accessed
195 (as an unquoted number) or through
197 (as a quoted number). These may be used at any place a token may begin,
198 including within the preprocessing stage. Reference to an argument
199 number beyond what was actually given is an error.
202 A simple conditional preprocessing stage is run as a part of parsing.
203 The general form is similar to the
204 .RB cond " ? " exp1 " : " exp2
207 .BR %( " CONDITION " %? " TRUE-TOKENS " %)
208 .BR %( " CONDITION " %? " TRUE-TOKENS " %: " FALSE-TOKENS " %)
210 The CONDITION is either an expression whose format is determined by its
211 first keyword, or a string literals comparison or a numeric literals
214 If the first part is the identifier
215 .BR kernel_vr " or " kernel_v
216 to refer to the kernel version number, with ("2.6.13\-1.322FC3smp") or
217 without ("2.6.13") the release code suffix, then
218 the second part is one of the six standard numeric comparison operators
219 .BR < ", " <= ", " == ", " != ", " > ", and " >= ,
220 and the third part is a string literal that contains an RPM-style
221 version-release value. The condition is deemed satisfied if the
222 version of the target kernel (as optionally overridden by the
224 option) compares to the given version string. The comparison is
225 performed by the glibc function
227 As a special case, if the operator is for simple equality
231 and the third part contains any wildcard characters
232 .RB ( * " or " ? " or " [ "),"
233 then the expression is treated as a wildcard (mis)match as evaluated
237 If, on the other hand, the first part is the identifier
239 to refer to the processor architecture, then the second part
240 then the second part is one of the two string comparison operators
242 and the third part is a string literal for matching it. This
243 comparison is a wildcard (mis)match.
245 Otherwise, the CONDITION is expected to be a comparison between two string
246 literals or two numeric literals. In this case, the arguments are the only
249 The TRUE-TOKENS and FALSE-TOKENS are zero or more general parser
250 tokens (possibly including nested preprocessor conditionals), and are
251 pasted into the input stream if the condition is true or false. For
252 example, the following code induces a parse error unless the target
253 kernel version is newer than 2.6.5:
255 %( kernel_v <= "2.6.5" %? **ERROR** %) # invalid token sequence
257 The following code might adapt to hypothetical kernel version drift:
259 probe kernel.function (
260 %( kernel_v <= "2.6.12" %? "__mm_do_fault" %:
261 %( kernel_vr == "2.6.13\-1.8273FC3smp" %? "do_page_fault" %:
266 probe syscall.vliw = kernel.function("vliw_widget") {}
271 Identifiers for variables and functions are an alphanumeric sequence,
272 and may include "_" and "$" characters. They may not start with a
273 plain digit, as in C. Each variable is by default local to the probe
274 or function statement block within which it is mentioned, and therefore
275 its scope and lifetime is limited to a particular probe or function
277 .\" XXX add statistics type here once it's supported
279 Scalar variables are implicitly typed as either string or integer.
280 Associative arrays also have a string or integer value, and a
281 a tuple of strings and/or integers serving as a key. Here are a
282 few basic expressions.
286 array1 [pid()] = "name" # single numeric key
287 array2 ["foo",4,i++] += 5 # vector of string/num/num keys
288 if (["hello",5,4] in array2) println ("yes") # membership test
291 The translator performs
293 on all identifiers, including array indexes and function parameters.
294 Inconsistent type-related use of identifiers signals an error.
296 Variables may be declared global, so that they are shared amongst all
297 probes and live as long as the entire systemtap session. There is one
298 namespace for all global variables, regardless of which script file
299 they are found within. A global declaration may be written at the
300 outermost level anywhere, not within a block of code. The following
301 declaration marks a few variables as global. The translator will
302 infer for each its value type, and if it is used as an array, its key
303 types. Optionally, scalar globals may be initialized with a string
306 .BR global " var1" , " var2" , " var3=4"
309 Arrays are limited in size by the MAXMAPENTRIES variable -- see the
310 .B SAFETY AND SECURITY
311 section for details. Optionally, global arrays may be declared with a
312 maximum size in brackets, overriding MAXMAPENTRIES for that array only.
313 Note that this doesn't indicate the type of keys for the array, just the
316 .BR global " tiny_array[10]" , " normal_array" , " big_array[50000]"
318 .\" XXX add statistics type here once it's supported
321 Statements enable procedural control flow. They may occur within
322 functions and probe handlers. The total number of statements executed
323 in response to any single probe event is limited to some number
324 defined by a macro in the translated C code, and is in the
325 neighbourhood of 1000.
328 Execute the string- or integer-valued expression and throw away
331 .BR { " STMT1 STMT2 ... " }
332 Execute each statement in sequence in this block. Note that
333 separators or terminators are generally not necessary between statements.
336 Null statement, do nothing. It is useful as an optional separator between
337 statements to improve syntax-error detection and to handle certain
340 .BR if " (EXP) STMT1 [ " else " STMT2 ]"
341 Compare integer-valued EXP to zero. Execute the first (non-zero)
342 or second STMT (zero).
344 .BR while " (EXP) STMT"
345 While integer-valued EXP evaluates to non-zero, execute STMT.
347 .BR for " (EXP1; EXP2; EXP3) STMT"
348 Execute EXP1 as initialization. While EXP2 is non-zero, execute
349 STMT, then the iteration expression EXP3.
351 .BR foreach " (VAR " in " ARRAY [ "limit " EXP ]) STMT"
352 Loop over each element of the named global array, assigning current
353 key to VAR. The array may not be modified within the statement.
356 operator after the VAR or the ARRAY identifier, the iteration will
357 proceed in a sorted order, by ascending or descending index or value.
360 keyword limits the number of loop iterations to EXP times. EXP is
361 evaluted once at the beginning of the loop.
363 .BR foreach " ([VAR1, VAR2, ...] " in " ARRAY [ "limit " EXP ]) STMT"
364 Same as above, used when the array is indexed with a tuple of keys.
365 A sorting suffix may be used on at most one VAR or ARRAY identifier.
367 .BR break ", " continue
368 Exit or iterate the innermost nesting loop
369 .RB ( while " or " for " or " foreach )
373 Return EXP value from enclosing function. If the function's value is
374 not taken anywhere, then a return statement is not needed, and the
375 function will have a special "unknown" type with no return value.
378 Return now from enclosing probe handler.
380 .BR delete " ARRAY[INDEX1, INDEX2, ...]"
381 Remove from ARRAY the element specified by the index tuple. The value will no
382 longer be available, and subsequent iterations will not report the element.
383 It is not an error to delete an element that does not exist.
386 Remove all elements from ARRAY.
389 Removes the value of SCALAR. Integers and strings are cleared to 0 and ""
390 respectively, while statistics are reset to the initial empty state.
393 Systemtap supports a number of operators that have the same general syntax,
394 semantics, and precedence as in C and awk. Arithmetic is performed as per
395 typical C rules for signed integers. Division by zero or overflow is
396 detected and results in an error.
398 binary numeric operators
399 .B * / % + \- >> << & ^ | && ||
401 binary string operators
403 (string concatenation)
405 numeric assignment operators
406 .B = *= /= %= += \-= >>= <<= &= ^= |=
408 string assignment operators
411 unary numeric operators
414 binary numeric or string comparison operators
418 .RB cond " ? " exp1 " : " exp2
424 .RB "fn " ( "[ arg1, arg2, ... ]" )
426 array membership check
429 .BR "[" exp1 ", " exp2 ", " ... "] in " array
432 The main construct in the scripting language identifies probes.
433 Probes associate abstract events with a statement block ("probe
434 handler") that is to be executed when any of those events occur. The
435 general syntax is as follows:
437 .BR probe " PROBEPOINT [" , " PROBEPOINT] " { " [STMT ...] " }
440 Events are specified in a special syntax called "probe points". There
441 are several varieties of probe points defined by the translator, and
442 tapset scripts may define further ones using aliases. These are
447 The probe handler is interpreted relative to the context of each
448 event. For events associated with kernel code, this context may
453 at that spot. These "target variables" are presented to the script as
454 variables whose names are prefixed with "$". They may be accessed
455 only if the kernel's compiler preserved them despite optimization.
456 This is the same constraint that a debugger user faces when working
457 with optimized code. Some other events have very little context.
459 New probe points may be defined using "aliases". Probe point aliases
460 look similar to probe definitions, but instead of activating a probe
461 at the given point, it just defines a new probe point name as an alias
462 to an existing one. There are two types of alias, i.e. the prologue
463 style and the epilogue style which are identified by "=" and "+="
466 For prologue style alias, the statement block that follows an alias
467 definition is implicitly added as a prologue to any probe that refers
468 to the alias. While for the epilogue style alias, the statement block
469 that follows an alias definition is implicitly added as an epilogue to
470 any probe that refers to the alias. For example:
473 probe syscall.read = kernel.function("sys_read") {
477 defines a new probe point
483 .IR kernel.function("sys_read") ,
485 with the given statement as a prologue. And
487 probe syscall.read += kernel.function("sys_read") {
491 defines a new probe point with the given statement as an epilogue.
493 Another probe definition
494 may use the alias like this:
497 printf("reading fd=%d\n", fildes)
502 Systemtap scripts may define subroutines to factor out common work.
503 Functions take any number of scalar (integer or string) arguments, and
504 must return a single scalar (integer or string). An example function
505 declaration looks like this:
507 function thisfn (arg1, arg2) {
511 Note the general absence of type declarations, which are instead
512 inferred by the translator. However, if desired, a function
513 definition may include explicit type declarations for its return value
514 and/or its arguments. This is especially helpful for embedded-C
515 functions. In the following example, the type inference engine need
516 only infer type type of arg2 (a string).
518 function thatfn:string (arg1:long, arg2) {
519 return sprint(arg1) . arg2
522 Functions may call others or themselves
523 recursively, up to a fixed nesting limit. This limit is defined by
524 a macro in the translated C code and is in the neighbourhood of 10.
527 There are a set of function names that are specially treated by the
528 translator. They format values for printing to the standard systemtap
529 output stream in a more convenient way. The
531 variants return the formatted string instead of printing it.
533 .BR print ", " sprint
534 Print one or more values of any type, concatenated directly together.
536 .BR println ", " sprintln
538 .IR print " and " sprint ,
539 but also append a newline.
541 .BR printd ", " sprintd
542 Take a string delimiter and two or more values of any type, and print the
543 values with the delimiter interposed. The delimiter must be a literal
546 .BR printdln ", " sprintdln
547 Print values with a delimiter like
548 .IR printd " and " sprintd ,
549 but also append a newline.
551 .BR printf ", " sprintf
552 Take a formatting string and a number of values of corresponding types,
553 and print them all. The format must be a literal string constant.
557 formatting directives similar to those of C, except that they are
558 fully type-checked by the translator.
560 x = sprintf("take %d steps forward, %d steps back\\n", 3, 2)
561 printf("take %d steps forward, %d steps back\\n", 3+1, 2*2)
567 printf("%s phoned %s %.4x times\\n", bob, alice . bob, 3456)
568 printf("%s except after %s\\n",
569 sprintf("%s before %s",
570 sprint(1), sprint(3)),
575 printdln("|", strlen(name), name, id[name])
579 It is often desirable to collect statistics in a way that avoids the
580 penalties of repeatedly exclusive locking the global variables those
581 numbers are being put into. Systemtap provides a solution using a
582 special operator to accumulate values, and several pseudo-functions to
583 extract the statistical aggregates.
585 The aggregation operator is
587 and resembles an assignment, or a C++ output-streaming operation.
588 The left operand specifies a scalar or array-index lvalue, which must
589 be declared global. The right operand is a numeric expression. The
590 meaning is intuitive: add the given number to the pile of numbers to
591 compute statistics of. (The specific list of statistics to gather
592 is given separately, by the extraction functions.)
595 stats[pid()] <<< memsize
598 The extraction functions are also special. For each appearance of a
599 distinct extraction function operating on a given identifier, the
600 translator arranges to compute a set of statistics that satisfy it.
601 The statistics system is thereby "on-demand". Each execution of
602 an extraction function causes the aggregation to be computed for
603 that moment across all processors.
605 Here is the set of extractor functions. The first argument of each is
606 the same style of lvalue used on the left hand side of the accumulate
608 .IR @count(v) ", " @sum(v) ", " @min(v) ", " @max(v) ", " @avg(v)
609 extractor functions compute the number/total/minimum/maximum/average
610 of all accumulated values. The resulting values are all simple
613 Histograms are also available, but are more complicated because they
614 have a vector rather than scalar value.
615 .I @hist_linear(v,start,stop,interval)
616 represents a linear histogram from "start" to "stop" by increments
617 of "interval". The interval must be positive. Similarly,
619 represents a base-2 logarithmic histogram. Printing a histogram
622 family of functions renders a histogram object as a tabular
623 "ASCII art" bar chart.
629 printf ("avg %d = sum %d / count %d\\n",
630 @avg(x), @sum(x), @count(x))
636 When in guru mode, the translator accepts embedded code in the
637 script. Such code is enclosed between
641 markers, and is transcribed verbatim, without analysis, in some
642 sequence, into the generated C code. At the outermost level, this may
645 instructions, and any auxiliary definitions for use by other embedded
648 The other place where embedded code is permitted is as a function body.
649 In this case, the script language body is replaced entirely by a piece
650 of C code enclosed again between
653 This C code may do anything reasonable and safe. There are a number
654 of undocumented but complex safety constraints on atomicity,
655 concurrency, resource consumption, and run time limits, so this
656 is an advanced technique.
658 The memory locations set aside for input and output values
659 are made available to it using a macro
661 Here are some examples:
663 function add_one (val) %{
664 THIS\->__retvalue = THIS\->val + 1;
666 function add_one_str (val) %{
667 strlcpy (THIS\->__retvalue, THIS\->val, MAXSTRINGLEN);
668 strlcat (THIS\->__retvalue, "one", MAXSTRINGLEN);
671 The function argument and return value types have to be inferred by
672 the translator from the call sites in order for this to work. The
673 user should examine C code generated for ordinary script-language
674 functions in order to write compatible embedded-C ones.
677 A set of builtin functions and probe point aliases are provided
678 by the scripts installed under the
680 .IR @prefix@/share/systemtap/tapset
682 directory. These are described in the
683 .IR stapfuncs "(5) and " stapprobes (5)
687 The translator begins pass 1 by parsing the given input script,
688 and all scripts (files named
690 found in a tapset directory. The directories listed
693 are processed in sequence, each processed in "guru mode". For each
694 directory, a number of subdirectories are also searched. These
695 subdirectories are derived from the selected kernel version (the
698 in order to allow more kernel-version-specific scripts to override less
699 specific ones. For example, for a kernel version
701 the following patterns would be searched, in sequence:
702 .IR 2.6.12\-23.FC3/*.stp ,
707 Stopping the translator after pass 1 causes it to print the parse trees.
710 In pass 2, the translator analyzes the input script to resolve symbols
711 and types. References to variables, functions, and probe aliases that
712 are unresolved internally are satisfied by searching through the
713 parsed tapset scripts. If any tapset script is selected because it
714 defines an unresolved symbol, then the entirety of that script is
715 added to the translator's resolution queue. This process iterates
716 until all symbols are resolved and a subset of tapset scripts is
719 Next, all probe point descriptions are validated
720 against the wide variety supported by the translator. Probe points that
721 refer to code locations ("synchronous probe points") require the
722 appropriate kernel debugging information to be installed. In the
723 associated probe handlers, target-side variables (whose names begin
724 with "$") are found and have their run-time locations decoded.
726 Next, all probes and functions are analyzed for optimization
727 opportunities, in order to remove variables, expressions, and
728 functions that have no useful value and no side-effect. Embedded-C
729 functions are assumed to have side-effects unless they include the
732 Since this optimization can hide latent code errors such as type
733 mismatches or invalid $target variables, it sometimes may be useful
734 to disable the optimizations with the
738 Finally, all variable, function, parameter, array, and index types are
739 inferred from context (literals and operators). Stopping the
740 translator after pass 2 causes it to list all the probes, functions,
741 and variables, along with all inferred types. Any inconsistent or
742 unresolved types cause an error.
745 In pass 3, the translator writes C code that represents the actions
746 of all selected script files, and creates a
748 to build that into a kernel object. These files are placed into a
749 temporary directory. Stopping the translator at this point causes
750 it to print the contents of the C file.
753 In pass 4, the translator invokes the Linux kernel build system to
754 create the actual kernel object file. This involves running
756 in the temporary directory, and requires a kernel module build
757 system (headers, config and Makefiles) to be installed in the usual
759 .IR /lib/modules/VERSION/build .
760 Stopping the translator after pass 4 is the last chance before
761 running the kernel object. This may be useful if you want to
765 In pass 5, the translator invokes the systemtap auxiliary program
767 program for the given kernel object. This program arranges to load
768 the module then communicates with it, copying trace data from the
769 kernel into temporary files, until the user sends an interrupt signal.
770 Any run-time error encountered by the probe handlers, such as running
771 out of memory, division by zero, exceeding nesting or runtime limits,
772 results in a soft error indication. Soft errors in excess of
773 MAXERRORS block of all subsequent probes, and terminate the session.
776 unloads the module, and cleans up.
781 manual page for a collection of samples.
784 The systemtap translator caches the pass 3 output (the generated C
785 code) and the pass 4 output (the compiled kernel module) if pass 4
786 completes successfully. This cached output is reused if the same
787 script is translated again assuming the same conditions exist (same kernel
788 version, same systemtap version, etc.). Cached files are stored in
790 .I $SYSTEMTAP_DIR/cache
791 directory, which may be periodically cleaned/erased by the user.
793 .SH SAFETY AND SECURITY
794 Systemtap is an administrative tool. It exposes kernel internal data
795 structures and potentially private user information.
797 either root privileges
799 To actually run the kernel objects it builds, a user must be one of
810 group. Members of the
812 group can only use modules located in
813 the /lib/modules/VERSION/systemtap directory. This directory
814 must be owned by root and not be world writable.
816 The kernel modules generated by
818 program are run by the
820 program. The latter is a part of the Systemtap package, dedicated to
821 module loading and unloading (but only in the white zone), and
822 kernel-to-user data transfer. Since
824 does not perform any additional security checks on the kernel objects
825 it is given, it would be unwise for a system administrator to add
826 untrusted users to the
832 The translator asserts certain safety constraints. It aims to ensure
833 that no handler routine can run for very long, allocate memory,
834 perform unsafe operations, or in unintentionally interfere with the
835 kernel. Use of script global variables is suitably locked to protect
836 against manipulation by concurrent probe handlers. Use of guru mode
837 constructs such as embedded C can violate these constraints, leading
838 to kernel crash or data corruption.
840 The resource use limits are set by macros in the generated C code.
841 These may be overridden with the
843 flag. A selection of these is as follows:
846 Maximum number of recursive function call levels, default 10.
849 Maximum length of strings, default 128.
852 Maximum number of iterations to wait for locks on global variables
853 before declaring possible deadlock and skipping the probe, default 1000.
856 Maximum number of statements to execute during any single probe hit
857 (with interrupts disabled),
860 MAXACTION_INTERRUPTIBLE
861 Maximum number of statements to execute during any single probe hit
862 which is executed with interrupts enabled (such as begin/end probes),
863 default (MAXACTION * 10).
866 Maximum number of rows in any single global array, default 2048.
869 Maximum number of soft errors before an exit is triggered, default 0, which
870 means that the first error will exit the script.
873 Maximum number of skipped reentrant probes before an exit is triggered, default 100.
876 Minimum number of free kernel stack bytes required in order to
877 run a probe handler, default 1024. This number should be large enough
878 for the probe handler's own needs, plus a safety margin.
881 Multipule scripts can write data into a relay buffer concurrently. A host
882 script provides an interface for accessing its relay buffer to guest scripts.
883 Then, the output of the guests are merged into the output of the host.
884 To run a script as a host, execute stap with
885 .BR \-DRELAYHOST[=name]
888 identifies your host script among several hosts.
889 While running the host, execute stap with
890 .BR \-DRELAYGUEST[=name]
891 to add a guest script to the host.
892 Note that you must unload guests before unloading a host. If there are some
893 guests connected to the host, unloading the host will be failed.
896 In case something goes wrong with
897 .IR stap " or " staprun
898 after a probe has already started running, one may safely kill both
899 user processes, and remove the active probe kernel module with
901 Any pending trace messages may be lost.
904 In addition to the methods outlined above, the generated kernel module
905 also uses overload processing to make sure that probes can't run for
906 too long. If more than STP_OVERLOAD_THRESHOLD cycles (default
907 500000000) have been spent in all the probes on a single cpu during
908 the last STP_OVERLOAD_INTERVAL cycles (default 1000000000), the probes
909 have overloaded the system and an exit is triggered.
911 By default, overload processing is turned on for all modules. If you
912 would like to disable overload processing, define STP_NO_OVERLOAD.
915 .\" consider autoconf-substituting these directories
918 Systemtap data directory for cached systemtap files, unless overridden
921 environment variable.
924 Temporary directory for systemtap files, including translated C code
927 @prefix@/share/systemtap/tapset
928 The automatic tapset search directory, unless overridden by
931 environment variable.
933 @prefix@/share/systemtap/runtime
934 The runtime sources, unless overridden by the
936 environment variable.
938 /lib/modules/VERSION/build
939 The location of kernel module building infrastructure.
941 @prefix@/lib/debug/lib/modules/VERSION
942 The location of kernel debugging information when packaged into the
943 .IR kernel\-debuginfo
944 RPM, unless overridden by the
945 .I SYSTEMTAP_DEBUGINFO_PATH
946 environment variable. The default value for this variable is
947 .IR \-:.debug:/usr/lib/debug .
948 This path is interpreted by elfutils as a list of base directories of
949 which various subdirectories will be searched. The \- at the front
950 means to skip CRC matching for separated debug objects and is a small
951 performance win if no possible corruption is suspected.
954 The auxiliary program supervising module loading, interaction, and
965 Use the Bugzilla link off of the project web page or our mailing list.
967 .BR http://sources.redhat.com/systemtap/ , <systemtap@sources.redhat.com> .
git://sourceware.org / systemtap.git / blob