This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |