Re: variables in scopes

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

Hi -


roland wrote:

> > 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.
> 
> Can you elaborate/clarify exactly what this means and looks like?  Does
> that mean systemtap language having variables whose type is "pointer to
> type foobar in the kernel context"?  

Yeah, something like that, basing this from merely reading about
dtrace and not playing with it.  Such pointer-typed values can be
dereferenced with -> (and *?), but I believe cannot be manufactured
casually.  Strangely though, pointer types may be conversion-cast to
each other explicitly.

My main concern with storing pointers relates to the typing
information.  Typing is relative to a probe point that defines an
executable address: that's where type-related debuginfo may be
searched for.  But now if a pointer value is stored in some systemtap
script variable, then used later in a different probe context, then
what the heck is the meaning of the pointer operation?  Imagine taking
an address from kernel space, then using it to dereference a "kernel"
struct in a (future) user space probe.  The original type may not even
exist in the other context.

(dtrace does not have this problem because the list of struct types is
fixed in script headers, not derived from actual debuginfo with its
scoping etc. complications.)


> [...]  That is, I think that for safety the only sane thing is to
> have the probe code use runtime macros that do the pointer fetches
> with fault recovery [...]

Definitely.  (Brad, systemtap would likely emit such checks inline and
not depend on the fault handler.)


I would like to find solution that does not involve storage of pointer
values, but still allows their compact dereferencing in their context
of origin.  Maybe we can hit both the target-value-naming and
pointer-dereferencing birds with a single syntactic rock.  How about
allowing just these constructs (and their natural compositions):

   $var          - to refer to "var" in probe target scope
   $$var         - same, but skip 1 lexical scope
   $var->field   - to refer to "var", dereferencing given field
   $var.subfield - analogously for non-pointer
   $var[idx]     - to index an array; idx being any systemtap expression

In each case, the overall value of the expression would be cast to a
systemtap number or string type for storage.  In safe mode, they would
be an unassignable rvalue.

- FChE

Attachment: pgp00000.pgp
Description: PGP signature