On Wed, 2005-04-13 at 13:25, Frank Ch. Eigler wrote:
...
By coincidence, this reminds me...
....
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.