Re: Debugging of optimized code

copperma@grenoble.rxrc.xerox.com (Max Copperman) writes:
> Milton Barber's nice example of the kinds of things optimization can do
> reminds me that I left out an important idea in my description of how
> to provide a clear way of describing the "current location in code" in
> source terms.
>
> The thing to realize is that most of the instructions generated from a
> statement are not of interest to the human who is debugging. If I want
> to break at "x = some complicated expression", it is the instruction
> that inplements the assignment that I want to break at. The fact that
> the computation of x's address was moved out of a loop, that CSE was
> done on part of the expression, that the loads of the operands in the
> expression were scheduled arbitrarily far above the assignment---these
> are all irrelevant to me the vast majority of the time.


I'd have to disagree with this assertion. The reason I want to stop at an
assignment statement is usually so I can see what the input values of the
computation are. If they are wrong, I may wish to change them to see if
that fixes the bug. If the debugger stops *after* the computation, then


    a) I cannot change the inputs and affect the assignment.


    b) If this assignment is the last use of one or more of the input
          variables, then the input values may not even be around any longer
          because the register where they were stored was reused during the
          computation.


> Each side effect visible to the programmer must be mapped to the
> instruction or instructions that implement it. A simple assignment would
> be mapped to the instruction(s) that finally puts the right-hand-side
> value into the left-hand-side location (whether memory or a register).
> Instructions that are part of the address computation of the
> left-hand-side or the value computation of the right-hand-side will not
> show up in this map, except if they are also part of the storing of the
> result.


Okay, so what if they *are* part of the storing? On a RISC machine, it is
quite common to compute the result in the final destination register.


This would mean that exactly what part of the computation had taken place
when you stopped at the assignment would be indeterminate.


> When mapping from the source code to the machine code, you should map
> from entities of interest to the programmer


Ah, but how do you know what is of interest to the programmer? Not even
the programmer knows until he needs to debug something, and then it's too
late!


--
Bill Leonard
Harris Computer Systems Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
Bill.Leonard@mail.hcsc.com
--

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