Patrick Cousot_Abstract Interpretation Based Formal Methods and Future Challenges

Patrick Cousot_Abstract Interpretation Based Formal Methods and Future Challenges

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Abstract Interpretation Based Formal Methods and Future Challenges Patrick Cousot École normale supérieure, Département d’informatique, 45 rue d’Ulm, 75230 Paris cedex 05, France˜cousot/ Abstract. In order to contribute to the solution of the software reliabil­ ity problem, tools have been designed to analyze statically the run-time behavior of programs. Because the correctness problem is undecidable, some form of approximation is needed. The purpose of abstract interpre­ tation is to formalize this idea of approximation. We illustrate informally the application of abstraction to the semantics of programming languages as well as to static program analysis. The main point is that in order to reason or compute about a complex system, some information must be lost, that is the observation of executions must be either partial or at a high level of abstraction. A few challenges for static program analysis by abstract interpretation are finally briefly discussed. The electronic version of this paper includes a comparison with other formal methods: typing , model-checking and deductive methods. 1 Introductory Motivations The evolution of hardware by a factor of 106 over the past 25 years has lead to the explosion of the size of programs in similar proportions. The scope of application of very large programs (from 1 to 40 millions of lines) is likely to widen rapidly in the next decade. Such big programs will have to be designed at a reasonable cost and then modified and maintained during their lifetime (which is often over 20 years). The size and efficiency of the programming and maintenance teams in charge of their design and follow-up cannot grow in similar proportions. At a not so uncommon (and often optimistic) rate of one bug per thousand lines such huge programs might rapidly become hardly manageable in particular for safety critical systems. Therefore in the next 10 years, the software reliability problem is likely to become a major concern and challenge to modern highly computer-dependent societies. In the past decade a lot of progress has been made both on thinking/methodological tools (to enhance the human intellectual ability) to cope with complex software systems and mechanical tools (using the computer) to help the pro­ grammer to reason about programs. Mechanical tools for computer aided program verification started by execut­ ing or simulating the program in as much as possible environments. However 132 Patrick Cousot debugging of compiled code or simulation of a model of the source program hardly scale up and often offer a low coverage of dynamic program behavior. Formal program verification methods attempt to mechanically prove that program execution is correct in all specified environments. This includes deduc­ tive methods, model checking, program typing and static program analysis. Since program verification is undecidable, computer aided program verifica­ tion methods are all partial or incomplete. The undecidability or complexity is always solved by using some form of approximation. This means that the me­ chanical tool will sometimes suffer from practical time and space complexity limitations, rely on finiteness hypotheses or provide only semi-algorithms, re­ quire user interaction or be able to consider restricted forms of specifications or programs only. The mechanical program verification tools are all quite similar and essentially differ in their choices regarding the approximations which have to be done in order to cope with undecidability or complexity. The purpose of abstract interpretation is to formalize this notion of approximation in a unified framework (10; 17). 2 Abstract Interpretation Since program verification deals with properties, that is sets (of objects with these properties), abstract interpretation can be formulated in an application independent setting, as a theory for approximating sets and set operations as considered in set (or category) theory, including inductive definitions (25). A more restricted understanding of abstract interpretation is to view it as a theory of approximation of the behavior of dynamic discrete systems (e.g. the formal semantics of programs or a communication protocol specification). Since such behaviors can be characterized by fixpoints (e.g. corresponding to iteration), an essential part of the theory provides constructive and effective methods for fixpoint approximation and checking by abstraction (19; 23). 2.1 Fixpoint Semantics The semantics of a programming language defines the semantics of any program written in this language. The semantics of a program provides a formal math­ ematical model of all possible behaviors of a computer system executing this program in interaction with any possible environment. In the following we will try to explain informally why the semantics of a program can be defined as the solution of a fixpoint equation. Then, in order to compare semantics, we will show that all the semantics of a program can be organized in a hierarchy by ab­ straction. By observing computations at different levels of abstraction, one can approximate fixpoints hence organize the semantics of a program in a lattice (15). 2.2 Trace Semantics Our finer grain of observation of program execution, that is the most pre­ Abstract Interpretation Based Formal Methods and Future Challenges 133 Initial states cise of the semantics that Final states of the Intermediate states we will consider, is that of finite traces abc d a trace semantics (15; 19). An execution of a program e f Infinite for a given specific interac­ traces g h tion with its environment x j i is a sequence of states, ob­ k served at discrete intervals of time, starting from an 0123456789 discrete time initial state, then moving from one state to the next Fig. 1. Examples of Computation Traces state by executing an atomic program step or transition and either ending in a final regular or erroneous state or non terminating, in which case the trace is infinite (see Fig. 1). 2.3 Least Fixpoint Trace Semantics Introducing the computational partial ordering (15), we define the trace seman­ tics in fixpoint form (15), as the least solution of an equation of the form X = F (X ) where X ranges over sets of finite and infinite traces. More precisely, let Behaviors be the set of execution traces of a program, possibly starting in any state. We denote by Behaviors+ the subset of finite traces and by Behaviors∞ the subset of infinite traces. a z . • A finite trace •−−− . .−−− in Behaviors+ is either reduced to a final state (in which case there is no possible transition from state • = •) or the initial state a a b • is not final and the trace consists of a first computation step •−−− after which, • b from the intermediate state • , the execution goes on with the shorter finite trace b a z •−−−. . .−−−• ending in the final state •. The finite traces are therefore all well defined by induction on their length. a . . An infinite trace •−−− . .−−− . . in Behaviors∞ starts with a first computa­ a b b z z tion step •−−−• after which, from the intermediate state • , the execution goes b on with an infinite trace •−−−. . .−−−. . . starting from the intermediate state b •. These remarks and Behaviors = Behaviors+ ∪ Behaviors∞ lead to the following fixpoint equation: Behaviors = {• | • is a final state} ∪ {•−−− •−−− . .−−− | •−−− is an elementary step & . • • z b •−−− . .−−− ∈ Behaviors+ } . • •−−− . .−−− . . | •−−− is an elementary step & . . • ∪ {•−−− b a b a b a b z a b aa •−−− . .−−− . . ∈ Behaviors∞ } . . In general, the equation has multiple solutions. For example if there is only one a a a non-final state • and only possible elementary step •−−−• then the equation is 134 Patrick Cousot a a a Behaviors = {•−−− •−−− . .−− . . | •−−− . .−−− . . ∈ Behaviors}. One solution . . . . a a a a •−−− •−−− •−−− . .−−− . .} but another one is the empty set ∅. Therefore, . . is {•−−− we choose the least solution for the computational partial ordering (15): « More finite traces & less infinite traces » . 2.4 Abstractions & Abstract Domains A programming language semantics is more or less precise according to the considered observation level of program execution. This intuitive idea can be formalized by Abstract interpretation (15) and applied to different languages , including for proof methods. The theory of abstract interpretation formalizes this notion of approximation and abstraction in a mathematical setting which is independent of particular applications. In particular, abstractions must be provided for all mathemati­ cal constructions used in semantic definitions of programming and specification languages (19; 23). An abstract domain is an abstraction of the concrete semantics in the form of abstract properties (approximating the concrete properties Behaviors) and abstract operations (including abstractions of the concrete approximation and computational partial orderings, an approximation of the concrete fixpoint trans­ former F , etc.). Abstract domains for complex approximations of designed by composing abstract domains for simpler components (19), see Sec. 2.10. If the approximation is coarse enough, the abstraction of a concrete seman­ tics can lead to an abstract semantics which is less precise, but is effectively computable by a computer. By effective computation of the abstract semantics, the computer is able to analyze the behavior of programs and of software before and without executing them (16). Abstract interpretation algorithms provide ap­ proximate methods for computing this abstract semantics. The most important algorithms in abstract interpretation are those providing effective methods for the exact or approximate iterative resolution of fixpoint equations (17). We will first illustrate formal and effective abstractions for sets. Then we will show that such abstractions can be lifted to functions and finally to fixpoints. The abstraction idea and its formalization are equally applicable in other ar­ eas of computer science such as artificial intelligence e.g. for intelligent planning, proof checking, automated deduction, theorem proving, etc. 2.5 Hierarchy of Abstractions As shown in Fig. 2 (from (15), where Behaviors , denoted τ ∞ for short, is the lattice infimum), all abstractions of a semantics can be organized in a lattice (which is part of the lattice of abstract interpretations introduced in (19)). The approximation partial ordering of this lattice formally corresponds to logical im­ plication, intuitively to the idea that one semantics is more precise than another one. Abstract Interpretation Based Formal Methods and Future Challenges Hoare pH s ❍ ❍❍ logics τ 135 τ s s weakest wlp ❍ ✯ ✟ ✟ τ wp ❍ precondition τ ❍❍✟✟ s semantics τ gwp sτ s denotational ✣✯ ✡ ✟s ❍ ✡✟τ τ ❍❍ semantics ✟ relational semantics trace semantics s ✯ ✟ ✟ τ tH ✟ ❍s ✟ gH sτ sSs s τ τ EM ! D τ+ ✯ ✟ τ? s✟ ✶ ✏s ω s ❍ ❍ ✶s ✏✏ τ ✏✏τ ∂ ✻ τ ✻❍ ✏ ❍s ✏ ∞ ❍✟ ✡ s sτ τ♦ τ s τ+ τ✻ ω s transition ✿ ✶sτ s ❍ ❍❍ ✏✏✘✘ τ semantics ✏✘✘ ✏✘ ❍✘✘ s ✏ ✲ abstraction τ∞ angelic natural demoniac deterministic infinite equivalence restriction Fig. 2. The Hierarchy of Semantics Fig. 3 illustrates the derivation of a relational semantics (denoted τ ∞ in Fig. 2) from a trace semantics (denoted τ ∞ in Fig. 2). The abstraction αr from trace a z to relational semantics consists in replacing the finite traces •−−− . .−−− by the . • a b •−−− . .−−− . . . . pair a, z of the initial and final states. The infinite traces •−−− are replaced by the pair a, ⊥ where the symbol ⊥ denotes non-termination. Therefore the abstraction is: . • •−−− . .−−− . . ∈ X } . . . αr (X ) = { a, z | •−−− . .−−− ∈ X } ∪ { a, ⊥ | •−−− The denotational semantics (denoted τ in Fig. 2) is the isomorphic representa­ tion of a relation by its right-image: αd (R) = λ a · {x | a, x ∈ R}. The abstraction from relational to big-step operational or natural seman­ tics (denoted τ + in Fig. 2) simply consists in forgetting everything about nontermination, so αn (R) = { a, x ∈ R | x = ⊥} , as illustrated in Fig. 3. A non comparable abstraction consists in collecting the set of initial and final states as well as all transitions x,y appearing along some finite or infinite trace •−−− . . •−−− . . . of the trace semantics. One gets the small-step operational or . • transition semantics (denoted τ in Fig. 2 and also called Kripke structure in modal logic) as illustrated in Fig. 4. A further abstraction consists in collecting all states appearing along some finite or infinite trace as illustrated in Fig. 5. This is the partial correctness semantics or the static /collecting semantics for proving invariance properties of programs. a x y a z a b 136 Patrick Cousot Initial states Intermediate states abc d e Initial states Final states ad ad ef Infinite α α traces ef gh ij g h ij k⊥ ⊥ 0123456789 discrete time x x x Final states of finite traces f h j § x g i k Trace semantics Relational semantics Natural semantics Fig. 3. Abstraction from Trace to Relational and Natural Semantics Initial states a ab e e g g i k i k Transitions bc d f h j Final states d f h j Fig. 4. Transition Semantics All abstractions considered in this paper are “from above” so that the ab­ stract semantics describes a superset or logical consequence of the concrete semantics. Abstractions “from below” are dual and consider a subset of the concrete semantics. An example of approximation “from below” is provided by debugging techniques which consider a subset of the possible program executions or by existential checking where one wants to prove the existence of an execu­ tion trace prefix fulfilling some given specification. In order to avoid repeating two times dual concepts and as we do usually, we only consider approximations “from above”, knowing that approximations “from below” can be easily derived by applying the duality principle (as found e.g. in lattice theory). 2.6 Effective Abstractions Numerical Abstractions Assume that a program has two integer variables X and Y. The trace semantics of the program (Fig. 1) can be abstracted in the static/collecting semantics (Fig. 5). A further abstraction consists in forgetting in a state all but the values x and y of variables X and Y. In this way the trace semantics is abstracted to a set of points (pairs of values), as illustrated in the plane by Fig. 6(a). Abstract Interpretation Based Formal Methods and Future Challenges 137 x x x § x Initial states abc a e e g g i i k k Reachable states d f h j Final states d f h j Fig. 5. Static / Collecting / Partial Correctness Semantics y {. . . , 5, 7 , . . . , 13, 21 , . . .} x y x≥0 y≥0 x (a) [In]finite Set of Points (b) Sign Abstraction y x ∈ [3, 27] y ∈ [4, 32] y x = 5 mod 8 y = 7 mod 9 x x (c) Interval Abstraction (d) Simple Congruence Ab­ straction Fig. 6. Non-relational Abstractions We now illustrate informally a number of effective abstractions of an [in]finite set of points. Non-relational Abstractions The non-relational, attribute independent or cartesian abstractions (19 , example consists in ignoring the possible relationships between the values of the X and Y variables. So a set of pairs is approximated through projection by a pair of sets. Each such set may still be infinite and in general not exactly computer representable. Further abstractions are therefore needed. The sign abstraction (19) illustrated in Fig. 6(b) consists in replacing integers by their sign thus ignoring their absolute value. The interval abstraction (16) illustrated in Fig. 6(c) is more precise since it approximates a set of integers by 138 Patrick Cousot x x x § x y 3 ≤ x ≤ 7 x+y ≤ 8 4 ≤ y ≤ 5 x−y ≤ 9 x y 7x + 3y ≤ 5 2x + 7y ≥ 0 x (a) Octagonal Abstraction (b) Polyhedral Abstraction y 3x + 5y = 8 mod 7 2x − 9y = 3 mod 5 y 3x + 7y ∈ [2, 7] mod 8 2x − 5y ∈ [0, 9] mod 4 x x (c) Relational Congruence Abstrac­ tion (d) Trapezoidal Congruence Abstrac­ tion Fig. 7. Relational Abstractions it minimal and maximal values (including −∞ and +∞ as well as the empty set if necessary). The congruence abstraction (38) (generalizing the parity abstraction (19)) is not comparable, as illustrated in Fig. 6(d). Relational Abstractions Relational abstractions are more precise than non relational ones in that some of the relationships between values of the program states are preserved by the abstraction. For example the polyhedral abstraction (31) illustrated in Fig. 7(b) approxi­ mates a set of integers by its convex hull. Only non-linear relationships between the values of the program variables are forgotten. The use of an octagonal abstraction illustrated in Fig. 7(a) is less precise since only some shapes of polyhedra are retained or equivalently only linear relations between any two variables are considered with coefficients +1 or -1 (of the form ±x ± y ≤ c where c is an integer constant). A non comparable relational abstraction is the linear congruence abstraction (39) illustrated in Fig. 7(c). A combination of non-relational dense approximations (like intervals) and relational sparse approximations (like congruences) is the trapezoidal linear con­ gruence abstraction (48) as illustrated in Fig. 7(d). Symbolic Abstractions Most structures manipulated by programs are sym­ bolic structures such as control structures (call graphs), data structures (search Abstract Interpretation Based Formal Methods and Future Challenges 139 x x x §y x x y y x x (a) yes (b) unkown (c) yes Fig. 8. Is 1/(X+1-Y) well-defined? trees, pointers (33; 34; 54; 58)), communication structures (distributed & mobile programs (36; 41; 57)), etc. It is very difficult to find compact and expressive abstractions of such sets of objects (sets of languages, sets of automata, sets of trees or graphs, etc.). For example Büchi automata or automata on trees are very expressive but algorithmically expensive. A compromise between semantic expressivity and algorithmic efficiency was recently introduced by (49) using Binary Decision Graphs and Tree Schemata to abstract infinite sets of infinite trees. 2.7 Information Loss Any abstraction introduces some loss of information. For example the abstrac­ tion of the trace semantics into relational or denotational semantics loses all information on the computation cost since all intermediate steps in the execu­ tion are removed. All answers given by the abstract semantics are always correct with respect to the concrete semantics. For example, if termination is proved using the relational semantics then there is no execution abstracted to a, ⊥ , so there is no infinite a b trace •−−−•−−−. . .−−−. . . in the trace semantics, whence non termination is impossible when starting execution in initial state a. However, because of the information loss, not all questions can be definitely answered with the abstract semantics. For example, the natural semantics can­ not answer questions about termination as can be done with the relational or denotational semantics. These semantics cannot answer questions about con­ crete computation costs. The more concrete is the semantics, the more questions it can answer. The more abstract semantics are simpler. Non comparable abstract semantics (such as intervals and congruences) answer non comparable sets of questions. To illustrate the loss of information, let us consider the problem of deciding whether the operation 1/(X+1-Y) appearing in a program is always well defined at run-time. The answer can certainly be given by the concrete semantics since it has no point on the line x + 1 − y = 0 , as shown in Fig. 8(a). 140 Patrick Cousot In practice the concrete abstraction is not computable so it is hardly usable in a useful effective tool. The dense abstractions that we have considered are too approximate as is illustrated in Fig. 8(b). However the answer is positive when using the relational congruence abstrac­ tion, as shown in Fig. 8(c). 2.8 Function Abstraction We now show how the abstraction of complex mathematical objects used in the semantics of programming or specification languages can be defined by compos­ ing abstractions of simpler mathematical structures. For example knowing abstractions of the Abstract domain parameter and result of a monotonic function F on sets, a function F can be abstracted into an abstract function F as illustrated in Fig. 9 (19). Mathematically, F takes its parame­ α ter x in the abstract domain. Let γ (x) be the corresponding concrete set (γ is the adjoined, x F intuitively the inverse of the abstraction func­ tion α). The function F can be applied to get Concrete domain the concrete result ◦ F ◦ γ (x). The abstraction function α can then be applied to approximate F =α◦F ◦γ the result F (x) = α ◦ F ◦ γ (x). In general, neither F , α nor γ are computable Fig. 9. Function Abstraction even though the abstraction α may be effective. So we have got a formal specification of the abstract function F and an algo­ rithm has to be found for an effective implementation. 2.9 Fixpoint Abstraction A fixpoint of a function F can often be obtained as the limit of the iterations of F from a given initial value ⊥. In this case the abstraction of the fixpoint can often be obtained as the abstract limit of the iteration of the abstraction F of F starting from the abstraction α(⊥) of the initial value ⊥. The basic result is that the concretization of the abstract fixpoint is related to the concrete fixpoint by the approximation relation expressing the soundness of the abstraction (19). This is illustrated in Fig. 10. Often states have some finite component (e.g. a program counter) which can be used to partition into fixpoint system of equations by projection along that component. Then chaotic (18) and asynchronous iteration strategies (10) can be used to solve the equations iteratively. Various efficient iteration strategies have been studied , including ones taking particular properties of abstractions into account and others to speed up the convergence of the iterates (24). Abstract Interpretation Based Formal Methods and Future Challenges 141 x x x § § ⊥ Abstract domain F F F α α F α F F α α F Approximation relation F F ⊥ F F F F F F F Concrete domain γ (lfp F ) Fig. 10. Fixpoint Abstraction lfp F 2.10 Composing Abstractions Abstractions hence abstract interpreters for static program analysis can be de­ signed compositionally by stepwise abstraction, combination or refinement (37; 13). An example of stepwise abstraction is the functional abstraction of Sec. 2.8. The abstraction of a function is parameterized by abstractions for the function parameters and the function result which can be chosen later in the modular design of the abstract interpreter. An example of abstraction combination is the reduced product of two abstrac­ tions (19) which is the most abstract abstraction more precise than these two abstractions or the reduce cardinal power (19) generalizing case analysis. Such combination of abstract domains can be implemented as parameterized modules in static analyzer generators (e.g. (46)) so as to partially automate the design of expressive analyses from simpler ones. An example of refinement is the disjunctive completion (19) which completes an abstract domain by adding concrete disjunctions missing in the abstract domain. Another example of abstract domain refinement is the complementation (8) adding concrete negations missing in the abstract domain. 2.11 Sound and Complete Abstractions Abstract interpretation theory has mainly been concerned with the soundness of the abstract semantics/interpreter, relative to which questions can be answered correctly despite the loss of information (17). Soundness is essential in practice and leads to a formal design method (19). However completeness , relative to the formalization of the loss of information in a controlled way so as to answer a given set of questions, has also been intensively studied (19; 37), including in the context of model checking (14). In practice complete abstractions, including a most abstract one, always exist to check that a given program semantics satisfies a given specification. 142 Patrick Cousot Moreover any given abstraction can be refined to a complete one. Nevertheless this approach has severe practical limitations since, in general, the design of such complete abstractions or the refinement of a given one is logically equiva­ lent to the design of an inductive argument for the formal proof that the given program satisfies the given specification, while the soundness proof of this ab­ straction logically amounts to checking the inductive verification conditions or proof obligations of this formal proof (14). Such proofs can hardly be fully auto­ mated hence human interaction is unavoidable. Moreover the whole process has to be repeated each time the program or specification is modified. Instead of considering such strong specifications for a given specific program, the objective of static program analysis is to consider (often predefined) spec­ ifications and all possible programs. The practical problem in static program analysis is therefore to design useful abstractions which are computable for all programs and expressive enough to yield interesting information for most pro­ grams. 3 Static Program Analysis Static program analysis is the automatic static determination of dynamic runtime properties of programs. 3.1 Foundational Ideas of Static Program Analysis Specification Program Given a program and a specification, a pro­ gram analyzer will check if the program seman­ tics satisfies the specification (Fig. 11). In case Program analyzer of failure, the analyzer will provide hints to un­ derstand the origin of errors (e.g. by a backward x analysis providing necessary conditions to be sat­ Diagnosis isfied by counter-examples). The principle of the analysis is to compute an approximate semantics of the program in order Fig. 11. Program Analysis to check a given specification. Abstract interpretation is used to derive, from a standard semantics, the approximate and computable abstract semantics. The derivation can often be done by composing standard abstractions to fit a partic­ ular kind of information which has to be discovered about program execution. This derivation is itself not (fully) mechanizable but static analyzer generators such as PAG (47) and others can provide generic abstractions to be composed with problem specific ones. In practice, the program analyzer contains a generator reading the pro­ gram text and producing equations or constraints whose solution is a com­ puter representation of the program abstract semantics. A solver is then used to solve these abstract equations/constraints. A popular resolution method is to use iteration. Of the numerical abstractions considered in Sec. 2.6 , only the sign and simple congruence abstractions ensure the finite convergence of Abstract Interpretation Based Formal Methods and Future Challenges 143 the iterates. If the limit of the iterates is inexistent (which may be the case e.g. for the polyhedral abstraction) or it is reached after infinitely many it­ eration steps (e.g. interval and octagonal abstractions), the convergence may have to be ensured and/or accelerated using a widening to over estimate the solution in finitely many steps followed by a narrowing to improve it (10; 17; 24). In abstract compilation, the gen­ Specification Program erator and solver are directly com­ piled into a program which directly Generator yields the approximate solution. System of fixpoint equations/constraints This solution is an approxima­ tion of the abstract semantics which Solver is then used by a diagnoser to check x (Approximate) solution the specification. Because of the loss Program of information, the diagnosis is al­ Diagnoser analyzer ways of the form “yes ”, “no ”, “un­ known ” or “irrelevant ” (e.g. a safety Diagnosis specification for unreachable code). The general structure of program an­ alyzers is illustrated in Fig. 12. Be­ Fig. 12. Principle of Program Analysis sides diagnosis, static program analysis is also used for other applications in which case the diagnoser is replaced by an optimiser (for compile-time opti­ mization), a program transformer (for partial evaluation (44)), etc. 3.2 Shortcomings of Static Program Analysis Static program analysis can be used for large programs (e.g. 220,000 lines of C) without user interaction. The abstractions are chosen to be of wide scope with­ out specialization to a particular program. Abstract algebras can be designed and implemented into libraries which are reusable for different programming languages. The objective is to discover invariants that are likely to appear in many programs so that the abstraction must be widely reusable for the program analyzer to be of economic interest. The drawback of this general scope is that the considered abstract specifi­ cations and properties are often simple, mainly concerning elementary safety properties such as absence of run-time errors. For example non-linear abstrac­ tions of sets of points are very difficult and very few mathematical results are of practical interest and directly applicable to program analysis. Checking termi­ nation and similar liveness properties is trivial with finite state systems, at least from a theoretical if not algorithmic point of view (e.g. finding loops in finite graphs). The same problem is much more difficult for infinite state systems be­ cause of fairness (49) or of potentially infinite data structures (as considered e.g. in partial evaluation) which do not amount to finite cycles so that termination or inevitability proofs require the discovery of variant functions on well-founded sets which is very difficult in full generality. 144 Patrick Cousot Even when considering restricted simple abstract properties, the semantics of real-life programming languages is very complex (recursion, concurrency, modu­ larity, etc.) whence so is the corresponding abstract interpreter. The abstraction of this semantics, hence the design of the analyzer is mostly manual (and beyond the ability of casual programmers or theorem provers) whence costly. The con­ sidered abstractions must have a large scope of application and must be easily reusable to be of economic interest. From a user point of view, the results of the analysis have to be presented in a simple way (for example by pointing at errors only or by providing abstract counter-examples, or less frequently concrete ones). Experience shows that the cases of uncertainty represent 5 to 10 % of the possible cases. They must be handled with other empirical or formal methods (including more refined abstract interpretations). 3.3 Applications of Static Program Analysis Among the numerous applications of static program analysis, let us cite data flow analysis (53; 28); program optimization and transformation (including par­ tial evaluation and program specialization (44) and data dependence analy­ sis for the parallelisation of sequential languages); set-based analysis (27); type inference (12) (including undecidable systems and soft typing); verification of reactive (40; 43), real-time and (linear) hybrid systems including state space re­ duction; cryptographic protocol analysis; abstract model-checking of infinite sys­ tems (28); abstract debugging, testing and verification ; cache and pipeline behav­ ior prediction (35); probabilistic analysis (50); communication topology analysis for mobile/distributed code (36; 41; 57); automatic differentiation of numeri­ cal programs; abstract simulation of temporal specifications; Semantic tattoo­ ing/watermarking of software (30); etc. Static program analysis has been intensively studied for a variety of pro­ gramming languages including procedural languages (e.g. for alias and pointer analysis (33; 34; 54; 58)), functional languages (e.g. for binding time (56), strict­ ness (4; 51) and comportment analysis (26), exception analysis (59)), parallel functional languages, data parallel languages, logic languages including Prolog (1; 22; 32) (e.g. for groundness (9), sharing (7), freeness (5) and their combina­ tions (6), parallelizatiion (3), etc.), database programming languages, concurrent logic languages, functional logic languages, constraint logic languages, concur­ rent constraint logic languages, specification languages, synchronous languages, procedural/functional concurrent/parallel languages (21), communicating and distributed languages (20) and more recently object-oriented languages (2; 55). Abstract interpretation based static program analyses have been used for the static analysis of the embedded ADA software of the Ariane 5 launcher1 and the ARD2 (45). The static program analyser aims at the automatic detection of 1 2 Flight software (60,000 lines of Ada code) and Inertial Measurement Unit (30,000 lines of Ada code). Atmospheric Reentry Demonstrator. Abstract Interpretation Based Formal Methods and Future Challenges 145 the definiteness , potentiality , impossibility or inaccessibility of run-time errors such as scalar and floating-point overflows, array index errors, divisions by zero and related arithmetic exceptions, uninitialized variables, data races on shared data structures, etc. The analyzer was able to automatically discover the Ariane 501 flight error. The static analysis of embedded safety critical software (such as avionic software (52)) is very promising (29). 3.4 Industrialization of Static Analysis by Abstract Interpretation The impressive results obtained by the static analysis of real-life embedded critical software (45; 52) is quite promising for the industrialization of abstract interpretation. This is the explicit objective of AbsInt Angewandte Informatik GmbH created in Germany by R. Wilhelm and C. Ferdinand in 1998 commercial­ izing the program analyzer generator PAG and an application to determine the worst-case execution time for modern computer architectures with memory caches, pipelines, etc (35). was created in France by A. Deutsch and D. Polyspace Technologies Pilaud in 1999 to develop and commercialize ADA and C program analyzers. created in Other companies like Connected Components Corporation the U.S.A. by W.L. Harrison in 1993 use abstract interpretation internally e.g. for compiler design (42). 4 Grand Challenge for the Next Decade We believe that in the next decade the software industry will certainly have to face its responsibility imposed by a computer-dependent society, in particular for safety critical systems. Consequently, Software reliability 3 will be a grand challenge for computer science and practice. The grand challenge for formal methods, in particular abstract interpretation based formal tools, is both the large scale industrialization and the intensifica­ tion of the fundamental research effort. General-purpose, expressive and cost-effective abstractions have to be devel­ oped e.g. to handle floating point numbers, data dependences (e.g. for paralleliza­ tion), liveness properties with fairness (to extend finite-state model-checking to software), timing properties for embedded software, probabilistic properties, etc. Present-day tools will have to be enhanced to handle higher-order compositional modular analyses and to cope with new programming paradigms involving com­ plex data and control concepts (such as objects, concurrent threads, distrib­ uted/mobile programming, etc.), to automatically combine and locally refine abstractions in particular to cope with “unknow” answers, to interact nicely with users and other formal or informal methods. 3 other suggestions were “trustworthiness” (C. Jones) and “robustness” (R. Leino). 146 Patrick Cousot The most challenging objective might be to integrate formal analysis by abstract interpretation in the full software development process, from the initial specifications to the ultimate program development. Acknowledgements I thank Radhia Cousot and Reinhard Wilhelm for their comments on a preliminary version of this paper. This work was supported by the daedalus (29) and tuamotu (30) projects. References [1] R. Barbuti, R. Giacobazzi, and G. Levi. A general framework for se­ mantics-based bottom-up abstract interpretation of logic programs. TOPLAS , 15(1):133–181, Jan. 1993. [2] B. Blanchet. Escape analysis for object-oriented languages: Application to Java. In Proc. ACM SIGPLAN Conf. OOPSLA ’99. ACM SIGPLAN Not. 34(10) , pages 20–34, Denver, CO, US, 1–5 Nov. 1999. [3] F. Bueno, M.J. García de la Banda, and M.V. Hermenegildo. Effectiveness of abstract interpretation in automatic parallelization: A case study in logic programming. TOPLAS , 21(2):189–239, Mar. 1999. [4] G.L. Burn, C.L. Hankin, and S. Abramsky. Strictness analysis of higher-order functions. Sci. Comput. Programming, 7:249–278, Nov. 1986. [5] M. Codish, D. Dams, G. Filè , and M. Bruynooghe. Freeness analysis for logic programs – and correctness? In D.S. Warren, editor, Proc. 10th ICLP ’93 , Budapest, HU, pages 116–131. MIT Press, 21–25 June 1993. [6] M. Codish, H. Søndergaard, and P.J. Stuckey. Sharing and groundness de­ pendencies in logic programs. TOPLAS , 21(5):948–976, Sep. 1999. [7] A. Cortesi and G. Filé. Sharing is optimal. J. Logic Programming, 38(3):371–386, 1999. [8] A. Cortesi, G. Filé, R. Giacobazzi, C. Palamidessi, and F. Ranzato. Comple­ mentation in abstract interpretation. TOPLAS , 19(1):7–47, Jan. 1997. [9] A. Cortesi, G. Filé , and W.H. Winsborough. Optimal groundness analysis using propositional logic. J. Logic Programming , 27(2):137–167, 1996. [10] P. Cousot. Méthodes itératives de construction et d’approximation de points fixes d’opérateurs monotones sur un treillis, analyse sémantique de programmes. Thèse d’ État ès sciences mathématiques, Université scientifique et médicale de Grenoble, Grenoble, FR, 21 Mar. 1978. [11] P. Cousot. Constructive design of a hierarchy of semantics of a transition system by abstract interpretation. ENTCS , 6, 1997. , 25 pages. [12] P. Cousot. Types as abstract interpretations, invited paper. In 24th POPL , pages 316–331, Paris, FR, Jan. 1997. ACM Press. [13] P. Cousot. The calculational design of a generic abstract interpreter. In M. Broy and R. Steinbrüggen, editors, Calculational System Design, vol­ ume 173, pages 421–505. NATO Science Series, Series F: Computer and Systems Sciences. IOS Press, 1999. [14] P. Cousot. Partial completeness of abstract fixpoint checking, invited pa­ per. In B.Y. Choueiry and T. Walsh, editors, Proc. 4th Int. Symp. SARA ’2000 , Horseshoe Bay, TX, US, LNAI 1864, pages 1–25. SpringerVerlag, 26–29 Jul. 2000. 148 Patrick Cousot [15] P. Cousot. Constructive design of a hierarchy of semantics of a transition system by abstract interpretation. Theoret. Comput. Sci. , To appear (Preliminary version in (11)). [16] P. Cousot and R. Cousot. Static determination of dynamic properties of pro­ grams. In Proc. 2nd Int. Symp. on Programming, pages 106–130. Dunod, 1976. [17] P. Cousot and R. Cousot. Abstract interpretation: a unified lattice model for static analysis of programs by construction or approximation of fixpoints. In 4th POPL , pages 238–252, Los Angeles, CA, 1977. ACM Press. [18] P. Cousot and R. Cousot. Automatic synthesis of optimal invariant asser­ tions: mathematical foundations. In ACM Symposium on Artificial In­ telligence & Programming Languages, Rochester, NY, ACM SIGPLAN Not. 12(8):1–12, 1977. [19] P. Cousot and R. Cousot. Systematic design of program analysis frame­ works. In 6th POPL , pages 269–282, San Antonio, TX, 1979. ACM Press. [20] P. Cousot and R. Cousot. Semantic analysis of communicating sequential processes. In J.W. de Bakker and J. van Leeuwen, editors, 7th ICALP , LNCS 85, pages 119–133. Springer-Verlag, Jul. 1980. [21] P. Cousot and R. Cousot. Invariance proof methods and analysis techniques for parallel programs. In A.W. Biermann, G. Guiho, and Y. Kodratoff, editors, Automatic Program Construction Techniques , chapter 12, pages 243–271. Macmillan, 1984. [22] P. Cousot and R. Cousot. Abstract interpretation and application to logic programs. J. Logic Programming , 13(2–3):103–179, 1992. (The editor of J. Logic Programming has mistakenly published the unreadable galley proof. For a correct version of this paper, see˜cousot .). [23] P. Cousot and R. Cousot. Abstract interpretation frameworks. J. Logic and Comp. , 2(4):511–547, Aug. 1992. [24] P. Cousot and R. Cousot. Comparing the Galois connection and widen­ ing/narrowing approaches to abstract interpretation, invited paper. In M. Bruynooghe and M. Wirsing, editors, Proc. 4th Int. Symp. PLILP ’92 , Leuven, BE, 26–28 Aug. 1992, LNCS 631, pages 269–295. Springer-Verlag, 1992. [25] P. Cousot and R. Cousot. Inductive definitions, semantics and abstract in­ terpretation. In 19th POPL , pages 83–94, Albuquerque, NM, 1992. ACM Press. [26] P. Cousot and R. Cousot. Higher-order abstract interpretation (and ap­ plication to comportment analysis generalizing strictness, termination, projection and PER analysis of functional languages), invited paper. In Proc. 1994 ICCL , pages 95–112, Toulouse, FR, 16–19 May 1994. IEEE Comp. Soc. Press. [27] P. Cousot and R. Cousot. Formal language, grammar and set-constraintbased program analysis by abstract interpretation. In Proc. 7th FPCA , pages 170–181, La Jolla, CA, 25–28 June 1995. ACM Press. Abstract Interpretation Based Formal Methods and Future Challenges 149 [28] P. Cousot and R. Cousot. Temporal abstract interpretation. In 27th POPL , pages 12–25, Boston, MA, Jan. 2000. ACM Press. [29] P. Cousot, R. Cousot, A. Deutsch, C. Ferdinand, É. Goubault, N. Jones, D. Pilaud, F. Randimbivololona, M. Sagiv, H. Seidel, and R. Wilhelm. DAEDALUS: Validation of critical software by static analysis and ab­ stract testing. Project IST-1999-20527 of the european 5th Framework Programme (FP5), Oct. 2000 – Oct. 2002. [30] P. Cousot, R. Cousot, and M. Riguidel. TUAMOTU: Tatouage électronique sémantique de code mobile Java. Project RNRT 1999 n◦ 95, Oct. 1999 – Oct. 2001. [31] P. Cousot and N. Halbwachs. Automatic discovery of linear restraints among variables of a program. In 5th POPL , pages 84–97, Tucson, AZ, 1978. ACM Press. [32] S.K. Debray. Formal bases for dataflow analysis of logic programs. In G. Levi, editor, Advances in Logic Programming Theory , Int. Schools for Computer Scientists, section 3, pages 115–182. Clarendon Press, 1994. [33] A. Deutsch. Semantic models and abstract interpretation techniques for in­ ductive data structures and pointers, invited paper. In Proc. PEPM ’95 , pages 226–229, La Jolla, CA, 21–23 June 1995. ACM Press. [34] N. Dor, M. Rodeh, and M. Sagiv. Checking cleanness in linked lists. In J. Palsberg, editor, Proc. 7th Int. Symp. SAS ’2000 , Santa Barbara, CA, US, LNCS 1824, pages 115–134. Springer-Verlag, 29 June – 1 Jul. 2000. [35] C. Ferdinand, F. Martin, R. Wilhelm, and M. Alt. Cache behavior predic­ tion by abstract interpretation. Sci. Comput. Programming, Special Issue on SAS’96 , 35(1):163–189, September 1999. [36] J. Feret. Confidentiality analysis of mobile systems. In J. Palsberg, editor, Proc. 7th Int. Symp. SAS ’2000 , Santa Barbara, CA, US, LNCS 1824, pages 135–154. Springer-Verlag, 29 June – 1 Jul. 2000. [37] R. Giacobazzi, F. Ranzato, and F. Scozzari. Making abstract interpreta­ tions complete. J. ACM , 47(2):361–416, 2000. [38] P. Granger. Static analysis of arithmetical congruences. Int. J. Comput. Math. , 30:165–190, 1989. [39] P. Granger. Static analysis of linear congruence equalities among variables of a program. In S. Abramsky and T.S.E. Maibaum, editors, Proc. Int. J. Conf. TAPSOFT ’91, Volume 1 (CAAP ’91) , Brighton, GB, LNCS 493, pages 169–192. Springer-Verlag, 1991. [40] N. Halbwachs. About synchronous programming and abstract interpreta­ tion. Sci. Comput. Programming, 31(1):75–89, May 1998. [41] R.R. Hansen, J.G. Jensen, F. Nielson, and H. Riis Nielson. Abstract inter­ pretation of mobile ambients. In A. Cortesi and G. Filé, editors, Proc. 6th Int. Symp. SAS ’99 , Venice, IT, 22–24 Sep. 1999, LNCS 1694, pages 134–138. Springer-Verlag, 1999. [42] W.L. Harrison. Can abstract interpretation become a main stream com­ piler technology? (abstract). In P. Van Hentenryck, editor, Proc. 4th 150 Patrick Cousot [43] [44] [45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] Int. Symp. SAS ’97 , Paris, FR, 8–10 Sep. 1997, LNCS 1302, page 395. Springer-Verlag, 1997. T.A. Henzinger, R. Majumbar, F. Mang, and J.-F. Raskin. Abstract in­ terpretation of game properties. In J. Palsberg, editor, Proc. 7th Int. Symp. SAS ’2000 , Santa Barbara, CA, US, LNCS 1824, pages 220–239. Springer-Verlag, 29 June – 1 Jul. 2000. N.D. Jones. Combining abstract interpretation and partial evaluation (brief overview). In P. Van Hentenryck, editor, Proc. 4th Int. Symp. SAS ’97 , Paris, FR, 8–10 Sep. 1997, LNCS 1302, pages 396–405. Springer-Verlag, 1997. P. Lacan, J.N. Monfort, L.V.Q. Ribal, A. Deutsch, and G. Gonthier. The software reliability verification process: The Ariane 5 example. In Pro­ ceedings DASIA 98 – DAta Systems In Aerospace , Athens, GR. ESA Publications, SP-422, 25–28 May 1998. B. Le Charlier and P. Van Hentenryck. Experimental evaluation of a generic abstract interpretation algorithm for Prolog. In Proc. 1992 ICCL , Oak­ land, CA, pages 137–146. IEEE Comp. Soc. Press, 20–23 Apr. 1992. F. Martin. Generating Program Analyzers. Pirrot Verlag, Saarbrücken, DE, 1999. F. Masdupuy. Semantic analysis of interval congruences. In D. Bjørner, M. Broy, and I.V. Pottosin, editors, Proc. FMPA , Akademgorodok, Novosi­ birsk, RU, LNCS 735, pages 142–155. Springer-Verlag, 28 June – 2 Jul. 1993. L. Mauborgne. Tree schemata and fair termination. In J. Palsberg, editor, Proc. 7th Int. Symp. SAS ’2000 , Santa Barbara, CA, US, LNCS 1824, pages 302–321. Springer-Verlag, 29 June – 1 Jul. 2000. D. Monniaux. Abstract interpretation of probabilistic semantics. In J. Pals­ berg, editor, Proc. 7th Int. Symp. SAS ’2000 , Santa Barbara, CA, US, LNCS 1824, pages 322–339. Springer-Verlag, 29 June – 1 Jul. 2000. A. Mycroft. Abstract Interpretation and Optimising Transformations for Ap­ plicative Programs. Ph.D. Dissertation, CST-15-81, Department of Com­ puter Science, University of Edinburgh, Edinburg, UK, Dec. 1981. F. Randimbivololona, J. Souyris, and A. Deutsch. Improving avionics soft­ ware verification cost-effectiveness: Abstract interpretation based tech­ nology contribution. In Proceedings DASIA 2000 – DAta Systems In Aerospace , Montreal, CA. ESA Publications, 22–26 May 2000. D.A. Schmidt and B. Steffen. Program analysis as model checking of ab­ stract interpretations. In G. Levi, editor, Proc. 5th Int. Symp. SAS ’98 , Pisa, IT, 14–16 Sep. 1998, LNCS 1503, pages 351–380. Springer-Verlag, 1998. J. Stransky. A lattice for abstract interpretation of dynamic (lisp-like) structures. Inform. and Comput. , 101(1):70–102, Nov. 1992. R. Vallée-Rai, H. Hendren, P. Lam, É Gagnon, and P. Co. Soot - a Javatm optimization framework. In CASCON ’99 , Sep. 1999. Abstract Interpretation Based Formal Methods and Future Challenges 151 [56] F. Védrine. Binding-time analysis and strictness analysis by abstract inter­ pretation. In A. Mycroft, editor, Proc. 2nd Int. Symp. SAS ’95 , Glasgow, UK, 25–27 Sep. 1995, LNCS 983, pages 400–417. Springer-Verlag, 1995. [57] A. Venet. Automatic determination of communication topologies in mobile systems. In G. Levi, editor, Proc. 5th Int. Symp. SAS ’98 , Pisa, IT, 14–16 Sep. 1998, LNCS 1503, pages 152–167. Springer-Verlag, 1998. [58] A. Venet. Automatic analysis of pointer aliasing for untyped programs. Sci. Comput. Programming, Special Issue on SAS’96 , 35(1):223–248, Septem­ ber 1999. [59] Kwangkeun Yi. An abstract interpretation for estimating uncaught exceptions in standard ML programs. Sci. Comput. Programming, 31(1):147–173, May 1998. The electronic version of this paper includes additional material on static pro­ gram analysis applications as well as a comparison with other formal methods (typing, model-checking and deductive methods) which, for lack of space, could not be included in this published version. A broader bibliography is available in its extended version.x ...
View Full Document

This note was uploaded on 04/18/2011 for the course COMPUTER S 1111 taught by Professor Name during the Spring '05 term at MIT.

Ask a homework question - tutors are online