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