A CIL Tutorial - Department of Computer Science - ETH Zürich

CHAPTER 15. AUTOMATED TEST GENERATION 128
approximation may prevent the SMT solver from producing a new path through the code, but
strategies for achieving high coverage exist in this case, and are implemented by the above mentioned
tools.
To handle function calls, the mapping of actual parameters to formal parameters is handled like
assignments. To handle function return values, a call is made so that the value can be remembered
by the runtime, and then assigned at the call site.
A loop is wrapped around each call of an autotest function. This loop noties the runtime
when an autotest function is completed. If the runtime is able to produce an input that may
explore a new path, the autotest function is called again. Otherwise, the loop terminates. This
loop is constructed in the makeTestLoop function by way of an interpreted constructor.
15.2.2 autotest Runtime
The runtime library for this tutorial is divided into three parts. First, we maintain a symbolic
memory that maps concrete addresses to expressions in terms of inputs. Second, at the end of an
autotest function, we translate these expressions into expressions of the Yices SMT solver in order
to obtain a path condition. Finally, we maintain a set of path conditions from which we may choose
a path to modify for submission to Yices in the hope of obtaining inputs that will explore a new
path. The source for the runtime library can be found in ciltut-lib/src/concolic. File names
mentioned below are relative to this path.
The le concolic exp.ml implements our internal expression representation. We dene our
own type for expressions instead of translating directly to Yices expressions so that we leave open
the possibility of using other SMT solvers in the future. The le concolic ctxt.ml implements the
mapping from memory addresses to our symbolic expressions. It also maintains state for Yices, and
includes a function yices of exp that translates our symbolic expressions into Yices expressions.
In yices of exp the bit shifting operations are not translated into symbolic Yices expressions.
This is because the Yices theory for bitvectors is only capable of reasoning about shifts by constant
amounts. Therefore, yices of exp simply uses the concrete result of the operations.
Finally, the le concolic paths.ml implements the path exploration algorithm. The global
record pState maintains a list of already explored paths along with a list of conditions for the
current path. It also maintains two mappings. The branchHT hash table maps branch identiers
to the state of a branch. A branch identier is a combination of an id assigned at compile time to
each conditional, and a count of the number of times a conditional has been executed on a single
concrete run. The count is kept so that the possibly many executions of the same static conditional
are not improperly conated by the path exploration algorithm. This is important, for example,
so that each time a loop guard is executed, it is considered a dierent conditional. The state of
a branch is either NeitherTaken, TrueTaken, FalseTaken, or BothTaken. The second hash table,
branchCounts, keeps track of how many times a conditional has been executed, so that branch id's
may be properly assigned.
When a conditional is executed, its id is determined by checking its static id and looking it up
in branchCounts. Then, the condition is appended to pathCond. When an autotest function ends,
the expressions in pathCond are translated to Yices expressions, and the resulting path condition is
appended to paths, and branchHT is updated. Then, paths is searched for a path condition having