Constraint Solving for Program Analysis

1. Program Analysis as Constraint Solving

2. Constraint Solving • Goal: Perform program analysis by solving constraints • Can be used to • Find invariants for program verification • Compute weakest precondition/strongest postcondition • Computing most general counter-examples

3. Why constraint-based? • Alternatives are fixed-point techniques • data-flow analysis • model checking • Constraint-based are goal-directed • Don't require widening heuristics • This paper's primary contribution is to focus only on constraint-based solutions

4. The Problems • Program verification • We have an assertion A that we want to prove • Program verification analysis should discover some invariant I such that I => A • Previous constraint-based techniques are only intra-procedural

5. The Problems • Weakest precondition/strongest postcondition • WP is the weakest precondition required (before executing the program) such that if it is satisfied the program is guaranteed not to fail • Will not an assertion • May not terminate • B is weaker than A if it implies “less” • A => B but not B => A

6. Program Model • x denotes integer variable • e is linear arithmetic expression • Linear assignments • x := e • x := ? (non-deterministic assignment)‏ • assume(p)‏: Assume p is true from earlier action • assert(p)‏: Halt program if p is not true • p is boolean predicate of linear inequalities • Form: e >= 0

7. Program Model • Example: • x + y >= 30 • x + y – 30 >= 0 • x <= 30 • -x >= -30 • -x + 30 >= 0

8. Program Verification • Idea: Convert program verification problem to second-order constraint satisfaction problem • The unknowns in the constraint correspond to the program invariants • Goal is to find the solution for unknowns that satisfy constraint • Then we also find program invariants

9. Approach (Overview)‏ • Convert program to second-order logical constraints • Assume that second-order unknowns in the constraint are actually first-order unknowns (using templates) • Convert first-order universal quantification to first-order existential quantification (using integer-specific lemma)‏ • Convert formula to SAT and solve

10. Convert program to constraints • Choose a cut set • Set of program points such that each cycle in the CFG passes through at least one of the points • At each cut point • Define “relation” I over all live program variables • The relation is the invariant at each point in the program • True at entry and exit • Unknown everywhere else • These are what we want to solve

11. Constraint • In words: At all adjacent cut points, the invariant at each cut point should be “compatible”

12. Constraint • The overall constraint is the conjunction over each pair of adjacent cut points

13. Convert to first-order unknown • The unknowns in our constraint are the unknown second-order relations • We restrict them to templates, i.e., • Problem: How do we pick the template? • What if the template is not expressive enough?

14. Example

15. Example

16. Simplify unknownsFarkas’ Lemma Of course, this will not discover things that are satisfiable in rationals but not integers

17. Simplify unknowns

18. Simplify unknowns Bottom constraint comes from polynomial comparison in y to negative lambda

19. Convert to SAT • Using bitvector theory • When satisfied, plug solutions back into template to get invariant

20. Choice of cut-set • Contribution: Some cut sets lead to better invariants • Choosing disjoint paths in loops will result in better invariants

21. Procedure summaries • Can use this technique to generate pre/post pairs (not well described)

22. Procedure summaries

23. Procedure summaries

24. Weakest precondition • Limit weakest precondition up to some constant c and fitting a template structure • First, treat the entry relation as unknown • Then, iteratively search for weaker preconditions • This doesn’t scale!

25. Weakest precondition • Instead, they add a new constraint to the VC

26. Weakest precondition • But, this structure does not fit Farkas’ lemma • They present two strategies • One does binary search over each possible constant assignment • The other sets the relation at each cut point to be the weakest consistent with its neighbors

27. Strongest postcondition • This is very similar to weakest precondition

28. Bounds Analysis

29. Most General Counter-Example If each assert statement fails, set an err variable to true and go to the end of the program. Then, compute weakest precondition. This gives the “opposite” of the regular weakest precondition.

30. Most General Terminating Counter-Example Assert(false)

31. Program Verification using Predicate Abstraction • Problem: Program Verification as before • They want to analyze linked list and sorting algorithms • This requires finding more expressive invariants • Before: Only linear inequalities connected by conjunctions and disjunctions • Now: Arbitrary first order logical formulas

32. Predicate Abstraction • Predicate Abstraction • The programmer knows the invariant has some form (forall x, there exists y, …..) • Also knows the basic predicates • Relations • Variables • Constants • Marks unknowns • The algorithms in this paper find the unknowns

33. Templates Unknown

34. Program Model • Similar to other paper, but not limited to linear expressions • Not using Farkas’ lemma anymore

35. Example

36. Three Algorithms • Two iterative data-flow like propagation of facts • Constraint-based (like the previous paper)

37. Results

38. Results