Re: structure access and tapsets

[Martin Hunt <hunt at redhat dot com>]

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.
> >
> >
> >
> >
> >
> >
> >
> >  
> >
>