Debugging "level"

Abstract

Debugging techniques originated with low-level programming languages, where the memory dump and interactive word-by-word examination of memory were the primary tools. "High-level" debugging is often no more than low-level techniques adapted to high-level languages. For example, to examine the execution of an operational specification one state at a time by setting breakpoints, is superior to doing the same thing to a machine-language program, but only because the language level has improved; the debugging remains primitive. This paper attempts a radical definition of debugging level, and illustrates it with a technique for ordering the execution of concurrent processes in a way that follows their design structure. Division of a program into a collection of cooperating processes is a means of controlling the complexity of each process. However, in execution the program--development structure is ignored, with the result that the advantages of decomposition are lost. What the designer has divided and conquered, the debugger sees as an overwhelming monolith. The technique proposed here causes the focus of execution to follow the design structure, in a way that does not require detailed user direction.