Symbolic crosschecking of floating-point and SIMD code

Collingbourne, Peter; Cadar, Cristian; Kelly, Paul H. J.

doi:10.1145/1966445.1966475

Cited by 72 publications

(50 citation statements)

References 19 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…However, it is projected that floating point units will be built in within a few years. Thus, we are currently looking into a floating point version of KLEE [2].…”

Section: Discussionmentioning

confidence: 99%

8Cage

Holling

Pretschner

Gemmar³

2014

Proceedings of the 29th ACM/IEEE International Conference on Automated Software Engineering

View full text Add to dashboard Cite

Matlab Simulink models, mainly used for the specification of continuous embedded systems, employ a data flow-driven notation well understood by engineers. This notation abstracts from the underlying computational model, hiding run time failures such as over-/underflows and divisions by zero. They are often detected late in the development process by the use of static analysis tools on the completely developed system. The responsible underlying faults are sometimes attributable to a single operation in a model. 8Cage is an automated test case generator for the early detection of such single operation related faults. It is configurable to detect these faults and runs automatically in the background. It tries to find potentially failure-causing operations and generates a test case to gather evidence for an actual fault. 8Cage is usable by developing/testing engineers with knowledge of Matlab. It does not require an expert to perform result validation or fault localization.

show abstract

“…However, it is projected that floating point units will be built in within a few years. Thus, we are currently looking into a floating point version of KLEE [2].…”

Section: Discussionmentioning

confidence: 99%

8Cage

Holling

Pretschner

Gemmar³

2014

Proceedings of the 29th ACM/IEEE International Conference on Automated Software Engineering

View full text Add to dashboard Cite

show abstract

“…As a first example, consider a program that uses floating-point numbers. Most DSE engines cannot handle symbolic floating-point computations, mainly due to the poor scalability of floating-point constraint solvers [4]. A possible testability transformation would be to replace all floating-point variables with integers or rational numbers, allowing DSE to make progress, while exploring a limited subset of behaviours.…”

Section: Semantics-altering Transformationsmentioning

confidence: 99%

Targeted program transformations for symbolic execution

Cadar

2015

Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering

Self Cite

View full text Add to dashboard Cite

Semantics-preserving program transformations, such as refactorings and optimisations, can have a significant impact on the effectiveness of symbolic execution testing and analysis. Furthermore, semantics-preserving transformations that increase the performance of native execution can in fact decrease the scalability of symbolic execution.Similarly, semantics-altering transformations, such as type changes and object size modifications, can often lead to substantial improvements in the testing effectiveness achieved by symbolic execution in the original program.As a result, we argue that one should treat program transformations as first-class ingredients of scalable symbolic execution, alongside widely-accepted aspects such as search heuristics and constraint solving optimisations. First, we propose to understand the impact of existing program transformations on symbolic execution, to increase scalability and improve experimental design and reproducibility. Second, we argue for the design of testability transformations specifically targeted toward more scalable symbolic execution.

show abstract

“…It includes 23:false because if the true branch is taken, the execution will reach new instances of fopen() and fclose() calls. It excludes all instructions in the inner loop (lines [14][15][16][17][18][19][20] and the return instruction (line 24) because they do not affect the event sequence. WOODPECKER then explores only the off-the-path branches included in the slice, and prunes the other ones, i.e., those at lines 14 and 15.…”

Section: Bounded Verification With Woodpeckermentioning

confidence: 99%

“…This verification approach is a form of bounded verification [17]. Researchers have argued and experimentally shown that checking all inputs within a small scope can effectively detect a high portion of bugs and achieve high statement and branch coverage [5,12,19,38].…”

Section: Introductionmentioning

confidence: 99%

Verifying systems rules using rule-directed symbolic execution

CuiHeming¹,

HuGang²,

WuJingyue³

et al. 2013

SIGPLAN Not.

View full text Add to dashboard Cite

Systems code must obey many rules, such as "opened files must be closed." One approach to verifying rules is static analysis, but this technique cannot infer precise runtime effects of code, often emitting many false positives. An alternative is symbolic execution, a technique that verifies program paths over all inputs up to a bounded size. However, when applied to verify rules, existing symbolic execution systems often blindly explore many redundant program paths while missing relevant ones that may contain bugs.Our key insight is that only a small portion of paths are relevant to rules, and the rest (majority) of paths are irrelevant and do not need to be verified. Based on this insight, we create WOOD-PECKER, a new symbolic execution system for effectively checking rules on systems programs. It provides a set of builtin checkers for common rules, and an interface for users to easily check new rules. It directs symbolic execution toward the program paths relevant to a checked rule, and soundly prunes redundant paths, exponentially speeding up symbolic execution. It is designed to be heuristic-agnostic, enabling users to leverage existing powerful search heuristics.Evaluation on 136 systems programs totaling 545K lines of code, including some of the most widely used programs, shows that, with a time limit of typically just one hour for each verification run, WOODPECKER effectively verifies 28.7% of the program and rule combinations over bounded input, whereas an existing symbolic execution system KLEE verifies only 8.5%. For the remaining combinations, WOODPECKER verifies 4.6 times as many relevant paths as KLEE. With a longer time limit, WOODPECKER verifies much more paths than KLEE, e.g., 17 times as many with a fourhour limit. WOODPECKER detects 113 rule violations, including 10 serious data loss errors with 2 most serious ones already confirmed by the corresponding developers.

show abstract

Symbolic crosschecking of floating-point and SIMD code

Cited by 72 publications

References 19 publications

8Cage

8Cage

Targeted program transformations for symbolic execution

Verifying systems rules using rule-directed symbolic execution

Contact Info

Product

Resources

About