1 Analysis Information Where Do Facts Hold? How much information - PDF document

711? CS711 Advanced Programming Languages Topics in Program Analysis Radu Rugina Fall 2005 CS711 Overview 2 Program Analysis Static vs. Dynamic • Static analysis: inspect programs at compile-time • Static analysis: – Work done at compile-time • Extract information about program execution – Characterizes all executions – Characterize dynamic program executions – Conservative: approximates concrete program states • Use analysis results for: • Dynamic analysis: – Optimizations and transformations – Run-time overhead – Program verification – Characterizes one or a few executions – Error detection – Precise: knows the concrete program state – Program understanding – Can ’ t “ look into the future ” CS711 Overview 3 CS711 Overview 4 Classifying Program Analyses Analysis Information • Figure out “ facts ” about the program execution • Lots of approaches to static analysis • Facts typically talk about: – How do they compare to each other? – What distinguishes them? – The values in the memory • Constant propagation: x = 5 • Main aspects of program analyses: • Points-to analysis: x points to y • Types: value of x is an integer – What information are we interested in? • Verification: the result of fact(n) = n! – What program constructs? – Events during program execution – How does the analysis work? • Liveness: variable x never used in the future – How much user interaction? • Temporal properties, e.g. lock-unlock property – Is the analysis sound? CS711 Overview 5 CS711 Overview 6 1

Analysis Information Where Do Facts Hold? • How much information depends on the client • Facts hold: – Either locally (e.g., at a particular program points) – Or globally (throughout the program. E.g., types) • E.g., program verification: show lack of errors • What is an error? increasingly difficult • Program points approximate sets of points in – Type error? dynamic execution traces – Memory error? – Incorrect result? • Can refine program points using: – The calling stack when the execution reaches a point – The program path that lead to a point CS711 Overview 7 CS711 Overview 8 Program Constructs Program Constructs functional imperative functions higher-order functions higher-order pointers pointers functions functions recursive recursive structures structures arrays arrays polymorphism polymorphism control control constructs constructs destructive destructive threads threads updates updates objects objects virtual virtual machine machine inheritance inheritance calls calls exceptions exceptions OO code code CS711 Overview 9 CS711 Overview 10 Analysis Techniques Abstractions • Dataflow analysis, Abstract interpretation • Analyses must use abstractions – Flow-sensitive: track facts through the control-flow – Model computation in the program • Type systems – Model program state – Check or infer types for program expressions • describe unbounded sets of unbounded states – Typically flow-insensitive • Finite, tractable abstractions are desirable • Constraint methods – Reduce the analysis problem to a set of constraints • Examples: – Examples: set constraints, linear systems, boolean formulas, etc. – Dataflow, AI: CFGs, SSA, lattices – Separates specification from implementation – Model checking: transition systems, temporal logic formulas • Model checking – Type systems: type abstraction, typing rules (type constraints) – Check properties expressed as temporal logic formulas – Constraint methods: constraints • Theorem proving – Theorem proving: theorems – Use logical deduction to prove facts CS711 Overview 11 CS711 Overview 12 2

User Interaction Soundness • Soundness: analysis conservatively approximates all • Three ways users can interact with analyses: program executions – Help the analysis: annotations, specifications • Unsound analyses: might miss some facts • Typical example: types – “ false negatives ” = “ missed facts ” • Best way to help the analysis: provide information at – “ false positives ” = “ facts that never occur ” procedure boundaries, loop invariants (Hoare-style) • Is soundness desirable? – Help the analysis: interactive – Definitely for analyses, transformations, verification • Provide help while the analysis runs – Error-detection is a different story • Unsound analyses okay – Tell the analysis what to compute: parameterization • Unsound analyses can prove the presence of errors, not their absence • User tells what facts the analysis should compute/verify • Sources of unsoundness: • Example: finite state machine models – Treatment of aliasing, loops, recursion, type-unsafe constructs CS711 Overview 13 CS711 Overview 14 Proving Soundness Efficiency and Scalability • How do I know that the analysis is sound? • Analyses can be expensive – Define program semantics – E.g., inter-procedural, flow-sensitive analyses – AI framework: show that abstract transformer yields conservative results • Ways to make an analysis scalable: – Fairly straightforward for standard compiler analyses – Reduce precision – Type systems: progress + preservation – Request user annotations – Be unsound • Another approach: – Define abstraction – Automatically build sound analyses for that abstraction CS711 Overview 15 CS711 Overview 16 This Course Course Structure • Programming paradigms and constructs: • Read significant/recent papers in the area – 35 minutes paper presentation – Focus on analyses for imperative languages – 25 minutes discussions – Look at: inter-procedural analysis, OO features, pointers, recursive structures, machine code, threads • Background – Dataflow analysis, optimizations (CS412) • Analysis Techniques: – Type systems (CS411, CS611) – Mainly dataflow, AI, type systems, constraint methods • Requirements • Bug-finding tools: – Attend seminars – Read all papers, engage in discussions – Including unsound analyses – Present 1-2 papers, start discussions – Do an implementation project • Automatic generation of static analyses • Or write a survey in a sub-area CS711 Overview 17 CS711 Overview 18 3

A Flavor of Static Analysis Example rotate(tree * t) { • Can an analysis determine that your program tree *x = t->left; builds a tree? (not a DAG or a cyclic graph) t->left = x->right; x->right = t; return x; • Why should I care? } – Program understanding/verification – Can parallelize programs with tree structures • Can the compile automatically prove that this – Check memory safety code preserves the tree shape? How? CS711 Overview 19 CS711 Overview 20 Example Find Bugs rotate(tree * t) { rotate(tree * t) { tree *x = t->left; tree *x = t->left; t->left = x->right; t->left = x->right; x->right = t; x->left left = t; return x; return x; } } • Shape analysis • Change “ x->right ” with “ x->left ” – Uses an abstraction that tracks reference counts • What goes wrong? – Tree if all reference count are equal to 1 CS711 Overview 21 CS711 Overview 22 Materials • Book: “ Principles of Program Analysis ” , by Nielson, Nielson, Hankin, Springer 1999 • Web site http:// www.cs.cornell.edu/courses/cs711 • Next time: Inter-procedural analysis “ Precise Inter-Procedural Dataflow Analysis via Graph Reachability ” by Reps, Horwitz, Sagiv, POPL ’ 95 CS711 Overview 23 4