Towards The Formalization of SPARK 2014 Semantics With Explicit Run-time Checks Using Coq Pierre Courtieu,Maria Virginia Aponte, Tristan Crolard Conservatoire National des Arts et Metiers Pierre.Courtieu@cnam.fr, maria-virginia.aponte_garcia@cnam.fr, tristan.crolard@cnam.fr Zhi Zhang, Robby, Jason Belt, John Hatcliff Kansas State University zhangzhi@ksu.edu, robby@ksu.edu, belt@ksu.edu, hatcliff@ksu.edu Jerome Guitton AdaCore guitton@adacore.com Trevor Jennings Altran trevor.jennings@altran.com ABSTRACT We present the first steps of a broad effort to develop a formal repre- sentation of SPARK 2014 suitable for supporting machine-verified static analyses and translations. In our initial work, we have de- veloped technology for translating the GNAT compiler’s abstract syntax trees into the Coq proof assistant, and we have formalized in Coq the dynamic semantics for a toy subset of the SPARK 2014 language. SPARK 2014 programs must ensure the absence of cer- tain run-time errors (for example, those arising while performing division by zero, accessing non existing array cells, overflow on integer computation). The main novelty in our semantics is the en- coding of (a small part of) the run-time checks performed by the compiler to ensure that any well-formed terminating SPARK pro- grams do not lead to erroneous execution. This and other results are mechanically proved using the Coq proof assistant. The mod- eling of on-the-fly run-time checks within the semantics lays the foundation for future work on mechanical reasoning about SPARK 2014 program correctness (in the particular area of robustness) and for studying the correctness of compiler optimizations concerning run-time checks, among others. Categories and Subject Descriptors D.2.4 [Software Engineering]: Software/Program Verification, For- mal Methods, Correctness Proofs; F.4.1 [Mathematical Logic and Formal Language]: Mathematical Logic—mechanical theorem prov- ing General Terms Reliability, Security, Verification Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org. HILT’13, November 10–14, 2013, Pittsburgh, PA, USA. Copyright 2013 ACM 978-1-4503-2466-3/13/11 ...$15.00. Keywords SPARK, Coq Proof Assistant, Formal Semantics, Machine-Verified Proof 1. MOTIVATION We believe that the certification process of SPARK technology can be stressed by the use of formal semantics. Indeed, the soft- ware certification process as required by the DO-178-C [10] stan- dard allows formal verification to replace some forms of testing. This is one of the goals pursued by the SPARK toolchain result- ing from the Hi-Lite project [3]. On the other hand, the DO-333 supplement [11] (formal method supplement to DO-178-C) recom- mends that when using formal methods "all assumptions related to each formal analysis should be described and justified". As any for- mal static analysis must rely on the behavior of the language being analyzed, a precise and unambiguous definition of the semantics of this language becomes clearly a requirement in the certification process. We also aim to strengthen the theoretical foundation of the GNAT- prove toolchain. The Ada reference manual [1] introduces the no- tion of errors. These correspond to error situations that must be detected at run time as well as erroneous executions that need not to be detected. In Ada, the former are detected by run-time checks (RTCs) inserted by the compiler. Both must be guaranteed never to occur during the process of proving SPARK (or Ada) subprograms within the GNATprove toolchain [2]. This can be ensured either by static analysis or by generating verification conditions (VCs) show- ing that the corresponding error situations never occur at that point in the subprogram. The generated VCs must be discharged in order to prove the subprogram. Tools within the GNATprove toolchain strongly rely on the completeness of this VCs generation process. Our semantics setting on top of a proof assistant open the possi- bility to formally (and mechanically) verify (to some extent) this completeness. In practice, since VCs are actually generated from the RTCs generated by the compiler, this completeness verification amounts to analyzing the RTCs inserted by the compiler in the ab- stract syntax tree produced by the GNAT compiler. Finally, one of our long-term goals is to provide infrastructure that can be leveraged in a variety of ways to support machine- verified proofs of correctness of SPARK 2014 static analysis and translations. To this end, we will build a translation framework from SPARK 2014 to Coq, which puts in place crucial infrastruc- ture necessary for supporting formal proofs of SPARK analysis. 21