Re: Few queries on tapset interface

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

jkenisto wrote:

> [...]  If we're going to use $var to mean "var in the context of the
> probed function," then I think it's confusing to start names of
> language-defined values (such as $timestamp) with '$' as well.
> [...]

Yes.  This is what I was referring to obliquely with that "$-variable
resolution rules must be specified" comment.  The variable namespaces
need to be separated.  dtrace for example uses "`" as a prefix for
target-space variables.


> I think that the thread->assoc_array syntax is confusing, especially
> now that the language supports the C-language meaning of -> [... so
> let's use array[$tid] ...]

I agree (though "->" is still only going to be a pale shadow of C's).


> [...]
> >       trace ("syscall " . $syscall_name .
> >              " return value = " .
> >              hexstring ($retvalue));  # function pseudo-argument
> > }
> 
> The runtime provides _stp_printf() for printk-like logging, so you could
> do something like
> 	_stp_printf("syscall %s return value = %#x\n",
> 		$syscall_name, $retvalue);

The runtime and the translator have not been sanity checked against
each other yet.  In particular, while varargs functions like printf
are cute in C and look kind of friendly, it may be just as well to
leave them out from the script language.


> > probe end {
> >       for ([syscall] in read_times) {
> 
> Why "[syscall]" rather than "syscall" in the "for" clause?

The square brackets would be optional for a single index:
    foreach (a in array) { }
    foreach ([a] in array) { }
    foreach ([a, b] in array2) { }


- FChE