Re: rethinking syscall tapset

["Daniel P. Berrange" <berrange at redhat dot com>]

On Mon, Jan 30, 2006 at 10:34:32PM -0800, Martin Hunt wrote:
> I've been thinking that the old version didn't do much useful. A bunch
> of lines like "count = $count" doesn't really add anything. There are
> some good utility functions in aux_syscalls.stp.  But why do we need a
> syscall tapset?  Basically it is supposed to make it easier to trace and
> profile system calls. So I'm trying things like:

As an app developer I'd want a syscall tapset to enable a consistent naming
policy to be given to calls & their arguments, regardless of kernel version 
or architecture, since while most syscalls are prefixed with 'sys_' in the 
kernel source, a handful are not, which always catches me out.

I think I'd also probably like it to automaticlly merge the 'fstat' / 'fstat64'
variants into a single 'syscall.fstat' probe - both to hide the differences
between i686 and x86_64, and to be consistent with the naming exposed by
libc to the app developer.

> probe syscall.open, syscall.read,
>       syscall.open.return, syscall.read.return {
> 
>       if (pid() == target()) {
>               if (returnp)
>                       printf("%s returned %d\n", name, returnval())
>               else
>                       log(tracestr)
>       }
> }

It would seem more readable to structure the probe separately
rather than using a conditional on returnp.

 probe syscall.open, syscall.read {
       if (pid() == target()) {
           log(tracestr)
       }
 }

 probe syscall.open.return, syscall.read.return {
       if (pid() == target()) {
               printf("%s returned %d\n", name, returnval())
       }
 }


> Note that I've replaced "kernel.syscall" with just "syscall".
> 
> I've created a string "tracestr" that each syscall returns with the name
> and formatted arguments. I've been debating if I want to include the
> name or just the args. So in my example I would do
> printf("%s: %s\n", name, argstr)
> 
> 
> I've created another variable all return probes set called "returnp".

I'm not clear on the intended use of this, besides enabling both the
call & return to be written in one block, using a conditional ?

> We could get the same thing calling is_return() in context.stp, but that
> is a bit slower.
> 
> What do you think?

Is there anyway to create the syscall tapset such that a user dosn't have
to explicitly attach to both the call & return probes ? As an example I'm
trying to write a systemwide strace()-alike in systemtap, which requires
saving the data from the call probe in a map & then in the return probe 
fishing it out again to print alongisde the return value.

If it helps, a simplified version of my curent probe is:

global logdatatrack
global logtimetrack

probe begin {
  starttime = gettimeofday_ms()
  log("startup");
}

probe end {
  log("shutdown");
}

function logcall(call, data) {
  if (execname() != "stpd") {
    key = string(pid()) . ":" . call
    logtimetrack[key] = gettimeofday_ms()
    logdatatrack[key] = string(logtimetrack[key]- starttime) . " pid " . string(pid()) . " (" . execname() . ") " . call . " " . data
  }
}

function logreturn(call, data) {
  if (execname() != "stpd") {
    key = string(pid()) . ":" . call
    if (logdatatrack[key] != "") {
      duration = gettimeofday_ms() - logtimetrack[key]
      log(logdatatrack[key] . " = " . data . " (+" . string(duration) . ")")
      delete logdatatrack[key]
      delete logtimetrack[key]
    }
  }
}

probe kernel.syscall.stat {
  logcall("stat", user_string(filename_uaddr))
}

probe kernel.syscall.stat.return {
  logreturn("stat", string(retval()))
}

probe kernel.syscall.stat64 {
  logcall("stat", user_string(filename_uaddr))
}

probe kernel.syscall.stat64.return {
  logreturn("stat", string(retval()))
}


Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, London. +44 7977 267 243 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|