Approach starts with GEN and KILL sets

Transcription

1 b -Advanced-DFA Review of Data Flow Analysis State Propaga+on Computer Science 5-6 Fall Prof. L. J. Osterweil Material adapted from slides originally prepared by Prof. L. A. Clarke A technique for determining facts at loca+ons on a CFG Can formulate problems in terms of a data flow framework Start with facts that are local Use propaga+on rules to generate increasingly accurate globally true facts. Know that the problem terminates Know that the computa+onal cost is reasonable Usually O(n ) Can usually define the problem so that the results are conserva+ve E.g., No false nega+ves Unfortunately, oxen have false posi+ves Approach starts with GEN and KILL sets For each node i, associate sets GEN(i) items to be added (generated) as concerns KILL(i) - items to be red (killed) as concerns The defini+ons of GEN and KILL depend on the problem that is being solved (the nature of the concern ) OXen the GEN and KILL sets can be derived from the abstract syntax tree E.g., variables defined in a node, DEF(i) variables referenced in a node, REF(i) Essence of Approach is Propaga+on Ini+al concerns GENerated and KILLed locally at each node Global informa+on summarized by OUT sets, ini+ally { IN equa+on (for forward flow analysis) Propaga+on of global data to each node by equa+on of form: IN(n i ) := Merge ( n j that are predecessors, OUT(n j ) ) Merge opera+on Over the {predecessors of n i for a forward- flow problem Merge operator determined by whether it is an all- path or an any- path problem Global summary informa+on in OUT equa+on Usually: OUT := (IN \ KILL) U GEN Using a Worklist Algorithm Essen+ally Depth- First Search But loops are traversed mul+ple +mes Traversals stop when OUT sets don t change Called a fixed point Fixed point reached quickly If only a finite number of possible values can be associated with a node s OUT set E.g. for undefined ref, it is any subset of the set of all variables If the func+on that determines the values is monotonic E.g. the only changes are removal of an element from a set Then the data- flow algorithm eventually terminates Worst case: Every one of N nodes has V variables ini+ally To re one value from one node, all N have to be visited Upper bound is O(N V) Actually very loose bound Page

2 b -Advanced-DFA A More General Conceptualiza+on Variables around the flow graph in different states Start out in undefined state Can transi+on to defined Will the variable encounter a ref while in undefined state? THINK PACMAN? When Pacman is in the right color can it gobble up a token (e.g. an undefined- colored variable token gobbles up a reference)? A More General Conceptualiza+on Variables around the flow graph in different states Start out in undefined state Can transi+on to defined Will the variable encounter a ref while in undefined state? THINK PACMAN? When Pacman is in the right color can it gobble up a token (e.g. an undefined- colored variable token gobbles up a reference)? What about situa+ons where > states is possible? Cecil: Olender and Osterweil User- specified Number of states (depends on property of interest) Transi+ons (driven by specified events ) States that are of interest Represented as a Determinis+c Finite State Automaton (DFSA) Or as a Quan+fied Regular Expression (QRE) Namely a specifica+on of the language accepted by the DFSA QREs can be translated into DFSAs Non determinis+c FSAs can be translated into DFSAs Property: The elevator always s its doors before moving Events:,, Assumes the doors are originally d,, Property: The elevator always s its doors before moving Property: The elevator always s its doors before moving Ini+al state Events:,, Events:,, Assumes the doors are originally d,, Assumes the doors are originally d,, Page

3 b -Advanced-DFA Property: The elevator always s its doors before moving Property: The elevator always s its doors before moving Events:,, Events:,, Accep+ng final states Assumes the doors are originally d,, trap or error state Assumes the doors are originally d,, Iden+fying Where Events Occur in Programs Recognizable events Method calls Can reason about sequences of method calls E.g., Push must be called before Pop Thread interac+ons Join or Fork Opera+ons on variables Define, reference, undefine a+b Need to be able to treat events as indivisible ac+ons E.g., can treat pop and push as atomic as long as they do not contain any events of concern Annotate control flow graph with events Annotate control flow graph with events,, Ini+alizing, Propaga+ng State Informa+on Forward Flow, Any Path Problem IN and OUT are sets of FSA states IN(n) = OUT(m) m pred(n) OUT(n) = δ(s, n) s IN(n) δ is the FSA transi+on func+on Ini+alize OUT(i) =, for all i For the workist algorithm, ini+alize IN()=start state Result: Let f be the final node of the flow graph Define Accept(P) to be the set of accep+ng states of a property, P For an All property: want OUT(f) Accept(P) For a None property: want OUT(f) Accept(P) = In Out Page 3

4 b -Advanced-DFA The Elevator Controller Example void main() { : if (elevatorstopped) {... 3: Doors();... 5: if (elevatorstopped) {... 7: Doors(); 9: ToNextFloor(); 3: 7: : if 5: if 9: Worklist:, 3,5, 7,9 Elevator Controller <> 3: <> <,> 7: <> <> <> : if 5: if 9: <,> <,> Property <,> <,> Elevator Controller Property Worklist: 3, 5, 7,9 <> : if void main() { 3: : if (elevatorstopped) <> {... 3: Doors(); 5: if <,>... 5: if (elevatorstopped) {... 7: Doors(); 7: <> 9: ToNextFloor(); 9: <,> The elevator never s while the doors are This DFSA is a none property A None Example,, Using Quan+fied Regular Expressions State propaga+on Alphabet, quan+fica+on, regular expression For the events {,, show that for all paths (( v )*, ( +, )*)* *,, Data Flow Analysis Problem - > lance (P(S),, ) func+on space δ : P(S) P(S) facts at nodes are elements of P(S) Propagate states un+l convergence and check if terminal node in an accep+ng/non- accep+ng state of DFSA Page 4

5 b -Advanced-DFA Example Meet Semilance {! {! {! {! {,! {,!! {,! values= P({,,)! = {! T = {,,! Ordering =! Meet =! Using Data Flow Analysis to Verify Proper+es Many interes+ng and important proper+es can be represented as FSAs or QREs Can efficiently determine if the property can be violated If it can be violated,can see a trace through the program that causes the viola+on BUT, may not correspond to an executable path {,,! Desiderata Represen+ng proper+es Modeling programs Interpre+ng results Any/All interpreta+on Verifying OO system method invoca+ons For OO systems, can reason about legal sequences of method invoca+ons Example: Must always check before popping a stack For events {pop, push, not_empty show that for all paths ((push)*, (not_empty, (- pop)*, pop)* )* (not_empty, (- pop)*)* push pop -pop not_empty Verifying OO system method invoca+ons For OO systems, can reason about legal sequences of method invoca+ons Example: Must always check before popping a stack For events {pop, push, not_empty show that for all paths ((push)*, (not_empty, (- pop)*, pop)* )* (not_empty, (- pop)*)* Verifying OO system method invoca+ons For OO systems, can reason about legal sequences of method invoca+ons Example: Must always check before popping a stack For events {pop, push, not_empty show that for all paths ((push)*, (not_empty, (- pop)*, pop)* )* (not_empty, (- pop)*)* push pop -pop push pop -pop not_empty Very conserva+ve property. Desirable for safety cri+cal systems not_empty Note: Omised transi+ons go to trap state Page 5

6 b -Advanced-DFA Quan+ta+ve Proper+es Cause Problems Can not represent #Insert > #Delete N deletes, K inserts, N deletes, k inserts, etc. K + K + > N + N + But for fixed N, can show that #inserts #deletes Each delete is immediately preceded by at least one insert For events {insert, delete For all paths (insert*, (insert,delete)*)* delete insert insert insert insert insert insert insert 3 4 delete delete delete delete... delete N insert Interpre+ng Results: When the system can not verify a property Provides a counter example User must decide what is wrong There could be a path through the system that violates the property OR The path that violates the property is not executable OR The property is incorrect State Propaga+on: Any/All paths All paths or no paths determined by how the last node in the graph is treated, not by intersec+on or union States of the property are propagated through the CFG For each node of the CFG, indicate the states of the property that the program could be in at that point in the program An any path problem An all (none) property is proved if only accep+ng (non- accep+ng) states are contained in the final node of the CFG,, Dealing with methods Dealing with methods If is a method call and it contains a, then must inline the code for If is a method call and it contains a, then must inline the code for CFG for CFG for Page 6

7 b -Advanced-DFA event/node simplifies analysis, Can reduce the CFG before doing the analysis Can re a node from the graph if it does not have an event associated with it, AND does not affect the flow of events through the graph Interprocedural Analysis- in- line reduced CFG CFG for Inline methods with events A summarized representation of (and everything that it calls) CFG for If does not call or, do not need to inline its code Advantages of State Propaga+on Data Flow Analysis determines if the property is valid or not Efficient Always terminates Conserva+ve Only validates the property if it is true for all/no possible execu+ons When it can not validate the property, it provides a counter example trace Rela+vely easy to use Do not have to understand how the system works Rela+vely easy to write proper+es Compared to predicate calculus or temporal logic Disadvantages of State Propaga+on Infeasible paths Can not usually express proper+es about compound data values E.g., For all I, A[ I ] > A[I+] Can not express general ordering rela+onships # Insert > # Delete But, can ensure that every delete is preceded by at least one insert Or, can ensure # Insert > # Delete, for some specific n Page 7

8 b -Advanced-DFA Associated support Support for elimina+ng infeasible paths Some systems apply symbolic execu+on Some+mes combined with a theorem prover Support for visualizing counter example traces Support for represen+ng proper+es Summary: Using Data Flow Analysis to Verify Proper+es Many interes+ng and important proper+es can be represented as DFSA or regular expressions Can efficiently determine if the property can be violated If it can be violated,can see a trace through the program that causes the viola+on May not correspond to an executable path For OO systems, works well for reasoning about legal sequences of method invoca+ons Page 8