Re: 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.
#
# * Is DWARF2, whatever that is, going to solve that problem? When?


Version 2 of the DWARF debugging information format (DWARF2) goes a
long way to allowing useful debugging of optimized code. For example,
DWARF2 has the notion of "location lists". In many debugging
information formats it is only possible to provide one machine
location for a particular source-level variable. On the other hand,
an optimizer might initially place a local variable in a machine
register, spill it onto the stack at some point, and then put it back
in a different machine register later in the code. A DWARF2 location
list can contain this sort of information by providing a number of
mappings from program counter ranges to machine locations.


# * 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?


It is necessary to keep a source location for each instruction.
DWARF2 makes this somewhat practical by providing a space-efficient
encoding for this sort of information, requiring little information
for the common cases, and requiring more information when significant
code motion has take place.
--

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