Debugging of optimized code

A major irritant with all the optimizing compilers I know of, is that
symbolic source-level debugging of the optimized version of released
products becomes impossible or very very flaky.


The programmers at my company (Tandem Computers) are very frustrated
with this. With our prior range of stack-oriented CISC machines, the
compilers could do so little to the code that they didn't bother to
do much, and so symbolic debugging support and post-mortem analysis
was excellent in all released products. With the MIPS compilers we
now use, anyone trying to recreate a problem in its original context
needs to learn how to puzzle out what the compiler did across an
entire procedure, at the machine level. The standard answer seems
to be to rebuild the product with ALL optimizations off, and try to
recreate the customer's problem in that version.


Is anyone doing much better than this?
Is the industry satisfied with this?
Do we all have to learn to be codegen & optimizer experts?


I'm interested in hearing
    * Are improvements in this area practical?
    * Are there any production compilers now in use or under further
        development, which support reliable symbolic debugging of
        maximally or not-quite-maximally optimized code?
    * Have any research compilers solved this problem adequately?
    * Are we fundamentally limited by the existing "standard" codefile
        debugger info formats?
    * Is DWARF2, whatever that is, going to solve that problem? When?
    * What are some clear ways of describing the "current location
        in code" in source terms, when code motion and cross-statement
        scheduling has blurred the statement boundaries?
    * Just how much added performance is gained, by those code
        optimizations that make source-level debugging particularly hard?


For the 10% of our code that determines system-level performance and
system prices, and hence our profits and salaries, Tandem's
programmers are willing to forgo symbolic debugging in exchange for
highest possible performance. But for the other 90% of our shipped
code that executes less often, Tandem would be very happy to trade
10-20% of the performance of those pieces, in exchange for reliable
symbolic debugging (and for more reliable compilers). Our customers'
application programmers would, also.


Clearly, code subjected to inter-statement common subexpr elimination
can't support debug-time modification of variables, or manually forced
branches to arbitrary unlabelled statements. So "totally unoptimized"
code is needed for full use of all debugger commands. But those
debugger features aren't essential in shipped products.


I'm asking for reliable debugging support of these essentials:
    * Where am I, in the program?
    * Stmt breakpoints are possible at some (if not most) statement
        boundaries, with at least one point avaiable in each basic block.
    * Displaying of variable values, with warning if the value is
        not current for the current claimed stmt location.
    * Stack traceback of callers.


These essentials are supported in Tandem's object code translator from
stack machine CISC code to MIPS code (described in ASPLOS-V). This
was done by forgoing optimizations that would confuse the CISC
debugger, eg assignments to memory variables are never moved or
deleted. The debugger was told about statement boundaries that
disappeared.


We wish we had an analogous feature in the MIPS native mode
compilers.


Do any of your optimizing compilers have a switch to support this
kind of compromise?


      -- Duane Sand, Tandem Computers
            sand_duane@tandem.com
--

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