Using meta-level compilation to check FLASH protocol code (2000)
| Venue: | ACM SIGPLAN Notices |
| Citations: | 17 - 5 self |
BibTeX
@ARTICLE{Chou00usingmeta-level,
author = {Andy Chou and Benjamin Chelf and Dawson Engler and Mark Heinrich},
title = {Using meta-level compilation to check FLASH protocol code},
journal = {ACM SIGPLAN Notices},
year = {2000}
}
Years of Citing Articles
OpenURL
Abstract
Building systems suchasOSkernels and embedded software is di cult. An important source of this di culty is the numerous rules they must obey: interrupts cannot be disabled for \too long, " global variables must be protected by locks, user pointers passed to OS code must be checked for safety before use, etc. A single violation can crash the system, yet typically these invariants are unchecked, existing only on paper or in the implementor's mind. This paper is a case study in how system implementors can use a new programming methodology, metalevel compilation (MC), to easily check suchinvariants. It focuses on using MC to check for errors in the code used to manage cache coherence on the FLASH shared memory multiprocessor. The only real practical method known for verifying such code is testing and simulation. We showthat simple, system-speci c checkers can dramatically improve this situation by statically pinpointing errors in the program source. These checkers can be written by implementors themselves and, by exploiting the system-speci c information this allows, can detect errors unreachable with other methods. The checkers in this paper found 34 bugs in FLASH code despite the care used in building it and the years of testing it has undergone. Many of these errors fall in the worst category of systems bugs: those that show up sporadically only after days of continuous use. The case study is interesting because it shows that the MC approach nds serious errors in well-tested, non-toy systems code. Further, the code to nd such bugs is usually 10-100 lines long, written in a few hours, and exactly locates errors that, if discovered during testing, would require several days of investigation by an experienced implementor. The paper presents8checkers we wrote, their applicationto ve di erent protocol implementations, and a discussion of the errors that we found. 1







