Symbolic execution of transition systems with function summaries

. Reactive systems can be modeled with various kinds of automata, such as Input Output Symbolic Transition Systems (IOSTS). Symbolic execution (SE) applied to IOSTS allows computing constraints associated to IOSTS path executions (path conditions). In this context, generating test cases amounts to ﬁnding numerical input values satisfying such constraints using solvers. This paper explores the case where IOSTS models contain functions which are outside of the scope of such solvers. We propose to use function summaries which are logical formulas built from concrete values describing some representative input/output data tuples of the function. We deﬁne algorithmic strategies to solve path conditions including such functions based on techniques using and enriching function summaries. Our method has been implemented within the Diversity tool and has been applied to several examples.


Introduction
Many testing theories and algorithms use Symbolic Execution (SE) techniques [10].In the last decade, it has received much attention and has been incorporated in several testing tools such as NASA's Symbolic (Java) PathFinder [29], UIUC's CUTE and jCUTE [21], UC Berkeley's CREST [13], and the CEA's PathCrawler [28] and DIVERSITY tools [15].In particular, for the latter one, SE has been adapted for models using variants of abstract labeled transition systems, namely Input Output Symbolic Transition Systems (IOSTS) [17].Symbolic trees representing all possible execution paths of the model (up to some coverage goals) are computed by executing the model with variables instead of concrete values.For a particular path, a constraint on these variables, called path condition, characterizes concrete values ensuring its execution.Sequences of concrete test inputs exercising a given path are computed by solving the corresponding path condition.As is the case for programs, one of the main limits of this approach is that the usage of some particular functions in the model may make the process inapplicable, either because their symbolic analysis would cause combinatorial explosion in the number of paths to be considered, or because they contain operations that go beyond the capacity of the solver used, or even simply because they are black box functions from the model point of view.This latter situation occurs for example when the modeler makes a reference to an executable function without accessible source code in its model (or without source code processable by the SE tool).In this paper, we call such functions external functions and they are assumed to be functionally correct (i.e.we suppose that we have a reference implementation for each of the external functions used in the model).In the frame of Model-based Testing [33], a classical way to deal with this situation is to fully abstract external functions by considering the results of their calls as random values.This makes the model behaviors highly non deterministic and causes the test case generation process to compute test cases with a low level of controllability: the behavior of the system under test may deviate from the execution path which it is supposed to exercise without revealing an error in the system.Those situations are referred to as inconclusive.
In this paper we adapt to models an approach used at the code level, which is based on a representation of external functions as so-called function summaries.A function summary is a logical formula that can be computed from a partial knowledge of the function, represented as a table containing some representative tuples of inputs/output data.Those tuples are obtained by (concretely) executing the function on a set of inputs, either produced randomly or given by the programmer.They may also result from pre-existing unit test campaigns.Path conditions are then computed based on a joint analysis of the guards occurring in executed transitions and of the function summaries associated to external functions called in those transitions.A drawback of such an approach is of course that the tables might be too incomplete to provide input/output data to follow a given model path, meaning that their corresponding summaries are too restrictive to follow the path.The main contribution of this paper is to define a heuristic to deal with this situation by completing the function tables.The heuristic is based on the computation of new inputs by solving formulas built to avoid duplications in the tables and also to take benefits of the potential function dependencies.The overall approach can be seen as a reachability analysis based on symbolic execution techniques and an heuristic search algorithm used to solve path conditions.The resulting symbolic paths can then be used to generate test cases, in a classical model-based testing approach, for IOSTS extended with function calls.Concrete test inputs can thus be given to an existing system, in order to see if this system reacts according to its IOSTS model.This contribution has potential applications for industrial software testing practices especially integration testing, where units of code (i.e.external functions) must be taken into account while testing the whole system.
The remainder of the paper is organized as follows.Section 2 gives basic concepts about IOSTS and SE.In Section 3, we define function summaries.The main contribution of the paper is given in Section 4: it concerns the resolution of path conditions involving function calls using function summaries.The implementation and experiments of our approach are discussed in Section 5. Finally we conclude the paper with a discussion of related work (Section 6) and some concluding words (Section 7).

Preliminaries
A data signature is a pair (S, F ) where S is a set of types and F a set of functions provided with a profile s 1 • • • s n → s n+1 on S. For V = s∈S V s a set of variables typed in S, the set T F (V ) = s∈S T F (V ) s of terms over V is defined as usual.For two sets A and B, B A denotes the set of mappings f : A → B from A to B and id A is the identity mapping on A. For a mapping f : .n is the mapping associating b i to a i for all i in 1..n and f (a) to a not belonging to The set Sen F (V ) of formulas is built over Boolean constants and ⊥, equalities t = t for t and t terms in T F (V ) of same type and Boolean connectives (∧, ∨, ¬).Substitutions over V are applications σ : V → T F (V ) that preserve types.Substitutions can be canonically extended to interpretation is an application ν in M V that preserves types and is canonically extended to T F (V ).The satisfaction of a formula ϕ in Sen F (V ) by an interpretation ν ∈ M V , denoted M |= ν ϕ, is defined as usual.A formula ϕ is said satisfiable or feasible if there exists an interpretation ν such that M |= ν ϕ.
In the sequel, a data signature (S, F ) and an F -model M are supposed given.Moreover, when a formula ϕ is satisfiable and can be handled by a solver, Sat(ϕ) will denote a solution computed by a solver (whatever are the solution or the solver).

IOSTS
Input Output Symbolic Transition Systems (IOSTS) represent behaviors of reactive systems as sequences of emissions or receptions of values through communication channels conditioned by guards expressed on some attribute values.An IOSTS-signature Γ is a couple (A, Ch), where A = s∈S A s is a set of typed variables, called attribute variables.In the sequel, a variable v of A will be denoted either as a simple identifier (id) or as an identifier (id) and an integer (i) pair, denoted as id[i].The latter case will be useful for dealing with modeling of arrays.Ch is a set of communication channel names.
Values of attribute variables can be modified either by a reception from the environment or by an assignment of a value issued from some internal process.
set of transitions tr of the form (q, ψ, act, ρ, q ) where: q and q are resp.the source (source(tr)) and target state (target(tr)) of tr; Example 1.Let us illustrate an example of IOSTS inspired from the Sesam-Grids project [12]: Figure 1 describes a simple model of a Microgrid, that is, a system of interconnected and distributed smart components (smartmeters, controller, ...) in connection with energy resources and energy consumption devices.Our example describes a simplified model of a controller inside a Microgrid.Electricity measurements are requested by a smart controller (mReq!action) and sent by a smart meter (getmeas?V alue[cpt]).N measurements are stored in the array V alue whose data can be accessed through variables of the form V alue[i] with i integer.Then, they are used by the controller to compute the total electricity consumption via an integral calculation (I → IN T GR(V alue)) where IN T GR is an external function.If the overall consumption is greater than 200, then the function RISE (which is also an external function) is called to compute, according to the returned consumption I, a rate r that is added to the energy price.The new price ((1 + r) * i) is sent to the actuator via the (out) channel, together with a message indicating whether the rise is normal ("ok", if r <= 1) or should trigger a warning ("alarm", if r > 1).Otherwise, if the consumption is lower than 200, an acknowledgment is sent (out!("ok", I)).In Figure 1, guards of the form t 1 ≤ t 2 , t 1 < t 2 , t 1 > t 2 or t 1 ≥ t 2 are concise representations of respectively t 1 ≤ t 2 = , t 1 < t 2 = , t 1 > t 2 = or t 1 ≥ t 2 = .

Symbolic execution of IOSTS
Symbolic execution (SE) consists in executing the IOST S with symbolic variables rather than numerical values.SE gathers constraints (path condition) over such variables that characterize under which circumstances a particular execution path is taken.
To store information concerning an execution, we use a set F r of so-called fresh variables with F r ∩ A = ∅ and structures called symbolic states.F r is an infinite set in which, whenever necessary, it is possible to take a variable not previously used.A symbolic state η is a tuple (q, π, λ) where: q (or q(η)) denotes the state in Q reached after an execution leading to η, π ∈ Sen F (F r) (or π(η)) is the path condition that should be satisfied for the execution to reach η and λ : A → T F (F r) (or λ(η)) denotes terms over variables in F r that are assigned to variables of A.
We denote F r(SE(tr, η)) the set of all fresh variables of F r occurring in its definition while not already present in η.
The symbolic execution tree associated with the IOST S is then defined simply by executing all transitions from all symbolic states.Definition 3 (SE of IOST S).Given an IOSTS G = (Q, q 0 , T r) over Γ = (A, Ch), the symbolic execution SE(G) = (SS, Init, ST ) of G is minimally defined by: -ST is a set of symbolic transitions such that for any η = (q, π, λ) in SS and for any tr ∈ T r of source state q, there exists one symbolic execution SE(tr, η) = (η, act F , η ) of tr from η with SE(tr, η) ∈ ST and η ∈ SS.
Moreover F r(SE(tr, η)) ∩ F r 0 = ∅ and for any two distinct symbolic transitions SE(tr 1 , η 1 ) and SE(tr Now, we define paths of the symbolic tree resulting from the symbolic execution of an IOST S: Definition 4 (Symbolic Paths).The set P aths(SE(G)) of paths of SE(G) is the set of all sequences st 1 • • • st n with ∀i ∈ 1..n, st i ∈ ST such that source(st 1 ) = Init and for any j < n, q(target(st j )) = q(source(st j+1 )). For By construction, path conditions accumulate constraints from all the guards of the IOSTS transitions over a path.Hence, feasibility of path pa is checked by calling a solver over the path condition of the last state of pa.In the sequel, such call will be denoted Sat(π(End(pa)).
As already mentioned in section 1, external functions such as IN T GR and RISE have no built-in interpretations in standard constraint solvers.Thus, when path conditions contain external functions, usual constraint solving techniques cannot be applied directly.We thus propose an improved resolution method to guide the symbolic execution by checking paths feasibility up to some function calls.

Function summaries
Instead of either considering external functions as purely abstract by replacing their output with a fresh variable or inserting their code (inlining) at model level quickly leading to combinatorial explosion, our approach allows to control this issue by replacing external functions with summaries that offer a partial and extendable view of the function within the model.
In the sequel, P will denote a distinguished subset of F , the set of all external functions.

Summaries
Values which are used to summarize an external function are taken from its concrete execution on some inputs.This can be represented and saved as a table mapping a finite set of tuples associating input and output data of the function.Notation 31 For p ∈ P an external function of profile s 1 . . .s n → s n+1 and p M ∈ M its interpretation, we denote by tab p , a set of tuples with the convention Sum(cl, ∅) = ⊥.
Example 2. Let us go back to the Microgrid example (Figure 1) with the hypothesis N = 2.Then, a scenario involves two measurements m 1 and m 2 .For illustrative purposes, values that will be used in the summaries associated to the external functions IN T GR and RISE are given in Table 1.Based on the values provided by Table 1, we can then compute the corresponding summaries for the set of function calls

Formula transformation
A path condition ϕ is built over terms of T F (V ) that may contain occurrences of external functions.Since the satisfiability of ϕ requires to find an interpretation ν ensuring M |= ν ϕ, the idea is to proceed in two steps: 1. ϕ is transformed into a formula with no occurrence of external functions and a set of function calls.
2. the satisfiability of ϕ is checked with a constraint solver and based on external function summaries (built on concrete executions of called functions).
For a formula ϕ containing a term of the form p(t 1 , • • • , t n ) with p ∈ P , we will eliminate the occurrence of p in ϕ by introducing a new fresh variable x in charge of storing the result of the application of p to the terms t 1 , . . ., t n .An interpretation will be acceptable as a solution only if it evaluates terms t 1 , . . ., t n and x so that they correspond to one of the elements of the function table tab p .Thus, while eliminating all occurrences of external function in formulas, we also collect all tuples (t 1 , . . ., t n , x) memorizing all contexts of calls of external functions.
Let us first define a function χ : T F (V ) → T F (V ∪ F r) × Calls(P ) as follows: ) with x a fresh variable in F r.
We assume that all fresh variables introduced by function calls (i.e. the sets χ(t) |2 ) are pairwise disjoint.Note that the term substitution is performed iteratively by starting with the innermost sub-terms in case of nested function calls.The function χ is canonically extended to formulas by preserving formula structure and accumulating all sets of function calls in a unique set.In the sequel, for a formula ϕ, χ(ϕ) |1 , the formula ϕ without external functions, will be denoted ϕ and χ(ϕ) |2 , the set of associated calls, will be denoted κ(ϕ).Now that we are able to remove external functions, we will propose an algorithm to check formula satisfiability.

Satisfiability of formulas up to function summaries
Given a formula ϕ possibly built over external functions, we aim at defining an algorithm that analyzes the satisfiability of ϕ up to summaries of called external functions.Recall that ϕ is transformed into a formula (ϕ) with no occurrence of external functions, while we keep track of external function calls in κ(ϕ).We also suppose that we have function tables for these external function calls in T ab.
Since by construction Sums(κ(ϕ), T ab) is the formula specifying that function calls of κ match with at least a tuple of T ab, if Sat(ϕ ∧ Sums(κ(ϕ), T ab)) returns a solution, then ϕ is satisfiable (i.e.there exists an interpretation ν such that M |= ν ϕ).Otherwise, either ϕ is not satisfiable (i.e.∀ν, M |= ν ϕ) or ϕ is satisfiable but the function tables (used to summarize functions) are not complete enough to exhibit an interpretation ν such that M |= ν ϕ.Therefore, in the sequel we place ourselves in the hypothesis that function tables can be enriched during the satisfiability search.Furthermore, some heuristics are proposed to help the solver finding a solution when current function summaries are not compatible with the formula, e.g. to find additional input data for external functions that could make the formula feasible.We describe these heuristics in more detail below.

Resolution strategies
NoCorres strategy: N oCorres computes a formula guaranteeing that the inputs of called external functions are different from those already present in the current function tables.This formula will be used later to get new inputs for the concrete executions of external functions, ensuring the enrichment of the function tables, which in turn increases chances to find a solution.
Definition 6 (NoCorres).Let Cls ⊆ Calls(P ) be a set of function calls and T ab = (tab p ) p∈P a set of tables where tab p is the table associated to p in P .N oCorres(Cls, T ab) is defined as follows: with N oCorres1((p, (t 1 , • • • , t n ), x), tab p ) being defined as follows: By considering the conjunction of N oCorres(κ(ϕ), T ab) and ϕ, the solver cannot compute interpretations of variables for which all function calls in κ(ϕ) are already present in T ab. - Dependency heuristic: Another way to accelerate and help the solver resolution task to find new inputs, when no solution is found with the current function tables, is to take advantage of direct dependencies between function calls.Indeed when the arguments of a call to an external function f depend on the result of calls to other external functions f i , we can indicate to the solver to search for solutions in which the inputs of f are compatible with the outputs already present in the tables of the f i .
Definition 7 (Dep).Let Cls ⊆ Calls(P ) be a set of function calls and T ab = (tab p ) p∈P a set of tables where tab p is the function table associated to p in P .
Dep(Cls, T ab) is defined as follows: with Dep1(cl, Cls, T ab) being defined as follows: where: - is the set of function calls on which the inputs of cl depend, i.e. the result of these function calls occurs in one or several input terms of cl.-For cl = (q, (t 1 , • • • , t n ), x ), CorresRes(cl , tab q ) is the formula CorresRes(cl , tab q ) extracts values from the tables of function calls on which cl depends.By combining both N oCorres and Dep heuristics, it is possible to generate new sets of inputs, i.e. new rows in the tables of external functions that are relevant for the overall path constraint resolution.Indeed, N oCorres ensures that we will add at least one new row to a function table, while Dep takes care of avoiding solutions that cannot be satisfied by the current summaries of the callers, and are thus useless for the current solving process.

SolveTab algorithm
Algorithm 1 describes our dynamic solving procedure SolveT ab(m, ϕ, κ(ϕ), T ab).The goal of SolveT ab is to analyze the satisfiability up to some function tables T ab of a formula (ϕ) with no occurrences of external functions, provided with a set of function calls (κ(ϕ)).The integer parameter m is used to bound the number of attempts that are made to increase the size of function tables.As explained in the previous section, we resort to this mechanism when no tuple in a function table is compatible with ϕ.However, since there is no guarantee that extending function tables will eventually lead to find a solution for ϕ ∧ Sums(κ(ϕ), T ab), we cut the search after at most m steps.If no solution is found beyond m or no possible function inputs are found, then we can deduce that the formula is unsatisfiable up to function tables.The case m = 0 corresponds to a purely static version where a solution is searched without modifying function tables (i.e.T ab is then a static variable).Let us now give some few comments on Algorithm 1.By hypothesis, arguments (ψ, κ) = χ(ϕ) for some ϕ, so that ψ and κ share external functions and variables.
If Sat(ψ ∧Sums(κ, T ab)) gives back a result sol, then sol directly provides an interpretation of variables that satisfies the formula ϕ in which external functions are interpreted according to values given in their associated tables T ab.In other words, by construction M |= sol ϕ.
In case no solution is found with Sat(ψ ∧ Sums(κ, T ab)) in Line 2 (ψ is unsatisfiable up to current function summaries), then we try to find additional input data for external functions that could enrich T ab (and function summaries) and make the formula satisfiable.In order to guide the solver to find new inputs, Dep and N oCorres heuristics can be used.N oCorres is necessary to compute new inputs distinct from those already present in current tables (that failed to provide us with a solution).On the other hand, Dep is an alternative option that can facilitate the search for inputs that are compatible with dependencies among function calls.However, this might restrict the search space too much, as we may need to add a new output to the table of function f to find a suitable input for g that depends on f .Therefore, if adding the Dep condition results in an unsatisfiable formula (Line 7), we call the solver again with only the formula and the N oCorres condition.Indeed, the new tuples might give us new outputs that will in turn make Dep satisfiable at next step, or even give directly a solution to the original problem.
If an interpretation (variable In) is found, then lines 10, 11 and 12 allow us to add new tuples in function tables (variable T ab), by successively extracting input values V Ins ← ins(In, cl) for each function call (line 10), concretely executing the function (line 11) with V Ins as input data, (Exec p being the reference implementation of p), to obtain the corresponding output (variable r) and finally storing new tuples in T ab p (line 12).Then, the solver is called (line 13) to check the satisfiability of ψ, with the new summaries based on the enriched function tables.
Last, let us point out that a bigger number m of allowed attempts to search for new tuples enriching function tables gives more chances to find a solution, but will possibly take longer to compute.

Discussion: SolveT ab for symbolic execution
Since path conditions are formulas built over terms that may contain occurrences of external functions, we proceed as detailed in the previous section in order to check symbolic paths feasibility according to function summaries.For that, we use the SolveT ab solving Algorithm 1 based on concrete executions of called functions to guide the symbolic execution of IOST S. Therefore, we need to extend symbolic states by accumulating function calls.An extended symbolic state is of the form η = (q, π, λ, κ), where κ (or κ(η)) denotes the sequence of function calls of the form (p, (t 1 , • • • , t n ), x).By construction, the path condition π does not contain occurrences of external functions.
A symbolic state (q, π, λ, κ) is satisfiable according to function summaries only if there exists an integer m and function tables T ab such that the result (sol, T ab) provided by SolveT ab(m, π, κ, T ab) defines an interpretation sol of fresh variables ensuring the interpretation of π as true.
The symbolic execution in accordance with function tables is based on the SolveT ab resolution algorithm which takes as arguments, in addition to the path condition and the set of accumulated function calls, the parameter m and the set of tables T ab.If we note SE T ab,m (G) the symbolic execution of G using SolveT ab for building satisfiable symbolic states, then SE T ab,m (G) is highly dependent on the initial tables (T ab) specifying called functions, the chosen threshold of resolution attempts m, the choice of the solver and the strategy of traversal (in depth, in width, . . . ) of the symbolic tree.Thus, the construction of SE T ab,m (G) will more or less approach the ideal symbolic tree SE(G).If elements of T ab are representative enough of the behavior of called functions, with regard to the solicitations of the IOST S or if m is large enough to find a solution for each possible path of the IOST S (by enriching function tables), then SE T ab (G) becomes closer to SE(G) and more states become reachable.

Implementation
DIVERSITY tool: DIVERSITY [3,14], is a multi-purpose and customizable platform for formal analysis based on symbolic execution (test generation, proof, deadlock search, etc.) that is on its way to becoming an Eclipse open-source project 5 .DIVERSITY generates a symbolic tree (for a fixed maximal height) by simulating the system specification with input symbols rather than concrete values for data.Test inputs are computed by solving the path conditions.For that purpose, DIVERSITY integrates solvers such as Z36 , and CV C4 7 .
We have implemented the SolveT ab algorithm 1 and the heuristics described in Section 4 as additional Formal Analysis Module (FAM) for checking satisfiability of path conditions within DIVERSITY.By default, constraints involving external functions are left uninterpreted (i.e.out of the scope of solvers).In addition, variable assignments within an IOST S transition contain only basic operations.Now, all such external functions can be handled with the newly implemented technique, using values recorded in function tables.The SolveT ab algorithm allows to know whether a new execution context EC (a symbolic state) can be built in the symbolic execution tree in accordance with called functions, after the execution of a transition in the IOST S. In other words, it checks if a transition of the IOST S could be fired or not according to called functions, with a possible enrichment of the function tables.Therefore, thanks to SolveT ab we ensure the symbolic tree's construction with only feasible paths compatible with called functions while ensuring a high transition coverage of the IOST S transitions.
Microgrids case study: Here, we discuss the application of our technique to the Microgrid example 1 that uses external function calls (IN T GR and RISE).For that, we present the resulting symbolic trees (to a depth of 6) by applying the SolveT ab algorithm with the initial function tables

Experiments
A summary of the main outcomes of the application of our technique to the Microgrid example is provided in Table 2.It should be noted that our results are based on the initial function tables given in table 1 and that we dispose of the functions' implementation in order to be able to execute them with appropriate inputs in an unitary setting.For each experiment (i.e. each line), we fix "m" (maximum number of attempts for the SolveT ab algorithm) and the maximum "height" allowed for the symbolic tree.Then we record results concerning the enriched tables (number of tuples) and the symbolic tree computation: the number of reachable states, the achieved IOST S transitions coverage and the execution time.Again, when m = 196 all possible symbolic states are covered, and there is no need to try to further enrich the function tables.
The resulting coverage rate and execution time depend on the initial function tables.In fact, the more the elements of called function tables are representative of the function behaviors and compatible with path conditions, the less attempts are needed to achieve the same level of coverage.For instance, if we now start with the initial function tables of table 3 for the Microgrid example, all transitions of the specification are covered (in 2s759ms) without doing any concrete     3 6 Related Work IOSTS and symbolic execution have been used in many works [6,10,17] for different purposes.Until now standard solvers were not capable of dealing with functions occurring in path conditions.The usage of symbolic execution and path feasibility analysis are studied in [7,35] but this is limited to the analysis of functions themselves and does not take into consideration the impact of function calls on the feasibility of the whole system.Our work borrows the idea of mixing symbolic execution with information obtained from instrumented concrete executions, from concolic testing, a method that has been implemented in various settings, such as [9,18,32].However, these frameworks are primarily directed at source code level in the objective of unit testing.Another concolic tool, PathCrawler [36] proposed an approach to encompass function calls [25], using pre/post-condition couples as a specification.
Other unit testing frameworks traditionally use stubs [26], which are built manually in an ad-hoc way, to replace external functions for which no implementation is available.Also, automatically-generated software stubs [19] are used for abstracting (over-approximating) lower-level functions during dynamic test generation [16] based on code.[1,4,20,22], propose different techniques to conduct symbolic execution with simplified summary representations.But these techniques do not include heuristics similar to the ones (NoCorres, Dependency) we introduce in our paper.
Other techniques have been proposed to deal with constraints generated from symbolic code execution [2,30].These techniques fall back on concrete values and use randomization to help simplify complex constraints that cannot be solved directly.Our approach based on IOSTS models is orthogonal to these code-based approaches and uses some heuristic search to solve path conditions including external function calls.
In our previous work [8], like in the work [25], we specify external functions by means of contracts (instead of tables): we unfolded the symbolic tree of an IOSTS by replacing each transition including an external function call by as many transitions as there are behaviors in the contract associated to the considered external function.

Conclusion and future work
In this work, we use the IOSTS framework extended with external functions.We adapt existing symbolic execution techniques over IOSTS to deal with such function calls, using function tables to summarize them with a formula.The construction of a symbolic execution tree is based on an algorithm SolveT ab that permits to check path conditions satisfiability up to function summaries with the possibility of enriching function tables by concretely executing them, in order to achieve a high transition coverage of the IOST S.
The proposed approach has been implemented within the DIVERSITY symbolic execution tool.The results show that symbolic execution coupled with function summaries is a practical and effective approach to take into consideration external functions for IOSTS models analysis mainly for model-based testing which is a significant motivation for our work.Nevertheless, it could probably be applied to other families of transition systems like those in [31,33,34].

Example 4 .
By applying the above N oCorres definition on the set of function calls and tables given in Example 2, N oCorres(Cls, T ab) is the formula N oCorres1(cl 1 , T ab(IN T GR)) ∨ N oCorres1(cl 2 , T ab(RISE)) where:

Example 5 .
Let us consider again the function calls introduced in Example 2. We have: -Dep cl2 = {cl 1 } with cl 1 = (IN T GR, ([m 1 , m 2 ]), I), because I (the variable storing the result of cl 1 ) is an input of cl 2 = (RISE, (I), r).-CorresRes(cl 1 , tab(IN T GR)) is (I = 228 ∨ I = 300) Therefore, to find new inputs for RISE, we can give to the solver Dep(cl 2 , Cls), that is CorresRes(cl 1 , tab(IN T GR)) to exploit the values of I already existing in T ab(IN T GR).

Algorithm 1 : 3 T 6 if 7 In 8 if 10 V 11 r 14 else 15 T abM odif ied ← F alse; 16 m ← m − 1; 17 return
SolveT ab(m, ψ, κ, T ab) Data: m: an integer, ψ: a formula without black-box functions, κ : a set of function calls, T ab: function tables Result: satisfiability of ψ up to κ; T ab: updated function tables 1 begin 2 sol ← Sat(ψ ∧ Sums(κ, T ab)); abM odif ied ← T rue; 4 while T abM odif ied and sol = N ON E and m = 0 do 5 In ← Sat(ψ ∧ NoCorres(κ, T ab) ∧ Dep(κ, T ab)) /* Search for new solutions while considering dependencies between function calls */ ; In = NONE then /* no possible inputs for function */ ← Sat(ψ ∧ NoCorres(κ, T ab)) /* Search for new possible solutions without considering function dependencies */ ; In = NONE then /* new possible inputs for function */ 9 for each call cl = (p, (t1, • • • , tn), x) in κ do Ins ← Ins(In, cl) /* extract inputs for p from In */; ← Execp(V Ins) /* concrete execution of p */; 12 T ab(p) ← (V Ins, r).T ab(p) /* save new tuple in T ab */; 13 sol ← Sat(ψ ∧ Sums(κ, T ab)); (sol, T ab); 1 and various values of m, the number of attempts made to increase the function tables.At first, we use the static version (static tables, m = 0).Result is shown in the left tree of Figure 2. Then we progressively increase m until 196, function tables are enriched by concretely executing functions with new inputs found thanks to NoCorres and Dependency heuristics.As expected, this permits to cover more transitions of the model, reach more symbolic states and explore more feasible paths.Indeed the size of the generated tree grows with the value of m.The middle tree of figure 2 is obtained with m = 1, while the one on the right is the result of m = 196, where all transitions of the IOST S are covered.

Fig. 2 :
Fig. 2: Symbolic execution tree in DIVERSITY a function table of p.If tab p covers the entire domain of p then it will fully represent p M .We associate with each external function a summary built on values in the function table.More precisely, a function call will be stored in a given symbolic state under the form (p, (t 1 , • • • , t n ), x) indicating that a call has been performed for the external function p with arguments (t 1 , • • • , t n ) and that its result is stored in the fresh variable x.We note Calls(P ) the set of all function calls.Definition 5 (Function call summaries).Let Cls ⊆ Calls(P ) be a set of function calls and T ab = (tab p ) p∈P , where tab p is a function table associated to p in P .The summary of Cls up to T ab is:

Table 1 :
IN T GR and RISE tables

Table 2 :
Experiments with initial Tables1

Table 3 :
Other initial Tables execution (m = 0), as all possible outcomes are captured by one row of the tables.

Table 4 :
Experiments with other initial Tables