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]

Re: variables in scopes


Hi -


jkenisto wrote:

> [...]
> > In Jim's proposal, @a+b+c@ was included as a sample expression to be
> > evaluated in target space.  This seems like a weak example, given that
> > systemtap can already add.
> 
> Actually, the example was @x->y + z@, which systemtap doesn't currently
> support.

And yet the interesting part of that is not the "+" but only the "->".


> > A better one would be this construct
> > @filp->f_dentry->d_inode@ living in a probe of filp_open().  I propose
> > a functional syntax such as 
> >     field(field(var("filp"),"f_dentry"),"d_inode")
>
> I honestly don't think we'd ever convince people to write such
> stuff.  [...] I can't imagine SystemTap succeeding without allowing
> access to kernel data structures using C syntax. [...]

You may be right.  Have you given consideration to the other
alternatives I sent to you privately, when you first posted your
language spec additions?


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

Thankfully this is not FORTRAN, we're not controlling a spacecraft,
and many other languages (including dtrace) get by just fine with such
properties.


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

Does someone have a response to this part?

 
> We really need to bite the bullet and parse full C expressions -- with
> the gdb parser's help or without it.  [...]

Not really.  While we may like to have a more compact way of
performing some operations in target space, that is a long way from
requiring that "full C" is parsed (casts?  assignments?  function
calls?  declarations?  control structures? ...).

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?


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