Abstract
Compiler correctness, in its simplest form, is defined as the inclusion of the set of traces of the compiled program in the set of traces of the original program. This is equivalent to the preservation of all trace properties. Here, traces collect, for instance, the externally observable events of each execution. However, this definition requires the set of traces of the source and target languages to be the same, which is not the case when the languages are far apart or when observations are fine-grained. To overcome this issue, we study a generalized compiler correctness definition, which uses source and target traces drawn from potentially different sets and connected by an arbitrary relation. We set out to understand what guarantees this generalized compiler correctness definition gives us when instantiated with a non-trivial relation on traces. When this trace relation is not equality, it is no longer possible to preserve the trace properties of the source program unchanged. Instead, we provide a generic characterization of the target trace property ensured by correctly compiling a program that satisfies a given source property, and dually, of the source trace property one is required to show to obtain a certain target property for the compiled code. We show that this view on compiler correctness can naturally account for undefined behavior, resource exhaustion, different source and target values, side channels, and various abstraction mismatches. Finally, we show that the same generalization also applies to many definitions of secure compilation, which characterize the protection of a compiled program linked against adversarial code.
Highlights
Compiler correctness is an old idea [46, 49, 50] that has seen a significant revival in recent times
We show that if is surjective, i.e., д
Proof of Theorem 7.1 ( ). (See theorem extra_target_RTCt in MoreTargetEventsExample.v, mechanizing a slightly simplified model.) By definition of RTC∼, we need to find a source context and source trace given a source program, target context, and target trace related by compilation and program semantics: This instantiation is simple, since the trace relation is a function from target traces to source traces, and it is easy to clean target contexts to produce equivalent source context without target-only events
Summary
Compiler correctness is an old idea [46, 49, 50] that has seen a significant revival in recent times. TPσquantifies over all target trace properties and uses σto obtain the corresponding source properties We prove that these two definitions are equivalent to CC∼, yielding a novel trinitarian view of compiler correctness (Figure 1). We use CC∼ compilers of various complexities to illustrate that our view on compiler correctness naturally accounts for undefined behavior (Section 4.1), resource exhaustion (Section 4.2), different source and target values (Section 4.3), and differences in the granularity of data and observable events (Section 4.4). We expect these ideas to extend to other discrepancies between source and target traces. This development has around 10K lines of code and is available at the following address: https://github.com/secure-compilation/different_traces
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Free) 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a call
