Re: variables in scopes

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -

prasadav wrote:

> [...]
> z(i,j)->a(x,y)->b(c,d)
> Let us say we are now probing function b, if i understand correctly this 
> proposal is how do we provide access to variable x from caller a or  to 
> variable i from caller z in the probe handler [...]

No - that would require a runtime search for debuginfo of a caller.
I believe Uli was referring to this scenario:

void foo (int arg1)
{
   { int arg1;  { int arg1;  { arg1++; } } arg1 ++ ; } 
}

where each new arg1 declaration hides the one from the outer scope.


> [...]  If we really want to implement this i would suggest doing
> this as a function call rather than as the language construct. A
> function something like getshadowvar(variable_name,
> function_in_which_it_is_active, levels_above) this way we can keep
> language simple.

By coincidence, this reminds me...

I prefer a function syntax like this in order to perform target-space
debuginfo-based data references.  Contrast this with Jim's
dpcc-inspired @expr@ or probe("expr") ideas.  Rather than supporting
an embedding of expressions that need to be parsed, consider instead
asking the user to provide an explicit "parse tree" in the syntax of
function calls.

In Jim's proposal, @a+b+c@ was included as a sample expression to be
evaluated in target space.  This seems like a weak example, given that
systemtap can already add.  A better one would be this construct
@filp->f_dentry->d_inode@ living in a probe of filp_open().  I propose
a functional syntax such as 
    field(field(var("filp"),"f_dentry"),"d_inode")

The "field"/"var" functions, and probably a few more like these, would
be specially evaluated at translation time to traverse the dwarf
debuginfo relevant to each probe point context.  Since these operators
would be based on dwarf constructs, they could be independent of the
target language.  (Also, to express Uli's idea, var("filp") could be
parametrized with a scope up-count.)

In the few spots where this would be statically sensible, values from
the systemtap variable space might be usable instead of literals:
@f->array[n]@ (with n in systemtap space rather than target space)
might map to
    index(field(var("f"),"array"),n)

It may be possible to abbreviate this stuff with macros or more syntax
heuristics, but that might not be worth the loss of explicitness.


Note that most of this complication is associated with pointer/struct
traversal.  dtrace's answer to this is to allow typed pointers to be
an additional script-side data type.  Maybe we should consider this.


- FChE

Attachment: pgp00000.pgp
Description: PGP signature