Re: variables in scopes

[Roland McGrath <roland at redhat dot com>]

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

If you make it possible to refer to pointers (rather than just "value of
this dereference chain starting at a variable"), then you need to carry the
type information along with the pointer values.  That is, something like
having systemtap variables with type "probed-space pointer to type foo".
You can't really recover the source language scoping of the type
definitions, and there isn't a useful meaning to that in C anyway.  Each
compilation unit will specify complete details about the types used in its
variables.  If you have one piece of systemtap probe code that extracts a
pointer value, and a separate piece that later uses that saved value, their
type for the systemtap variable they share (or pass as argument or whatever
they can do) has to match.  Each one might be defined as "struct foobar",
referring to some specification of source location or somesuch to indicate
the set of DWARF information where "struct foobar" will be found.  You
can't match those up for naming identity in any useful way.  But, you can
compare their concrete definitions and declare them identical if their
fields are in the same places and defined identically (recurse).

However, that only deals with the type of the data pointed to.  There is
also the address space (or abstractly, region) in which the memory resides.
Obviously there are kernel pointer and user pointers.  That is not two
regions, but many--there is a separate address space for each user process.
Among "kernel pointers", there is still more to the picture.  There is
vmalloc space, which might be unmapped entirely.  There are pointers from
"kmap", which are pages not normally fixed in the kernel address space
(pages in user address space, or page table pages).  Those are accessible
only in the short period while they're being used, and then they're unmapped.

All of this complexity makes me agree vigorously that it is indeed the best
plan not to allow storing pointers.  At the instant of a probe point, you
can dereference out the wazoo sensibly, but as soon as the probe has let
the kernel progress, cached pointers are hard to keep track of.

Of course, with safe access you can just let a probe-writer shoot himself
in the foot hanging on to bad pointers and using them later.  He'll just
get his probes bailing out with an error.  But I am inclined not to let
probes get into this can of worms until there is a proven need for it.

> > [...]  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.)

In fact, the "inline checks" are in fact just taking advantage of fault
handlers in a different way.  As I said, they have zero overhead.  One just
uses some macros that do the access with static annotations pointing to
fixup code--it's the same sort of code that any kernel/module code using
the `get_user' et al macros produces.  We'll just have in the runtime some
variant macros that do the fault recovery without the part in `get_user'
that requires a pointer in the address space accessible to user mode.

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

This seems like it's fairly easy to do.  I don't much care about the
syntax, myself.

>    $var[idx]     - to index an array; idx being any systemtap expression

Is this meant for explicit, sized array types only?  Otherwise there are no
known bounds to check, and this is tantamount to a (type *)idx facility.


Thanks,
Roland