Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

error::sdt(7stap) [centos man page]

ERROR::SDT(7stap)														 ERROR::SDT(7stap)

error::sdt - <sys/sdt.h> marker failures DESCRIPTION
Systemtap's <sys/sdt.h> probes are modeled after the dtrace USDT API, but are implemented differently. They leave a only a NOP instruction in the userspace program's text segment, and add an ELF note to the binary with metadata. This metadata describes the marker's name and parameters. This encoding is designed to be parseable by multiple tools (not just systemtap: GDB, the GNU Debugger, also contains sup- port). These allow the tools to find parameters and their types, wherever they happen to reside, even without DWARF debuginfo. The reason finding parameters is tricky is because the STAP_PROBE / DTRACE_PROBE markers store an assembly language expression for each op- erand, as a result of use of gcc inline-assembly directives. The compiler is given a broad gcc operand constraint string ("nor") for the operands, which usually works well. Usually, it does not force the compiler to load the parameters into or out of registers, which would slow down an instrumented program. However, some instrumentation sites with some parameters do not work well with the default "nor" con- straint. unresolveable at run-time GCC may emit strings that an assembler could resolve (from the context of compiling the original program), but a run-time tool can- not. For example, the operand string might refer to a label of a local symbol that is not emitted into the ELF object file at all, which leaves no trace for the run-time. Reference to such parameters from within systemtap can result in "SDT asm not understood" errors. too complicated expression GCC might synthesize very complicated assembly addressing modes from complex C data types / pointer expressions. systemtap or gdb may not be able to parse some valid but complicated expressions. Reference to such parameters from within systemtap can result in "SDT asm not understood" errors. overly restrictive constraint GCC might not be able to even compile the original program with the default "nor" constraint due to shortage of registers or other reasons. A compile-time gcc error such as "asm operand has impossible constraints" may result. There are two general workarounds to this family of problems. change the constraints While compiling the original instrumented program, set the STAP_SDT_ARG_CONSTRAINT macro to different constraint strings. See the GCC manual about various options. For example, on many machine architectures, "r" forces operands into registers, and "g" leaves operands essentially unconstrained. revert to debuginfo As long as the instrumented program compiles, it may be fine simply to keep using <sys/sdt.h> but eschew extraction of a few indi- vidual parameters. In the worst case, disable <sys/sdt.h> macros entirely to eschew the compiled-in instrumentation. If DWARF debuginfo was generated and preserved, a systemtap script could refer to the underlying source context variables instead of the positional STAP_PROBE parameters. SEE ALSO
stap(1), stapprobes(3stap), error::dwarf(7stap),,, error::reporting(7stap) ERROR::SDT(7stap)

Check Out this Related Man Page


warning::debuginfo - systemtap missing-debuginfo warnings DESCRIPTION
For many symbolic probing operations, systemtap needs DWARF debuginfo for the relevant binaries. This often includes resolving func- tion/statement probes, or $context variables in related handlers. DWARF debuginfo may be found in the original binaries built during com- pilation, or may have been split into separate files. The SYSTEMTAP_DEBUGINFO_PATH environment variable affects where systemtap looks for these files. If your operating system came from a distributor, check with them if debuginfo packages or variants are available. If your distributor does not have debuginfo-equipped binaries at all, you may need to rebuild it. Systemtap uses the elfutils library to process ELF/DWARF files. The version of elfutils used by systemtap is the number after the slash in the -V output: % stap -V Systemtap translator/driver (version 2.3/0.156, rpm 2.3-1.fc19) Copyright (C) 2005-2013 Red Hat, Inc. and others [...] This indicates systemtap version 2.3 with elfutils version 0.156. kernel debuginfo For scripts that target the kernel, systemtap may search for the vmlinux file created during its original build. This is distinct from the boot-loader's compressed/stripped vmlinuz file, and much larger. If you have a hand-built kernel, make sure it was built with the CONFIG_DEBUG_INFO=y option. process debuginfo For scripts that target user-space, systemtap may search for debuginfo. If you have hand-built binaries, use CFLAGS=-g -O2 to com- pile them. minidebuginfo On some systems, binaries may be compiled with a subset of debuginfo useful for function tracing and backtraces. This 'Minidebugin- fo' is a xz compressed section labeled .gnu_debugdata. Support for minidebuginfo relies on elfutils version 0.156 or later. compressed debuginfo On some systems, debuginfo may be available, but compressed into .zdebug_* sections. Support for compressed debuginfo relies on el- futils version 0.153 or later. unnecessary debuginfo In some cases, a script may be altered to avoid requiring debuginfo. For example, as script that uses probe syscall.* probes could try instead probe nd_syscall.* (for non-DWARF syscall): these work similarly, and use more intricate (fragile) tapset functions to extract system call arguments. Another option is use of compiled-in instrumentation such as kernel tracepoints or user-space <sys/sdt.h> markers in libraries or executables, which do not require debuginfo. If debuginfo was required for resolving a compli- cated $var->foo->bar expression, it may be possible to use @cast(var,"foo","foo.h")->foo->bar to synthesize debuginfo for that type from a header file. AUTOMATION
On some platforms, systemtap may advise what commands to run, in order to download needed debuginfo. Another possibility is to invoke sys- temtap with the --download-debuginfo flag. The stap-prep script included with systemtap may be able to download the appropriate kernel de- buginfo. Another possibility is to install and use a stap-server remote-compilation instance on a machine on your network, where debuginfo and compilation resources can be centralized. Try the stap --use-server option, in case such a server is already running. SEE ALSO
stap(1), stappaths(7), stap-server(8), strip(1), error::dwarf(7stap), error::reporting(7stap), error::contextvars(7stap),, WARNING::DEBUGINFO(7stap)
Man Page

Featured Tech Videos