Re: Debugging of optimized code

SAND_DUANE@tandem.com wrote:
: 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
-snip-


: I'm asking for reliable debugging support of these essentials:
: * Where am I, in the program?
This is reasonably simple to provide - the source line has to be carried
through all the intermediate forms in the compiler. However it can be quite a
bit of work to ensure it is transferd through all the transformations.


: * Stmt breakpoints are possible at some (if not most) statement
: boundaries, with at least one point avaiable in each basic block.
More difficult - how do you track the start of a statement. If you have a
marker for the statement start in the intermediate forms then these can be
lost or moved to stupid places. Another approach is to take the instruction
(from those that are generated from the statement) with the lowest address as
being the start of the statement. This might not be what you expect. Consider
if part of a statement is hoisted out of a loop, the breakpoint for that
statement would occur before the enclosing loop! You might have to forbid
some optimizations to get breakpoints.


Note also there is a conflict between the requirements of telling where one
is in the program (object->source location) and between telling where to set
breakpoints (source->object location). Most debug formats only have one set
of information for mapping between locations between source and object. The
implementor has to decide which use the most important and set it up for that.


: * Displaying of variable values, with warning if the value is
: not current for the current claimed stmt location.
Not so sure about this one. Stuff in registers would be difficult to find. It
might be possible to describe it to the debbufger but it would take a lot
of debug information.
: * Stack traceback of callers.
This is basically a matter of knowing where one is. It must also be possible
to identify the stack frames. This is usually easy using the frame pointer.
Not all processors provide a frame pointer in hardware so when it is done
in software trace back could be difficult if the compiler optimizes out the
use of a frame pointer when it does not need it (eg when no variables not in
registers). The cost of always providing a frame pointer is small so it
is reasonable to always do it.


-snip-


: Do any of your optimizing compilers have a switch to support this
: kind of compromise?
Apollo (Now part of HP) and DEC VAX compilers (both CISC machines) will
support source location with optimization but not symbolic debug of variables.
I have seen compilers for (semi-RISC) embeded processors which do the same.
--
Stephen Baynes baynes@mulsoc2.serigate.philips.nl
Philips Semicondutors Ltd
Southampton
United Kingdom
--

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