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::DWARF(7stap)ERROR::DWARF(7stap)NAME
error::dwarf - dwarf debuginfo quality problems
DESCRIPTION
Systemtap sometimes relies on ELF/DWARF debuginfo for programs being instrumented to locate places to probe, or context variables to
read/write, just like a symbolic debugger does. Even though examination of the program's source code may show variables or lines where
probes may be desired, the compiler must preserve information about them for systemtap (or a debugger such as gdb) to get pinpoint access
to the desired information. If a script requires such data, but the compiler did not preserve enough of it, pass-2 errors may result.
Common conditions that trigger these problems include;
compiler version
Prior to GCC version 4.5, debuginfo quality was fairly limited. Often developers were advised to build their programs with -O0 -g
flags to disable optimization. GCC version 4.5 introduced a facility called "variable-tracking assignments" that allows it to gen-
erate high-quality debuginfo under full -O2 -g optimization. It is not perfect, but much better than before. Note that, due to
another gcc bug (PR51358) -O0 -g can actually sometimes make debuginfo quality worse than for -O2 -g.
function inlining
Even modern gcc sometimes has problems with parameters for inlined functions. It may be necessary to change the script to probe at
a slightly different place (try a .statement() probe, instead of a .function() probe, somewhere a few source lines into the body of
the inlined function. Or try putting a probe at the call site of the inlined function. Or use the if @defined($var) { ... } script
language construct to test for the resolvability of the context variable before using it.
instruction reordering
Heavily optimized code often smears the instructions from multiple source statements together. This can leave systemtap with no
place to choose to place a probe, especially a statement probe specified by line number. Systemtap may advise to try a nearby line
number, but these may not work well either. Consider placing a probe by a statement wildcard or line number range.
ALTERNATIVES
In order to reduce reliance on ELF/DWARF debuginfo, consider the use of statically compiled-in instrumentation, such as kernel tracepoints,
or <sys/sdt.h> userspace markers. Such instrumentation hook sites are relatively low cost (just one NOP instruction for sdt.h), and nearly
guarantee the availability of parameter data and a reliable probe site, all without reliance on debuginfo.
SEE ALSO stap(1),
http://dwarfstd.org/,
http://sourceware.org/systemtap/wiki/TipContextVariables,
http://gcc.gnu.org/wiki/Var_Tracking_Assignments,
warning::debuginfo(7stap),
error::reporting(7stap)ERROR::DWARF(7stap)