A Verified CompCert Front-End for a Memory Model Supporting Pointer Arithmetic and Uninitialised Data

TLDR: This work proposes a novel memory model for CompCert which gives a defined semantics to challenging features such as bitwise pointer arithmetics and access to uninitialised data and shows how to tame the expressive power of the normalisation so that the memory model fits the proof framework of CompCert.

Abstract: The CompCert C compiler guarantees that the target program behaves as the source program. Yet, source programs without a defined semantics do not benefit from this guarantee and could therefore be miscompiled. To reduce the possibility of a miscompilation, we propose a novel memory model for CompCert which gives a defined semantics to challenging features such as bitwise pointer arithmetics and access to uninitialised data. We evaluate our memory model both theoretically and experimentally. In our experiments, we identify pervasive low-level C idioms that require the additional expressiveness provided by our memory model. We also show that our memory model provably subsumes the existing CompCert memory model thus cross-validating both semantics. Our memory model relies on the core concepts of symbolic value and normalisation. A symbolic value models a delayed computation and the normalisation turns, when possible, a symbolic value into a genuine value. We show how to tame the expressive power of the normalisation so that the memory model fits the proof framework of CompCert. We also adapt the proofs of correctness of the compiler passes performed by CompCert’s front-end, thus demonstrating that our model is well-suited for proving compiler transformations.

Figures

Fig. 6: Lock-step forward simulation diagram

Fig. 10: Injecting local variables into a stack block

Fig. 15: Definition of the new allocation operation

Fig. 2: Storing information in spare bits of pointers

Fig. 14: The symbolic memory model

Fig. 18: Semantics of Clight with symbolic values (excerpt)

Frequently asked questions

Q1. What have the authors contributed in "A verified compcert front-end for a memory model supporting pointer arithmetic and uninitialised data" ?

To reduce the possibility of a miscompilation, the authors propose a novel memory model for CompCert which gives a defined semantics to challenging features such as bitwise pointer arithmetics and access to uninitialised data. In their experiments, the authors identify pervasive low-level C idioms that require the additional expressiveness provided by their memory model. The authors also show that their memory model provably subsumes the existing CompCert memory model thus cross-validating both semantics. The authors show how to tame the expressive power of the normalisation so that the memory model fits the proof framework of CompCert. The authors also adapt the proofs of correctness of the compiler passes performed by CompCert ’ s front-end, thus demonstrating that their model is well-suited for proving compiler transformations. 

Q2. What have the authors stated for future works in "A verified compcert front-end for a memory model supporting pointer arithmetic and uninitialised data" ?

As future work, the authors shall study how to adapt the back-end of CompCert. In spite of the remaining difficulties, the authors believe that the full CompCert compiler can be ported to their novel memory model. This would improve further the confidence in the generated code. 

Q3. Why does the simulation require that the program have defined semantics in SClight?

Because the memory is infinite is CClight, this program has defined semantics and the simulation the authors are trying to prove requires that this program have defined semantics in SClight as well. 

Q4. How does the proof accommodate for the size of the variables?

Note that to accommodate for alignment and padding the stack frame might allocate more bytes than the size of the variables themselves. 

Q5. What is the solution to normalise symbolic values?

The solution is to normalise symbolic values in a more eager manner i.e. before any write into memory or into a register, and only keep symbolic values when the normalisation fails. 

Q6. How do the authors decode a list of smemvals?

This is done by converting each smemval into a symbolic value, and then concatenating those symbolic values: the concat function recovers the 64-bit bitvector that represents the original symbolic value, and the decode function applies the from_bits function to the result of concat with the appropriate chunk. 

Q7. What is the meaning of normalising a symbolic value into a pointer?

Algorithm 2 explains how the authors normalise symbolic values into pointers, and is based on the fact that a symbolic value sv can only have ptr(b, o) as normalisation if b appears syntactically in sv. 

Q8. What is the function that checks that all the blocks fit in memory?

The algorithm checks that all the blocks fit in memory by running the function fresh_addr which constructs as witness a valid concrete memory cm and returns the first fresh address addr. 

Q9. Why does the function is_aligned simplify to 3 == 0?

Because of the alignment constraints on the block b, this symbolic value simplifies to 3 == 0, which in turn evaluates to int(0). 

Q10. Why are certain undefined behaviours introduced in C?

certain undefined behaviours of C were introduced on purpose to ease either the portability of the language across platforms or the development of efficient compilers. 

Q11. what is the motivation of the current handling of bit-fields in compcert?

Another motivation is illustrated by the current handling of bit-fields in CompCert: they are emulated in terms of bit-level operations by an elaboration pass preceding the formally-verified front-end.