Correct optimization can change the behavior of an incorrect program; therefore at times it is necessary to debug optimized code. However, optimizing compilers produce code that impedes source-level debugging. Optimization can cause an inconsistency between where the user expects a breakpoint to be located and the breakpoint's actual location. This article describes a mapping between statements and breakpoint locations that ameliorates this problem. The mapping enables debugger behavior on optimized code that approximates debugger behavior on unoptimized code sufficiently closely for the user to use traditional debugging strategies. Optimization can also cause the value of a variable to be noncurrent —to differ from the value that would be predicted by a close reading of the source code. This article presents a method of determining when this has occurred, and shows how a debugger can describe the relevant effects of optimization. The determination method is more general than previously published methods; it handles global optimization and many flow graph transformations, and it is not tightly coupled to optimizations performed by a particular compiler. Necessary compiler support is also described.

When attempting to debug optimized programs, most debuggers may give misleading information about the value of variables at breakpoints.Hennessy proposed a set of algorithms for generating optimized code and determining when, in the generated code, the reported values would be misleading-and under certain circumstances actually recovering the "expected" value of the variable (i.e., one that would not be misleading).We point out where the assumptions made by Hennessy need to be revised due to advances in compiler and debugger technology, and give references for current work on this revised problem.