|
HP OpenVMS Systems Documentation |
|
OpenVMS Debugger Manual
Chapter 14
|
%DEBUG-W-UNALLOCATED, entity X was not allocated in memory
(was optimized away)
%DEBUG-W-NOVALATPC, entity X does not have a value at the
current PC
|
The following Pascal example shows how this could happen:
PROGRAM DOC(OUTPUT);
VAR
X,Y: INTEGER;
BEGIN
X := 5;
Y := 2;
WRITELN(X*Y);
END.
|
If you compile this program with the /NOOPTIMIZE (or equivalent) qualifier, you obtain the following (normal) behavior when debugging:
$ PASCAL/DEBUG/NOOPTIMIZE DOC
$ LINK/DEBUG DOC
$ DEBUG/KEEP
.
.
.
DBG> RUN DOC
.
.
.
DBG> STEP
stepped to DOC\%LINE 5
5: X := 5;
DBG> STEP
stepped to DOC\%LINE 6
6: Y := 2;
DBG> STEP
stepped to DOC\%LINE 7
7: WRITELN(X*Y);
DBG> EXAMINE X,Y
DOC\X: 5
DOC\Y: 2
DBG>
|
If you compile the program with the /OPTIMIZE (or equivalent) qualifier, because the values of X and Y are not changed after the initial assignment, the compiler calculates X*Y, stores that value (10), and does not allocate storage for X or Y. Therefore, after you start debugging, a STEP command takes you directly to line 7 rather than line 5. Moreover, you cannot examine X or Y:
$ PASCAL/DEBUG/OPTIMIZE DOC
$ LINK/DEBUG DOC
$ DEBUG/KEEP
.
.
.
DBG> RUN DOC
.
.
.
DBG> EXAMINE X,Y
%DEBUG-W-UNALLOCATED, entity X was not allocated in memory
(was optimized away)
DBG> STEP
stepped to DOC\%LINE 7
7: WRITELN(X*Y);
DBG>
|
In contrast, the following lines show the unoptimized code at the WRITELN statement:
DBG> STEP
stepped to DOC\%LINE 7
7: WRITELN(X*Y);
DBG> EXAMINE/OPERAND .%PC
DOC\%LINE 7: MOVL S^#10,B^-4(FP)
B^-4(FP) 2146279292 contains 62914576
DBG>
|
Several methods of optimizing consist of performing operations in a sequence different from the sequence specified in the source code. Sometimes code is eliminated altogether.
As a result, the source code displayed by the debugger does not correspond exactly to the actual code being executed.
The following example depicts a segment of source code from a Fortran program as it might appear on a compiler listing or in a screen-mode source display. This code segment sets the first ten elements of array A to the value 1/X.
Line Source Code ---- ----------- 5 DO 100 I=1,10 6 A(I) = 1/X 7 100 CONTINUE |
Optimization may produce the following scenario: As the compiler processes the source program, it determines that the reciprocal of X need only be computed once, not 10 times as the source code specifies, because the value of X never changes in the DO loop. The compiler thus may generate optimized code equivalent to the following code segment:
Line Optimized Code Equivalent
---- -------------------------
5 TEMP = 1/X
DO 100 I=1,10
6 A(I) = TEMP
7 100 CONTINUE
|
Depending on the compiler implementation, the moved code may be associated with the first line of the loop or may retain its original line number (common on Alpha systems).
If a discrepancy occurs, it is not obvious from looking at the displayed source line. Furthermore, if the computation of 1/X were to fail because X is 0, it would appear from inspecting the source display that a division by 0 had occurred on a source line that contains no division at all.
This kind of apparent mismatch between source code and executable code
should be expected from time to time when you debug optimized programs.
It can be caused not only by code motions out of loops, as in the
previous example, but by a number of other optimization methods as well.
14.1.3 Semantic Stepping (Alpha Only)
Semantic stepping (available only on Alpha systems) makes stepping through optimized code less confusing. The semantic-stepping mode complements the traditional step-by-line and step-by-instruction modes. There are two commands for semantic stepping: SET STEP SEMANTIC_EVENT and STEP/SEMANTIC_EVENT.
One problem of stepping through optimized code is that the apparent source program location "bounces" back and forth with the same line often appearing again and again. Indeed, sometimes the forward progress in STEP LINE mode averages barely more than one instruction per STEP command.
This problem is addressed through annotating instructions that are semantic events. Semantic events are important for two reasons:
A semantic event is one of the following:
It is important to understand that not every assignment, transfer of control, or call is necessarily a semantic event. The major exceptions are as follows:
SET STEP SEMANTIC_EVENT Command
The SET STEP SEMANTIC_EVENT command establishes the default stepping mode as semantic.
STEP/SEMANTIC_EVENT, or simply STEP when semantic mode is in effect, causes a breakpoint to be set at the next semantic event, whether an assignment, a transfer of control, or a call. Execution proceeds to that next event. Parts of any number of different lines/statements may be executed along the way without interfering with progress. When the semantic event is reached (that is, when the instruction associated with that event is reached but not yet executed), execution is suspended (similar to reaching the next line when STEP/LINE is used).
The comments in the following C program, doct2, point out some considerations for optimization:
#include <stdio.h>
#include <stdlib.h>
int main(unsigned argc, char **argv) {
int w, x, y, z=0;
x = atoi(argv[1]);
printf("%d\n", x);
x = 5;
y = x;
if (y > 2) { /* always true */
printf("y > 2");
}
else {
printf("y <= 2");
}
if (z) { /* always false */
printf("z");
}
else {
printf("not z");
}
printf("\n");
}
|
Contrast the following two examples, which show stepping by line and stepping by semantic event through the optimized doct2 program:
$ doct2:=$sys$disk:[]doct2
$ doct2 6
Debugger Banner and Version Number
Language:: Module: Doct2: GO to reach DBG> go
break at routine DOCT2\main
654: x = atoi(argv[1]);
DBG> step
stepped to DOCT2\main\%LINE 651
651: int main(unsigned argc, char **argv) {
DBG> step
stepped to DOCT2\main\%LINE 654
654: x = atoi(argv[1]);
DBG> step
stepped to DOCT2\main\%LINE 651
651: int main(unsigned argc, char **argv) {
DBG> step
stepped to DOCT2\main\%LINE 654
654: x = atoi(argv[1]);
DBG> step
stepped to DOCT2\main\%LINE 655
655: printf("%d\n", x);
DBG> step
stepped to DOCT2\main\%LINE 654
654: x = atoi(argv[1]);
DBG> step
stepped to DOCT2\main\%LINE 655
655: printf("%d\n", x);
DBG> step
6
stepped to DOCT2\main\%LINE 661
661: printf("y > 2");
DBG> step
y > 2
stepped to DOCT2\main\%LINE 671
671: printf("not z");
DBG> step
not z
stepped to DOCT2\main\%LINE 674
674: printf("\n");
DBG> step
stepped to DOCT2\main\%LINE 675
675: }
DBG> step
'Normal successful completion'
DBG>
|
$ doct2:=$sys$disk:[]doct2
$ doct2 6
Debugger Banner and Version Number
Language:: Module: Doct2: GO to reach DBG> set step semantic_event
DBG> go
break at routine DOCT2\main
654: x = atoi(argv[1]);
DBG> step
stepped to DOCT2\main\%LINE 654+8
654: x = atoi(argv[1]);
DBG> step
stepped to DOCT2\main\%LINE 655+12
655: printf("%d\n", x);
DBG> step
6
stepped to DOCT2\main\%LINE 661+16
661: printf("y > 2");
DBG> step
y > 2
stepped to DOCT2\main\%LINE 671+16
671: printf("not z");
DBG> step
not z
stepped to DOCT2\main\%LINE 674+16
674: printf("\n");
DBG> step
stepped to DOCT2\main\%LINE 675+24
675: }
DBG> step
stepped to DOCT2\__main+104
DBG> step
'Normal successful completion'
DBG>
|
Notice that the semantic stepping behavior is much smoother and more straightforward than the stepping-by-line example. Further, semantic stepping results in stopping at significant points of the program. In general, semantic stepping significantly reduces or eliminates the confusion of "bouncing" around the code nonsequentially, which characteristically happens with stepping by line through optimized code. Although some reordering of the source program may be done to take advantage of better execution characteristics, generally the flow is from top to bottom.
The granularity of stepping is different between stepping by line and
stepping semantically. Sometimes it is greater, sometimes smaller. For
example, a statement that would by its semantic nature constitute a
semantic event will not show up with semantic stepping if it has been
optimized away. Thus, the semantic region will span across several
lines, skipping the line that has been optimized away.
14.1.4 Use of Registers
A compiler might determine that the value of an expression does not change between two given occurrences and might save the value in a register. In such cases, the compiler does not recompute the value for the next occurrence, but assumes the value saved in the register is valid.
If, while debugging a program, you use the DEPOSIT command to change the value of the variable in the expression, the corresponding value stored in the register might not be changed. Thus, when execution continues, the value in the register might be used instead of the changed value in the expression, which will cause unexpected results.
In addition, when the value of a nonstatic variable (see Section 3.4.3)
is held in a register, its value in memory is generally invalid;
therefore, a spurious value might be displayed if you enter the EXAMINE
command for a variable under these circumstances.
14.1.5 Split-Lifetime Variables
In compiling with optimization, the compiler sometimes performs split-lifetime analysis on a variable, "splitting" it into several independent subvariables that can be independently allocated. The effect is that the original variable can be thought to reside in different locations at different points in time --- sometimes in a register, sometimes in memory, and sometimes nowhere. It is even possible for the different subvariables to be simultaneously active.
On Alpha processors, in response to the EXAMINE command, the debugger tells you at which locations in the program the variable was defined. When the variable has an inappropriate value, this location information can help you determine where the value of the variable was assigned. (The /DEFINITIONS qualifier enables you to specify more or fewer than the default five locations.)
Split-lifetime analysis applies only to scalar variables and parameters. It does not apply to arrays, records, structures, or other aggregates.
Examples of Split-Lifetime Processing
The following examples illustrate the use of split-lifetime processing. For the first example, a small C program, the numbers in the left column are listing line numbers.
385 doct8 () {
386
387 int i, j, k;
388
389 i = 1;
390 j = 2;
391 k = 3;
392
393 if (foo(i)) {
394 j = 17;
395 }
396 else {
397 k = 18;
398 }
399
400 printf("%d, %d, %d\n", i, j, k);
401
402 }
|
When compiled, linked, and executed for debugging, the optimized program results in this dialogue:
$ run doct8 |
.
.
.
DBG> step/into
stepped to DOCT8\doct8\%LINE 391
391: k = 3;
DBG> examine i
%W, entity 'i' was not allocated in memory (was optimized away)
DBG> examine j
%W, entity 'j' does not have a value at the current PC
DBG> examine k
%W, entity 'k' does not have a value at the current PC
|
Note the difference in the message for the variable i compared to j or k. The variable i was not allocated in memory (registers, core, or otherwise) at all, so there is no point in ever trying to examine its value again. By contrast, j and k do not have a value "at the current PC" here; somewhere later in the program they will.
Stepping one more line results in this:
DBG> step
stepped to DOCT8\doct8\%LINE 385
385: doct8 () {
|
This looks like a step backward --- a common phenomenon in optimized (scheduled) code. (This problem is dealt with by "semantic stepping mode," discussed in Section 14.1.2.) Continuing to step results in this:
DBG> step 5
stepped to DOCT8\doct8\%LINE 391
391: k = 3;
DBG> examine k
%W, entity 'k' does not have a value at the current PC
DBG> step
stepped to DOCT8\doct8\%LINE 393
393: if (foo(i)) {
DBG> examine j
%W, entity 'j' does not have a value at the current PC
DBG> examine k
DOCT8\doct8\k: 3
value defined at DOCT8\doct8\%LINE 391
|
Here j is still undefined, but k now has a value, namely 3. That value was assigned at line 391.
Recall from the source that j was assigned a value before k (at line 390), but that has yet to show up. Again, this is common with optimized (scheduled) code.
DBG> step
stepped to DOCT8\doct8\%LINE 390
390: j = 2;
|
Here the value of j appears. Thus:
DBG> examine j
%W, entity 'j' does not have a value at the current PC
DBG> step
stepped to DOCT8\doct8\%LINE 393
393: if (foo(i)) {
DBG> examine j
DOCT8\doct8\j: 2
value defined at DOCT8\doct8\%LINE 390
|
Skipping ahead to the print statement at line 400, examine j again.
DBG> set break %line 400
DBG> g
break at DOCT8\doct8\%LINE 400
400: printf("%d, %d, %d\n", i, j, k);
DBG> examine j
DOCT8\doct8\j: 2
value defined at DOCT8\doct8\%LINE 390
value defined at DOCT8\doct8\%LINE 394
|
Here there is more than one definition location given for j. Which applies depends on which path was taken in the IF clause. If a variable has an apparently inappropriate value, this mechanism provides a means to take a closer look at those places, and only those, where that value might have come from.
You can use the SHOW SYMBOL/ADDRESS command to display the split-lifetime information for a symbol, as in the following example:
DBG> show symbol/address j
data DOCT8\doct8\j
between PC 131128 and 131140
PC definition locations are at: 131124
address: %R3
between PC 131144 and 131148
PC definition locations are at: 131140
address: %R3
between PC 131152 and 131156
PC definition locations are at: 131124
address: %R3
between PC 131160 and 131208
PC definition locations are at: 131124, 131140
address: %R3
|
The variable j has four lifetime segments. The PC addresses are the result of linking the image, and the comments relate them to line numbers in the source program.
On Alpha systems, the debugger tracks and reports which assignments and definitions might have provided the displayed value of a variable. This additional information can help you cope with some of the effects of code motion and other optimizations --- effects that cause a variable to have a value coming from an unexpected place in the program.
EXAMINE/DEFINITIONS Command (Alpha Only)
For a split-lifetime variable, the EXAMINE command not only displays the value of the active lifetime, it also displays the lifetime's definition points. The definition points are places where the lifetime could have received an initial value (if there is only one definition point, then that is the only place.)
There is more than one definition point if a lifetime's initial value can come from more than one place. In the previous example when the program is suspended at the printf, examining j results in the following:
DBG> examine j
DOCT8\doct8\j: 2
value defined at DOCT8\doct8\%LINE 390
value defined at DOCT8\doct8\%LINE 394
|
Here, the lifetime of j has two definition points, because the value could have come from either line 390 or line 394, depending on whether or not the expression at line 393 was TRUE.
By default, up to five definition locations are displayed when the contents of a variable are examined. You can specify the number of definition locations to display with the /DEFINITIONS=n qualifier, as in the following example:
DBG> EXAMINE/DEFINITIONS=74 FOO |
Note that the minimum abbreviation is /DEFI.
If you want a default number of definitions other than five, you can use a command definition like the following:
DBG> DEFINE/COMMAND E = "EXAMINE/DEFINITIONS=100" |
If the /DEFINITIONS qualifier is set to 100, and the split-lifetime variable examined has 120 definition points, the debugger displays the 100 as specified, and then reports:
there are 20 more definition points |
| Previous | Next | Contents | Index |