[PATCH] Support OR (using ||) in preprocessor's conditions.

[PATCH] Support OR (using ||) in preprocessor's conditions.

[Przemyslaw Pawelczyk]

---
 parse.cxx |   18 +++++++++++++++++-
 1 files changed, 17 insertions(+), 1 deletions(-)

diff --git a/parse.cxx b/parse.cxx
index a26d594..52712bd 100644
--- a/parse.cxx
+++ b/parse.cxx
@@ -337,11 +337,27 @@ parser::scan_pp (bool wildcard)
       delete op;
       delete r;
 
+      const token *n;
+      while ((n = input.scan ()) && n->type == tok_operator && n->content == "||")
+        {
+          l = input.scan (false);
+          op = input.scan (false);
+          r = input.scan (false);
+          if (l == 0 || op == 0 || r == 0)
+            throw parse_error ("incomplete condition after '%('", t);
+
+          result |= eval_pp_conditional (session, l, op, r);
+          delete l;
+          delete op;
+          delete r;
+          delete n;
+        }
+
       /*
       clog << "PP eval (" << *t << ") == " << result << endl;
       */
 
-      const token *m = input.scan (); // NB: not recursive
+      const token *m = n; // NB: not recursive
       if (! (m && m->type == tok_operator && m->content == "%?"))
         throw parse_error ("expected '%?' marker for conditional", t);
       delete m; // "%?"
-- 
1.5.6.5

[PATCH] Support || and && in preprocessor's conditions.

[Przemyslaw Pawelczyk]

---
 parse.cxx |   30 ++++++++++++++++++++++++++++--
 1 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/parse.cxx b/parse.cxx
index a26d594..a74b513 100644
--- a/parse.cxx
+++ b/parse.cxx
@@ -332,16 +332,42 @@ parser::scan_pp (bool wildcard)
 
       // Do not evaluate the condition if we haven't expanded everything.
       // This may occur when having several recursive conditionals.
-      bool result = eval_pp_conditional (session, l, op, r);
+      bool and_result = eval_pp_conditional (session, l, op, r);
       delete l;
       delete op;
       delete r;
 
+      bool result = false;
+      const token *n;
+      while ((n = input.scan ()) && n->type == tok_operator)
+        {
+          if (n->content == "||")
+            {
+              result |= and_result;
+              and_result = true;
+            }
+          else if (n->content != "&&")
+            break;
+          l = input.scan (false);
+          op = input.scan (false);
+          r = input.scan (false);
+          if (l == 0 || op == 0 || r == 0)
+            throw parse_error ("incomplete condition after '%('", t);
+
+          and_result &= eval_pp_conditional (session, l, op, r);
+          delete l;
+          delete op;
+          delete r;
+          delete n;
+        }
+
+      result |= and_result;
+
       /*
       clog << "PP eval (" << *t << ") == " << result << endl;
       */
 
-      const token *m = input.scan (); // NB: not recursive
+      const token *m = n; // NB: not recursive
       if (! (m && m->type == tok_operator && m->content == "%?"))
         throw parse_error ("expected '%?' marker for conditional", t);
       delete m; // "%?"
-- 
1.5.6.5

Re: [PATCH] Support || and && in preprocessor's conditions.

[Josh Stone]

On 06/20/2009 06:17 AM, Przemyslaw Pawelczyk wrote:
> ---
>  parse.cxx |   30 ++++++++++++++++++++++++++++--
>  1 files changed, 28 insertions(+), 2 deletions(-)
> 
> diff --git a/parse.cxx b/parse.cxx
> index a26d594..a74b513 100644
> --- a/parse.cxx
> +++ b/parse.cxx
> @@ -332,16 +332,42 @@ parser::scan_pp (bool wildcard)
>  
>        // Do not evaluate the condition if we haven't expanded everything.
>        // This may occur when having several recursive conditionals.
> -      bool result = eval_pp_conditional (session, l, op, r);
> +      bool and_result = eval_pp_conditional (session, l, op, r);
>        delete l;
>        delete op;
>        delete r;
>  
> +      bool result = false;
> +      const token *n;
> +      while ((n = input.scan ()) && n->type == tok_operator)
> +        {
> +          if (n->content == "||")
> +            {
> +              result |= and_result;
> +              and_result = true;
> +            }
> +          else if (n->content != "&&")
> +            break;
> +          l = input.scan (false);
> +          op = input.scan (false);
> +          r = input.scan (false);
> +          if (l == 0 || op == 0 || r == 0)
> +            throw parse_error ("incomplete condition after '%('", t);
> +
> +          and_result &= eval_pp_conditional (session, l, op, r);
> +          delete l;
> +          delete op;
> +          delete r;
> +          delete n;
> +        }
> +
> +      result |= and_result;

The approach looks ok, but I would like to see less code duplication.
This might work better as a do-while loop, and it may also help to push
the scan/delete of (l,op,r) into eval_pp_conditional.

We need testcases for this too.  I don't think runtime tests are
necessary -- just semok and semko tests are probably fine, stuff like:

probe %( kernel_v > "99" || arch != "foo" %? begin %: badprobe %) {}

Note that *ok tests can be bundled together, but *ko tests must have
only one failure per test file.

It would also be nice if you could survey the tapsets and patch up
pieces to use these conditionals.  For example, the probe
scheduler.ctxswitch has redundancies that could be eliminated.

Thanks,

Josh

[PATCH 1/2] Support || and && in preprocessor's conditions.

[Przemyslaw Pawelczyk]

* parse.cxx (parser::scan_pp): Add || and &&.
* stap.1.in: Document || and && in PREPROCESSING.
* testsuite/parseok/twenty.stp: Test case.
* testsuite/parseko/preprocess14.stp: Ditto.
* testsuite/parseko/preprocess15.stp: Ditto.
---
 parse.cxx                          |   46 +++++++++++++++++++++++------------
 stap.1.in                          |    5 +++-
 testsuite/parseko/preprocess14.stp |    4 +++
 testsuite/parseko/preprocess15.stp |    4 +++
 testsuite/parseok/twenty.stp       |   12 +++++++++
 5 files changed, 54 insertions(+), 17 deletions(-)
 create mode 100755 testsuite/parseko/preprocess14.stp
 create mode 100755 testsuite/parseko/preprocess15.stp
 create mode 100755 testsuite/parseok/twenty.stp

diff --git a/parse.cxx b/parse.cxx
index 41a13ca..a2e2b65 100644
--- a/parse.cxx
+++ b/parse.cxx
@@ -321,27 +321,41 @@ parser::scan_pp (bool wildcard)
 
       // We have a %( - it's time to throw a preprocessing party!
 
-      const token *l, *op, *r;
-      l = input.scan (false); // NB: not recursive, though perhaps could be
-      op = input.scan (false);
-      r = input.scan (false);
-      if (l == 0 || op == 0 || r == 0)
-        throw parse_error ("incomplete condition after '%('", t);
-      // NB: consider generalizing to consume all tokens until %?, and
-      // passing that as a vector to an evaluator.
-
-      // Do not evaluate the condition if we haven't expanded everything.
-      // This may occur when having several recursive conditionals.
-      bool result = eval_pp_conditional (session, l, op, r);
-      delete l;
-      delete op;
-      delete r;
+      bool result = false;
+      bool and_result = true;
+      const token *n = NULL;
+      do {
+        const token *l, *op, *r;
+        l = input.scan (false); // NB: not recursive, though perhaps could be
+        op = input.scan (false);
+        r = input.scan (false);
+        if (l == 0 || op == 0 || r == 0)
+          throw parse_error ("incomplete condition after '%('", t);
+        // NB: consider generalizing to consume all tokens until %?, and
+        // passing that as a vector to an evaluator.
+
+        // Do not evaluate the condition if we haven't expanded everything.
+        // This may occur when having several recursive conditionals.
+        and_result &= eval_pp_conditional (session, l, op, r);
+        delete l;
+        delete op;
+        delete r;
+        delete n;
+
+        n = input.scan ();
+        if (n && n->type == tok_operator && n->content == "&&")
+          continue;
+        result |= and_result;
+        and_result = true;
+        if (! (n && n->type == tok_operator && n->content == "||"))
+          break;
+      } while (true);
 
       /*
       clog << "PP eval (" << *t << ") == " << result << endl;
       */
 
-      const token *m = input.scan (); // NB: not recursive
+      const token *m = n; // NB: not recursive
       if (! (m && m->type == tok_operator && m->content == "%?"))
         throw parse_error ("expected '%?' marker for conditional", t);
       delete m; // "%?"
diff --git a/stap.1.in b/stap.1.in
index aafd2d7..3ac1c39 100644
--- a/stap.1.in
+++ b/stap.1.in
@@ -309,7 +309,10 @@ ternary operator:
 .ESAMPLE
 The CONDITION is either an expression whose format is determined by its
 first keyword, or a string literals comparison or a numeric literals
-comparison.
+comparison.  It can be also composed of many alternatives and conjunctions
+of CONDITIONs (meant as in previous sentence) using || and && respectively.
+However, parentheses are not supported yet, so remembering that conjunction
+takes precedence over alternative is important.
 .PP
 If the first part is the identifier
 .BR kernel_vr " or " kernel_v
diff --git a/testsuite/parseko/preprocess14.stp b/testsuite/parseko/preprocess14.stp
new file mode 100755
index 0000000..7946f0e
--- /dev/null
+++ b/testsuite/parseko/preprocess14.stp
@@ -0,0 +1,4 @@
+#! stap -p1
+
+# incomplete compound condition
+%( arch == "2.6" && %? probe begin() { } %)
diff --git a/testsuite/parseko/preprocess15.stp b/testsuite/parseko/preprocess15.stp
new file mode 100755
index 0000000..c4aaa9c
--- /dev/null
+++ b/testsuite/parseko/preprocess15.stp
@@ -0,0 +1,4 @@
+#! stap -p1
+
+# bad compound condition
+%( arch == "2.6" && || arch == "2.66" %? probe begin() { } %)
diff --git a/testsuite/parseok/twenty.stp b/testsuite/parseok/twenty.stp
new file mode 100755
index 0000000..d474ad5
--- /dev/null
+++ b/testsuite/parseok/twenty.stp
@@ -0,0 +1,12 @@
+#! stap -p1
+
+global
+%( kernel_v > "2.6" && kernel_vr != "2.9.77-2873NOTHING" && kernel_v <= "3.5" && kernel_vr == "2.3.5-2.43.54.2" %? "FAIL1" %: PASS %)
+
+global
+%( arch == "i386" || arch == "i686" || arch == "x86_64" %? x86 %: other %)
+
+global
+%( $# != 2 && @# < "1" && @# == "0" && $# >= 3 %?
+   %( $2 >= "12" %? $3 FAIL2 %: $2 FAIL3 %) #This line must not be evaluated
+%: PASS2 %)
-- 
1.5.6.5

[PATCH 2/2] Use || and && in preprocessor's conditions in tapsets.

[Przemyslaw Pawelczyk]

---
 tapset/scheduler.stp |   16 +++-------------
 1 files changed, 3 insertions(+), 13 deletions(-)

diff --git a/tapset/scheduler.stp b/tapset/scheduler.stp
index 45ddbb0..d67e031 100644
--- a/tapset/scheduler.stp
+++ b/tapset/scheduler.stp
@@ -121,12 +121,8 @@ probe scheduler.balance = kernel.function("idle_balance")? {}
  *    prevtsk_state: the state of the process to be switched out
  */
 probe scheduler.ctxswitch =
-%( arch != "x86_64" %?
- %( arch != "ia64" %?
+%( arch != "x86_64" && arch != "ia64" %?
 	kernel.function("__switch_to")
- %:
-	kernel.function("context_switch")
- %)
 %:
 	kernel.function("context_switch")
 %)
@@ -137,13 +133,7 @@ probe scheduler.ctxswitch =
         prev_task = $prev
         next_task = $new
         prevtsk_state = $prev->state
-%: %( arch == "x86_64" %?
-        prev_pid = $prev->pid
-        next_pid =  $next->pid
-        prev_task = $prev
-        next_task = $next
-        prevtsk_state = $prev->state
-%: %( arch == "ia64" %?
+%: %( arch == "x86_64" || arch == "ia64" %?
         prev_pid = $prev->pid
         next_pid =  $next->pid
         prev_task = $prev
@@ -155,5 +145,5 @@ probe scheduler.ctxswitch =
         prev_task = $prev_p
         next_task = $next_p
         prevtsk_state = $prev_p->state
-%) %) %)
+%) %)
 }
-- 
1.5.6.5

Re: [PATCH 1/2] Support || and && in preprocessor's conditions.

[Josh Stone]

Both patches applied and pushed -- thanks!

Josh