dtrace(1) [centos man page]

DTRACE(1)						      General Commands Manual							 DTRACE(1)

NAME

       dtrace - Dtrace compatibile user application static probe generation tool.

SYNOPSIS

       dtrace -s file [OPTIONS]

DESCRIPTION

       The dtrace command converts probe descriptions defined in file.d into a probe header file via the -h option or a probe description file via
       the -G option.

OPTIONS

       -h     generate a systemtap header file.

       -G     generate a systemtap probe definition object file.

       -o file
	      is the name of the output file.  If the -G option is given then the output file will be called file.o; if the  -h  option  is  given
	      then the output file will be called file.h.

       -C     run the cpp preprocessor on the input file when the -h option is given.

       -I file
	      give this include path to cpp when the -C option is given.

       -k     keep temporary files, for example the C language source for the -G option.

       --types
	      generate probe argument typedef information when the -h option is given.

EXAMPLES

       Systemtap is source compatible with dtrace user application static probe support.  Given a file test.d containing:

	      provider sdt_probes
	      {
		probe test_0 (int type);
		probe test_1 (struct astruct node);
	      };
	      struct astruct {int a; int b;};

       Then  the  command  "dtrace -s test.d -G" will create the probe definition file test.o and the command "dtrace -stest.d -h" will create the
       probe header file test.h Subsequently the application can use the generated macros this way:

	      #include "test.h"
	       ...
	      struct astruct s;
	       ...
	      SDT_PROBES_TEST_0(value);
	       ...
	      if (SDT_PROBES_TEST_1_ENABLED())
		  SDT_PROBES_TEST_1(expensive_function(s));

SEMAPHORES

       Semaphores are flag variables used by probes as a way of bypassing potentially costly processing to prepare arguments for probes  that  may
       not  even be active.  They are automatically set/cleared by systemtap when a relevant script is running, so the argument setup cost is only
       paid when necessary.  These semaphore variables are defined within the the "test.o" object file, which must therefore be linked into an ap-
       plication.

       Sometimes,  semaphore variables are not necessary nor helpful.  Skipping them can simplfy the build process, by omitting the extra "test.o"
       file.  To skip dependence upon semaphore variables, include "<sys/sdt.h>" within the application before "test.h":

	      #include <sys/sdt.h>
	      #include "test.h"
	       ...
	      struct astruct s;
	       ...
	      SDT_PROBES_TEST_0(value);
	       ...
	      if (SDT_PROBES_TEST_1_ENABLED())
		 SDT_PROBES_TEST_1(cheap_function(s));

       In this mode, the ENABLED() test is fixed at 1.

SEE ALSO

       stap(1),
       stappaths(7)

																	 DTRACE(1)

Check Out this Related Man Page

ERROR::PASS2(7stap)													       ERROR::PASS2(7stap)

NAME

       error::pass2 - systemtap pass-2 errors

DESCRIPTION

       Errors that occur during pass 2 (elaboration) can have a variety of causes.  Common types include:

       unavailable probe point classes
	      Some  types  of  probe  points are only available on certain system versions, architectures, and configurations.	For example, user-
	      space process.*  probes may require utrace or uprobes capability in the kernel for this architecture.

       unavailable probe points
	      Some probe points may be individually unavailable even when their class is fine.	For example, kprobe.function("foobar") may fail if
	      function	foobar	does  not  exist  in  the  kernel any more.  Debugging or symbol data may be absent for some types of .function or
	      .statement probes; check for availability of debuginfo.  Try the stap-prep program to download possibly-required debuginfo.   Use  a
	      wildcard	parameter  such as stap -l 'kprobe.function("*foo*")' to locate still-existing variants.  Use ! or ?  probe point suffixes
	      to denote optional / preferred-alternatives, to let the working parts of a script continue.

       typos  There might be a spelling error in the probe point name ("sycsall" vs.  "syscall").  Wildcard probes may not find a match at all	in
	      the  tapsets.   Recheck the names using stap -l PROBEPOINT.  Another common mistake is to use the .  operator instead of the correct
	      -> when dereferencing context variable subfields or pointers: $foo->bar->baz even if in C one would say foo->bar.baz.

       unavailable context variables
	      Systemtap scripts often wish to refer to variables from the context of the probed programs using $variable  notation.   These  vari-
	      ables may not always be available, depending on versions of the compiler, debugging/optimization flags used, architecture, etc.  Use
	      stap -L PROBEPOINT to list available context variables for given probes.	Use the @defined() expression to test for the  resolvabil-
	      ity  of  a context variable expression.  Consider using the stap --skip-badvars option to silently replace misbehaving context vari-
	      able expressions with zero.

GATHERING MORE INFORMATION

       Increasing the verbosity of pass-2 with an option such as --vp 02 can help pinpoint the problem.

SEE ALSO

       stap(1),
       stap-prep(1),
       stapprobes(3stap),
       probe::*(3stap),
       error::dwarf(7stap),
       error::inode-uprobes(7stap),
       warning::debuginfo(7stap),
       error::reporting(7stap)

															       ERROR::PASS2(7stap)

Linux and UNIX Man Pages

dtrace(1) [centos man page]

Check Out this Related Man Page