During optimization, the compiler repositions and reorganizes instructions derived from your source code, resulting in more efficient execution of the program. Because the information in the optimized code has been rearranged, the debugger cannot always identify the source code that corresponds to a set of instructions. For this reason, it is advisable to debug your code before optimizing it whenever possible. You can enable optimization after you finish debugging.
Following are instructions for preventing optimization and suggestions for debugging optimized code, if necessary.
To prevent the compiler from optimizing code
– or –
– or –
The Project Settings dialog box appears.
You can enable optimizations after you finish debugging.
Debugging optimized code
Some bugs affect optimized code but do not affect unoptimized code. If you must debug optimized code, use the following techniques:
To see why the Disassembly window is useful, consider the following example:
for (x=0; x<10; x++)
Suppose you set a breakpoint at this line. You might expect the breakpoint to be hit 10 times. But if this code is optimized, the breakpoint is hit only once, because the compiler recognizes that the first instruction associated with this line, which assigns the value of 0 to x
, needs to execute only once. The compiler moves this instruction out of the loop. If you set a breakpoint on this source-code line, the debugger sets the breakpoint on the first instruction, which executes only once.
The instructions that compare and increment x
remain inside the loop. To set a breakpoint on these instructions, use the Disassembly window. By viewing the object code the source-code line creates, you can set a breakpoint at the appropriate instruction. You can set a breakpoint at the location where the condition is checked or the variable is incremented. You can use the Step Into or Step Over commands in the Disassembly window to step by assembly instructions, which allows greater control than stepping by source-code line.