``Debug products have been available for many years. On smaller computing systems, the users swear by these products, and strongly depend on them. In larger systems, they seem to swear at them, and the usage is spotty.''[Sei83]
According to Max Copperman in [Cop93], ``[d]ebugging is the art of determining, from a program's `misbehavior', the source constructs responsible for the misbehavior.'' In the absence of appropriate tools, this misbehavior and its cause must be inferred from the output of the executing program. In the case of high-level languages where the ``semantic gap'' beween source program and generated code is significant, this process is difficult, time-consuming, and error-prone.
Experience with debugging tools designed for imperative-procedural sequential programs has shown that the cost of providing source-level debugging support is greatly outweighed by the benefits in programmer productivity. As the semantic gap becomes increasingly complex as a result of code restructuring and optimizations, the benefit of debug tools capable of bridging this gap becomes more evident. Therefore, the dearth of usable interactive debuggers for high-level parallel programming languages is more attributable to the technical difficulty of building such tools than to a lack of demand for the functionality they provide.
In 1983, Seidner and Tindall[Sei83] proposed some requirements for a canonical interactive debugger. Aside from standard execution control and symbol name resolution, these requirements included such features as flowback analysis, conditional breakpoints, and support for debugging optimized code. Some of these features are easily provided in a sequential debugger, but most raise complex problems in the realm of parallel debugging. Solutions for many of these problems have been proposed, but usage of the resulting products remains ``spotty.''