This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
structure access and tapsets
- From: Martin Hunt <hunt at redhat dot com>
- To: Hien Nguyen <hien at us dot ibm dot com>, "systemtap at sources dot redhat dot com" <systemtap at sources dot redhat dot com>
- Date: Mon, 13 Feb 2006 12:06:37 -0800
- Subject: structure access and tapsets
- Organization: Red Hat Inc
Accessing Structures
The current aux_syscalls.stp has some functions to access structures
from userspace. For example
function __uget_ts_m:long(u_addr:long,member:long)
%{
struct timespec ts;
char *ptr = (char *)(unsigned long)THIS->u_addr;
size_t sz = sizeof(struct timespec);
if(_stp_copy_from_user((char *)&ts,ptr,sz))
THIS->__retvalue = -EFAULT;
else if(THIS->member == 0)
THIS->__retvalue = ts.tv_sec;
else
THIS->__retvalue = ts.tv_nsec;
%}
This copies a timespec from userspace and returns either the seconds or
nanoseconds field. It isn't very convenient for the syscall tapset. It
is also badly named. __uget_ts_m() means nothing to me.
So I wrote the following, which is very useful for building argstr in
the syscall tapset:
function _utimespec_str(uaddr:long)
%{
struct timespec ts;
char *ptr = (char *)(unsigned long)THIS->uaddr;
if (ptr == NULL)
strlcpy (THIS->__retvalue, "NULL", MAXSTRINGLEN);
else {
if(_stp_copy_from_user((char *)&ts,ptr,sizeof(struct timespec))) {
strlcpy (THIS->__retvalue, "UNKNOWN", MAXSTRINGLEN);
} else
snprintf(THIS->__retvalue, MAXSTRINGLEN, "[%ld.%09ld]",
(unsigned long)ts.tv_sec, (unsigned long)ts.tv_nsec);
}
%}
So the questions I am considering are:
1. Is there any reason to make arguments passed in a structure available
to tapset callers? For example, in sys_futex(), if a timespec is passed
in, should the tapset set a variable "secs" and "nsecs" with the seconds
and nanoseconds pulled out of the struct?
2. If we provide a bunch of functions to decode common system
structures, how should they be named? This is important; I already have
60 functions in aux_syscalls and they mostly decode flags and return
strings. Add in a bunch that do optional userspace copies then decode
structs and return either longs or strings.
Maybe
_struct_timespec(addr, num) - returns element num
_struct_timespec_str(addr) - returns formatted string
_struct_utimespec_str(uaddr) - same as above but takes userspace
address.
3. How does http://sources.redhat.com/bugzilla/show_bug.cgi?id=2049
affect this? From the brief description, I can't be sure, but it looks
like eliminate all the need for creating ways to access fields.
Functions to print a struct as a neatly-formatted string (as in
_utimespec_str above) seem like they would be still useful.