trusty (7) error::dwarf.7stap.gz

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 generate 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, error::reporting(7stap)

                                                                                             ERROR::DWARF(7stap)