structure access and tapsets

Hien Nguyen hien@us.ibm.com
Tue Feb 14 18:59:00 GMT 2006


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



More information about the Systemtap mailing list