Re: variables in scopes

[Jim Keniston <jkenisto at us dot ibm dot com>]

On Wed, 2005-04-13 at 13:25, Frank Ch. Eigler wrote:

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

Actually, the example was @x->y + z@, which systemtap doesn't currently
support.

> 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")
> 

I honestly don't think we'd ever convince people to write such stuff.

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

rpn and assembly language are also target-language independent, but
nobody codes in them unless they have to.  The gdb expression parser
already supports C expressions and most C++ expressions, which should
take us a long way.  I can't imagine SystemTap succeeding without
allowing access to kernel data structures using C syntax. 

> (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)

Indeed, the @expr@ syntax doesn't provide access to systemtap variables
without further tweaking.  If this feature is deemed important, then I'd
suggest enhancing the systemtap parser to handle all C expressions, and
support the following type of semantics:

probe kernel.function("foo").entry
{
  local n;
  probe f;
  ...
  ... f->array[n] ...
}

Here "probe f" means f refers to identifier f in the context of the
probed function.  (We don't have to say "probe array" because the debug
info can verify that array is a field of f.)

"local n" means n is a script-local variable.  (By the way, I've always
been uncomfortable with allowing the use of undeclared variables.  I've
heard too many stories about typos in FORTRAN programs yielding
disastrous results.)

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

We really need to bite the bullet and parse full C expressions -- with
the gdb parser's help or without it.  Don't make the "expert" script
and/or tapset writer do the parsing for us.

> 
> 
> - FChE

Jim