This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: structure access and tapsets


Martin,

For the time being, I agree with you we are going to have a bunch of structure printing functions (for the system calls tapset). I am going to do the same for the structures I see in the syscalls2.stp.
But for some stucture such as 'struct stat' or 'struct rusage' (has lot of members) do we want to have a string that represents all members?
What about if people want the struct membersindividually? I think we still need to export the structure data individually. It would be nice that we could export just the structure (if we have struct data type in the language) and user could access to all members of the struct.


Hien.
Martin Hunt wrote:

OK, let's not do anything with structure access, if it's just going to
become automatic in the future.  I'm going to rip all those out of
auxsyscalls.stp.

Then I'm going to create some structure printing functions for the
tapset to print nicely formatted time, socket, other structs. These will
still be useful. I'll put them in auxsyscalls temporarily.

Martin


On Mon, 2006-02-13 at 13:55 -0800, Hien Nguyen wrote:


As I recalled, Vara pointed out before that we need to have support for struct data type in the language.
Accessing struct data in function arguments should be as easy as


$target->fieldname

Looks like #3 try to do the samething.

Hien
Martin Hunt wrote:



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.

















Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]