1. What are the contributions mentioned in the paper "Verified software toolchain" ?
Their Verified Software Toolchain verifies with machine-checked proofs that the assertions claimed at the top of the toolchain really hold in the machine-language program, running in the operating-system context, on a weakly-consistent-shared-memory machine.. Their verification approach is modular, in that proofs about operating systems or concurrency libraries are oblivious of the programming language or machine language, proofs about compilers are oblivious of the program logic used to verify static analyzers, and so on.. In this paper I explain some semantic techniques for building a verified toolchain.. The authors want to construct a machine-checked proof, from the foundations of logic, that Any claims by the static analyzer about observations of the source-language program will also characterize the observations of the compiled program.. The authors may want to attach several different static analyzers to the same compiler, or choose among several compilers beneath the same analyzer, or substitute one operating system for another.. The construction and verification of just one component, such as a compiler or a static analyzer, may be as large as one project team or research group can reasonably accomplish.. Of course, those semantics will show up in the proof of the claim !. The authors organize their proof, in Coq, as follows.. ( Items marked • are either completed or nearly so ; items marked ◦ are in the early stages ; my principal coauthors on this research ( in rough chronological order ) are Sandrine Blazy, Aquinas Hobor, Robert Dockins, Lennart Beringer, and Gordon Stewart.. The authors specify an expressive program logic for source-language programs ; ◦ they instrument the static analyzer to emit witnesses in the form of invariants ; ◦ they reimplement just the core of the static analyzer ( invariant checker, not invariant inference engine ) and prove it correct w. r. t the program logic ; • they specify a decorated operational semantics for source-language programs ; • they prove the soundness of the program logic w. r. t. the decorated semantics ; • they specify an angelic operational semantics ; • they prove a correspondence between executions of the decorated and the angelic semantics ; ?. The authors prove the correctness of the optimizing compiler w. r. t. the angelic operational semantics of the source and machine languages ;. The authors specify the observable behavior of a concurrent program ( or of a single thread of that program ) as its input-output behavior, so that the statement Program p matches specification S can be expressed independently of the semantics of the programming language in which p is written, or of the machine language.
read more
2. What is the way the permissionchange is calculated in the decorated semantics?
The way the permissionchange ∆π is calculated, in the decorated semantics, is that R is fetched from the state and (classically, not constructively) evaluated.
read more
3. Why is the operational semantics invisible in the CompCert bisimulations?
The fact that the operational semantics is angelic is almost invisible in the CompCert bisimulations, because the angel is consulted only at certain of the external function calls, and never during ordinary computation steps corresponding to instructions emitted by the compiler.
read more
4. Why did the authors choose C minor as a target language for VST?
The authors chose to use C minor (instead of C light) as the target for VST, for two reasons: C minor is more friendly to Hoare-style reasoning as there are no side effects inside expressions;2 and C minor can be used as a target language from source languages such as ML or Java.
read more