Re: file io script example

[fche at redhat dot com (Frank Ch. Eigler)]

kevinrs wrote:

> [...]
> function get_string(str_ptr_addr)
> [...]
>            (const char __user*) (uintptr_t) THIS->str_ptr_addr,

A "user_string()" function is already provided for safely copying such
strings.

> function get_fname(fd) [...]

A more conveniently placed breakpoint might use the "struct file *"
variable extracted out of "files->fd[fd]".  Then traversing that
pointer thusly could work, without needing a custom C function:

     kernel_string ($filp->f_dentry->d_name->name)

 [...]
> *The format variable will not be needed when bz#1306 is resolved.
> * probe kernel.statement("*@fs/open.c:958") [...will go away with bz #1295]

To some extent such bugs, and future ones sure to appear, impede
tapset writing.  When working on that, however, please also keep a
version of scripts that use the facilities as they should
theoretically work, not just a hacked-up one that works around the
bugs of the day.


jamesd wrote:

> [quoting lots of stuff]

Please trim embedded copies of messages you are responding to.

> seems like over the last few days all the samples use  %} if i
> understand this construct requires "guru mode" will this always be the
> case?

Will what be the case?  Requiring guru mode for end-user scripts that
use %{ %}?  Probably.  If such helper functions turn out to be widely
needed and standardizable, they could be placed within a tapset .stp
file, thus implicitly gaining guru-mode treatment.

> or will systemtap be able to support C contructs like struct and
> typedef in the future? if this is not the case it sounds terribly
> broken.

I don't expect to see C type expressions in the main script language.
I expect a limited class of C-style pointer expressions to be parsed
and evaluated against the debugging information ($ptr->field->field).
With experience, we may need to expand that facility somewhat to cover
other cases, like struct "downcasting" used in various places.  I
don't know what the far future will hold, except that "terrible
brokenness" is unlikely to be acceptable.


- FChE