This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: variables in scopes
On Wed, 2005-04-13 at 17:15, Frank Ch. Eigler wrote:
> Hi -
>
> > [...] Seriously, I believe that this is a fundamental safety We
> > presumably won't crash any spacecraft, but we could crash a
> > customer's system. Dtrace doesn't have to worry about this so much
> > because the user is in a pretty tight straitjacket.
>
> Please be more specific. Having implicitly declared and typed
> systemtap variables poses a crash risk to the kernel how?
probe s; // array of pointers to structs
j = -1;
...
jj = what_j_should_be; // misspelled "j" as "jj"
...
... s[j]->foo ...
This gives you at least a stray memory reference. If it's an assignment
to s[j]->foo, it scribbles on God-knows-what.
>
>
> > > [...]
> > > It seems to me that we are really missing only a few constructs:
> > > - referring to variables in target space
> > > - performing -> . [] on those pointer variables and related names
> > > Does something else very useful come to mind?
> >
> > & lvalue
> > * pointer
> > functions calls -- to three types of functions:
> > a) SystemTap auxiliary functions (as currently parsed)
> > b) C functions in the context of the probed function
> > c) C functions (set off by yacc/lex escapes such as %% or %{...%}) that
> > are copied from the .stp file to the module's .c file.
>
> That looks like way too generous. Can you provide motivation for each
> of these constructs as really useful/necessary to a systemtap user?
> They clearly toss the barn door wide open.
Yes, I'm sure I could, but I think we agree that it would more useful to
create real-world instrumentation and see which features we need. If
you like, I could hack your parser to accept the "Jim" constructs I
suggest above. The parser could have a --jim mode, which quietly
accepts the "Jim" constructs, and a (default) --frank mode, which
complains about them. If real-world instrumentation can be created in
--frank mode, then we can forgo further implementation of the "Jim"
constructs.
> - FChE
Jim