This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: rethinking syscall tapset
- From: "Daniel P. Berrange" <berrange at redhat dot com>
- To: Martin Hunt <hunt at redhat dot com>
- Cc: Hien Nguyen <hien at us dot ibm dot com>, "systemtap at sources dot redhat dot com" <systemtap at sources dot redhat dot com>
- Date: Tue, 31 Jan 2006 18:43:57 +0000
- Subject: Re: rethinking syscall tapset
- References: <1138689272.3948.17.camel@monkey2>
- Reply-to: "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 -=|