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