systemtap userspace function tracing

Question

I have a simple c++ program

main.cpp

#include <iostream>
using namespace std;

int addition (int a, int b)
{
  int r;
  r=a+b;
  return r;
}

int main ()
{
  int z;
  z = addition (5,3);
  cout << "The result is " << z;
}

I want to generate the function tracing for this - print function names and its input output and return types

My systemtap script : para-callgraph.stp

#! /usr/bin/env stap

function trace(entry_p, extra) {
  %( $# > 1 %? if (tid() in trace) %)
  printf("%s%s%s %s\n",
         thread_indent (entry_p),
         (entry_p>0?"->":"<-"),
         probefunc (),
         extra)
}


probe $1.call   { trace(1, $$parms)  }
probe $1.return { trace(-1, $$return) }

My C++ Exec is called : a ( compiled as g++ -g main.cpp)

Command I run 
stap para-callgraph.stp 'process("a").function("*")' -c "./a > /dev/null"

 0 a(15119):->_GLOBAL__I__Z8additionii 
    27 a(15119): ->__static_initialization_and_destruction_0 __initialize_p=0x0 __priority=0x0
   168 a(15119): <-__static_initialization_and_destruction_0 
   174 a(15119):<-_GLOBAL__I__Z8additionii 
     0 a(15119):->main 
    18 a(15119): ->addition a=0x0 b=0x400895
    30 a(15119): <-addition return=0x8
   106 a(15119):<-main return=0x0

Here ->addition a=0x0 b=0x400895 : its address and not actual values ie 5, 3 which I want.

How to modify my stap script?

What versions of G++/SystemTap are you using? Your code works fine for me. Note that SystemTap relies on DWARF information supplied by GCC to show variables, and GCC >5.0 versions had switched DWARF to version 4. — myaut, Nov 15 '15 at 15:17
Can you give me the link to DWARF for Centos 7 (3.10.0-229.14.1.el7.x86_64) Systemtap translator/driver (version 2.6/0.160, rpm 2.6-10.el7_1) gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-9) — Step, Nov 16 '15 at 14:41

score 2 · Accepted Answer · answered Nov 16 '15 at 23:30

This appears to be a systemtap bug. It should print the value of b, not its address. Please report it to the systemtap@sourceware.org mailing list (with compiler/etc. versions and other info, as outlined in man error::reporting.

As to changing the script, the $$parms part is where the local variables are being transformed into a pretty-printed string. It could be changed to something like...

trace(1, $$parms . (@defined($foobar) ? (" foobar=".$foobar$) : ""))

to append foobar=XYZ to the trace record, whereever a parameter foobar is available. To work around the systemtap bug in question, you could try

trace(1, $$parms . (@defined($b) ? (" *b=".user_int($b)) : ""))

to dereference the b variable as if it were an int *.

systemtap userspace function tracing

1 Answers1