Re: Debugging of optimized code

I have been pursuing the problem of debugging optimized code as my
thesis topic. Our research focuses on non-intrusively debugging
optimized code, i.e., we do not want to constrain the compiler's
optimizations in any way nor do want to insert additional code into
the object just to allow debugging. We have been focusing on C as the
source language being debugged and are looking at standard scalar
optimizations found in typical production compilers (e.g., instruction
scheduling, coloring register allocation, code motion, strength
reduction, dead code elim., etc.). We have implemented and are in the
process of evaluating most of our techniques in the context of an
optimizing C compiler being developed here at CMU. We are not yet
looking at parallelized code; Robert Cohn's thesis, available as CMU
tech report CMU-CS-92-204, addresses the problem of source-level
debugging of parallelized code.


In our opinion, it is important that the techniques for debugging
optimized code be non-intrusive. A version of the code that has been
compiled with less than full strength optimizations or with additional
code to allow debugging is not the fully optimized version and thus
does not fully address the problem. A vendor will ship the fully
optimized translation of a program that will not contain the
additional code or debuggable optimizations. For interactive
debugging purposes, it may be O.K. to assume that the debugger can be
somewhat intrusive by implementing additional breakpoints behind the
user's back, although doing so may change the timing behavior of the
process being debugged, thus possibly masking a bug (e.g., due to race
conditions). However, such techniques obviously don't apply in the
case of post-mortem debugging.


For an approach to have practical significance in production compiler
tool chains, we must look at popular source languages such as C,
despite the additional problems that this language's "features" may
create (e.g., pointers, undefined evaluation order, etc.).


We have found that the situation is not at all hopeless. With full
optimizations, it is generally not possible to allow debugging in the
classical sense. The debugger's functionality must be extended to
allow new forms of breakpoints to account for the re-ordering and
interleaving of statements and new responses to user queries to
account for source variables whose run-time values are either
non-existent (e.g., due to register allocation) or not as the user
expects (due to elimination or re-ordering of code).


You can find earlier results of our work concerning register
allocation and instruction scheduling in POPL'93 and PLDI'93. These
papers and some of our more recent work can be found in


http://www.cs.cmu.edu:8001/afs/cs.cmu.edu/user/ali/www/ali.html


Ali Adl-Tabatabai
School of Computer Science
Carnegie Mellon University
--

Return to the comp.compilers page.
Search the comp.compilers archives again.