See http://sourceware.org/ml/systemtap/2007-q3/msg00023.html for one possibility.
I'm interested in this feature. As far as I understand, with this feature, systemtap treats the next script ; --- probe ALIAS=PROBEPOINT { stmt1; } probe ALIAS if (expr) { stmt2; } --- as --- probe PROBEPOINT { if (!expr) next; stmt1; stmt2} --- In that case, --- probe ALIAS=PROBEPOINT { stmt1; } probe ALIAS if (expr) { stmt2; } probe ALIAS { stmt3; } --- will be treated as --- probe PROBEPOINT { if (!expr) next; stmt1; stmt2} probe PROBEPOINT { stmt1; stmt3} --- Is that right?
> In that case, > --- > probe ALIAS=PROBEPOINT { stmt1; } > probe ALIAS if (expr) { stmt2; } > probe ALIAS { stmt3; } > --- > will be treated as > --- > probe PROBEPOINT { if (!expr) next; stmt1; stmt2} > probe PROBEPOINT { stmt1; stmt3} > --- > Is that right? That's right. It wouldn't make sense to act as if the conditional was within the probe handler block (after the prefix from aliases), since that would require the underlying probe to still be active. It also means that the variables in "expr" can in practice only involve global script-level variables. (Even pure embedded-C functions can change their values frequently enough to make them impractical as part of an automatic predicate. In this sort of case, we could opt to automatically translate the script to the "{ if (!expr) next; ... }" form, which would run correctly but slowly.)
Created attachment 2095 [details] on-the-fly enable/disable probes patch for parser and elabolator I developed a patch for the parser and the elabolator to support this syntax. Currently, this just translates the next script; --- probe ALIAS=PROBEPOINT if (expr1) { stmt1 } probe ALIAS if (expr2) { stmt2 } --- to below; --- probe PROBEPOINT { if (!((expr2)&&(expr1))) next stmt1 stmt2 } --- This patch adds "if (..)" condition to the PROBEPOINT instead of "probe". So, you can write the below script with this patch; --- probe PP1 if (expr1), PP2 if (expr2) {stmt} --- This is translated to below; --- probe PP1 { if (!expr1) next stmt } probe PP2 { if (!expr2) next stmt } --- This is the first step of this feature, since this patch does not include optimization code. Thanks,
Created attachment 2110 [details] A bugfix patch for on-the-fly probe enable/disable syntax This patch fixes a bug in the previous patch to allow user to access kernel variables in the condition expression of probe points.
(In reply to comment #4) > This patch fixes a bug in the previous patch to allow user to access kernel > variables in the condition expression of probe points. Please note that use of this capability would render the probe un-disableable, since kernel $context variables need to be evaluated from a single particular kprobe rather than anywhere in the script.
(In reply to comment #5) > Please note that use of this capability would render the probe un-disableable, > since kernel $context variables need to be evaluated from a single particular > kprobe rather than anywhere in the script. > Sure, I agree. I think when we access only global variables in the condition and those variables are not changed in the probe point, the probe will be disabled automagically from other probes where those global variables are changed. And This optimization depends on where the global variables are changed. Procfs probes and timer probe are good places to do that.
Created attachment 2122 [details] Documentation patch for on-the-fly probe enable/disable syntax This patch adds comments in manpage and NEWS.
Created attachment 2123 [details] Testcases for on-the-fly probe enable/disable syntax This patch adds testcases for on-the-fly probe enable/disable syntax, which includes: - parser tests (ok/ko) - semantic tests (ok/ko) - basic functionality test
Thank you, these are good to commit. We can fix minor spelling errors in CVS. One question regarding the new semko/thirtynine test: why should that fail rather than be interpreted as an unconditional probe that happens to contain ".if(1)" as the last probe point component?
(In reply to comment #9) > One question regarding the new semko/thirtynine test: why should that fail > rather than be interpreted as an unconditional probe that happens to contain > ".if(1)" as the last probe point component? Because the "if()" statement is not a component of a probe point, you should NOT use it with ".". The parser passes ".if(1)" as a probe point component.However, the elaborator fails to resolve it, so it is "semko". Here is the error output: --- semantic error: probe point mismatch at position 2 (alternatives: call inline return) while resolving probe point kernel.function("sys_open").if(1) --- Thanks,
I got following error message with latest systemtap. $ stap -e 'probe kernel.function("netlink_unicast") if (execname()=="swapper"){ print_backtrace();}' semantic error: probe condition must not reference function: identifier 'execname' at <input>:1:46 Pass 2: analysis failed. Try again with more '-v' (verbose) options. Why can not we use function or kernel-variables in probepoint condition?
> $ stap -e 'probe kernel.function("netlink_unicast") if (execname()=="swapper"){ > Why can not we use function or kernel-variables in probepoint condition? In this case, the reason is that such expressions can't be optimized in the sense that probes with such conditions cannot actually be armed/disarmed, because the translator has no way of knowing when execname() (an embedded-C function) will change value. As for pure script functions and such - the current code blocks them out, but some of that is temporary. (The reasoning there goes that even to evaluate expressions containing such function calls, more context space and statement-counting calculations are necessary. That's not ideal considering that We did discuss letting the script still more unrestricted condition expressions, (including embedded-C functions or $target variables), and implement that the way your first checkin did: by prepending the condition to the probe handler body as if it had been there all along. (A warning should be produced.) This may well come back. I just wanted to restrict it for the moment while the actual optimization implementation is proceeding.
With the syntax already in, what's left is support in the translator and the runtime for asynchronous kprobe (and in general, other derived_probe) arming/disarming. *** This bug has been marked as a duplicate of 6933 ***