Re: Debugging of optimized code

Milton Barber <milt@Eng.Sun.COM> writes:


> [what can the poor debugger do after an optimizer has mangled the code?]


>I think a key part of a solution to this problem is recognition of
>the fact that, above a certain level of optimization, the very idea
>of a positional correspondence between the original source program
>and the object program is broken so many transformations have
>occurred to the program that any attempt to utilize this
>correspondence will mislead more than it will help.


While you're right in general (unfortunately), the situation isn't
quite as hopeless, at least for some languages. Often, the compiler
can accurately describe the program state at least at *some* points in
the program (e.g., at non-inlined calls). In some pointer-safe
languages (e.g., Smalltalk and Self), these points turn out to be the
only ones where a run-time error can actually happen. Thus, a program
can only be suspended by an error at these "interrupt points", and as
long as you can describe the state there you have accurate
source-level debugging.


The second idea is to use unoptimized code to provide the rest of the
debugging functionality. Whenever needed, the current program state
is read from the optimized procedure and copied into (possibly many)
unoptimized procedures. (You could also use an interpreter, of
course.) Setting a breakpoint involves invalidating (or recompiling)
all code containing inlined copies of the corresponding source
location.


I have implemented such a scheme in Self (using runtime compilation, a
big help) and it works quite nicely, providing full (i.e., always
accurate) debugging in the presence of many optimizations. (See
http://self.stanford.edu.)


Of course, deoptimization is no panacea. For example, it relies on
the compiler being correct, it can't hide all optimizations, and it
probably doesn't work as well for non-pointer-safe languages because
every memory access can potentially fail. I just wanted to observe
that the situation isn't hopeless, and I think today's debuggers could
still be improved quite a bit. For example, there's no fundamental
reason why you shouldn't be able to set a breakpoint in a method even
if that method was inlined in many places.


-Urs
--
----------------------------------------------------------------------------
Urs Hoelzle urs@cs.ucsb.edu http://www.cs.ucsb.edu/~urs
Computer Science Dept., University of California, Santa Barbara, CA 93106
--

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