Computer program debugging in the presence of compiler synthesized variables5956512Abstract A debugger is used in an environment of optimized compiling to track both user-defined and synthesized variables so that the values of these variables at selected programmer counter addresses can be either determined or set. The tracking is primarily accomplished by the generation of various interrelated tables including a Type Scope Table, a Name Space Table, an Expression Table, a Location Range Tab and a Variable Table. These tables define the existence of variable at defined program counter ranges and provide the algebraic definitions for the synthesized variables. A programmer can efficiently debug a program produced with optimized compiling through the operations of determining variable values and setting variable values. Claims What we claim is: Description FIELD OF THE INVENTION
______________________________________
I = (I+I)*4
Load I .fwdarw. R1 Start range for I in R1
Move R1 .fwdarw. R2
Start range for I in R2
R2 = I+I R1 R2 End range for I in R2
Move #4 .fwdarw. R1
End range for I in R1
R1 = (I+I)*4 R2 R1
______________________________________
Once every instruction in the basic block is processed, the logical control flow within the block is assumed complete. If there are any ranges that are still open at that point, those ranges are closed out at the end of the basic block. The Expression Table is further defined in reference to FIG. 5. In this figure there is shown a sample of source code, a directed graph, an expression tree and a subexpression. Whenever a variable is synthesized, an expression is produced. However, synthesized variables are introduced sporadically throughout all of the phases of the compiler. Determining the expression for the synthesized variable is done by walking the directed graph backwards and creating an expression tree, as shown. The graphs shown in FIG. 5 represent the case for a redundant expression. The directed graph represent the logical structure of the two lines of source code. When the compiler finds the subexpression "3*k*(i+j)" in the directed graph, it creates a synthesized variable. The synthesized variable represents the subexpression. The expression tree is then built from the directed graph. The expression tree can be stored into a data file. FIG. 6 shows some of the entry nodes for a sample FORTRAN routine line of code illustrated below. Entry nodes are identified by the reference numerals 150, 152, 154 and 156. At entry node 154, the computation nodes 158, 160, 162, 164, 166, 168 and 170 represent the calculation of: a(i)=i * 3+x The computation nodes are used at the code generation phase to produce the machine language instructions. A further significant case in synthesized variables is that of loop induction variables. For example, two synthesized loop induction variables are created from the following code:
______________________________________
INTEGER*4 A(N)
DO I = 1, N, 5
A(I) = I+2
ENDDO
______________________________________
One synthesized variable is required to function as a pointer into the array of A. The other is for the expression I+2. These synthesized variables are introduced logically at the time of the Decycle phase as a node to be referred to as an XSECT node (described below). However, the synthesized variables are not realized until the Cycle phase. A significant aspect of the present invention is that of an XSECT node. See FIGS. 7a, 7b and 7c. Such a node has two inputs, one is a base and the other is a step. The base is the initial value for the node and the step is the increment. The logical output is a linear series of values. For example, an XSECT with a base of 3 and a step of 5 has a logical output that is the sequential series of 3, 8, 13, 18, 23, etc. Each value in the series is used during one iteration of the loop. XSECT is essentially a triplet as described in Aho et al. above at pages 643-648. The XSECT node is transformed into a synthesized variable during the Cycle phase. At that time, using the base and step of the XSECT node yields the following equation: FINAL BASE+STEP*(CURRENT LOOP ITERATION) Therefore, in accordance with the present invention, at the time of the XSECT node creation, the node is annotated with the expression that symbolizes each loop iteration. For the above example this is (I-1)/5. When both the XSECT nodes have been realized into synthesized variables, this quantity will be substituted for the current loop iteration. The synthesized variables for the XSECT nodes are defined by the expressions: ?i1=loc(A)+4*5*((I-1)/5) ?i2=3+5*(I-1)/5 These are the expressions that are emitted into the Expression Table by the compiler. Note the "4" in the first expression is the size of each element in the array A. Also, many of these values are folded together such as 4*5 is reduced to 20. Referring now to FIGS. 7a, 7b and 7c, there are provided a series of diagrams illustrating the implementation of an XSECT node, the annotations of such nodes and the transformations of these nodes into synthesized variables. Referring to FIG. 7a, there is shown the graph of the code (shown immediately above) before the Decycle process is performed. The quantities within the ovals are computation nodes. FIG. 7b is an illustration of the graph structure of FIG. 7a which has been produced after the Decycle phase. Computation nodes have been created which are identified as XSECT 1, XSECT 2 and XSECT 3. Each of these XSECT nodes is defined in FIG. 7b to have a base, a step and a symbolic annotation. One major aspect of the present invention is the annotation of the XSECT nodes as shown in FIG. 7b. The principal occurrence illustrated in FIG. 7b is that the XSECT nodes have been created from the body of the loop to perform further optimizations. Note that a loop no longer exists in FIG. 7b because the code has been decycled (all cycles removed). Referring now to FIG. 7c, there is shown the next step in the processing which is entitled "After Recycle". Many optimizations occur after decycling and before recycling. In this step, the XSECT nodes have been replaced with synthesized variables which define the XSECT nodes. The synthesized variable is initialized with the final base and incremented with the final step of XSECT. The equations are then generated using these values. XSECT 1 was removed from the graph since it does not feed anything else. The XSECT 2 and 3 compiler nodes have been transformed into synthesized variables wherein XSECT 3 has been transformed into ?i1 and XSECT 2 has been transformed into ?i2. ?i1 is a pointer to the current element in the array and must be dereferenced for a value to be stored there. (indicated by the dereference node) A further concept that is used in conjunction with the present invention is that of "expression trees". The following description represents a process for generating an expression for a synthesized variable. Each expression tree is composed of one or more expression nodes. There are many types of expression nodes and these can be grouped into five kinds. Each expression node has the following two fields. type: An enumeration of ADD, USE, SUBTRACT, MULTIPLY, CONSTANT, etc. kind: There are five kinds of expression nodes (SYMBOL, CONSTANT, OPERATOR, CONVERT, INTRINSIC). Symbol Node: This is used for a variable within the expression. It contains these fields: Pointer to Variable Table Entry Data Type Intrinsic: This is used when there is a runtime library call such as to (SINE OR SQUARE ROOT) The fields are: Enumeration of the intrinsic (SINE, COSINE, SQUARE ROOT) Parameter list to pass. This is a list of expressions. Data Type of Returned Value Constant value: This is used when there are values in the equations. The fields are: Binary value of the constant Data type of constant Operator node: Used when this is an explicit operator like ADD, SUBTRACT, NEGATE. Handles only unary and binary operators. The fields are: Operand 1 points to another expression. Operand 2 points to another expression (not necessary for a unary operation). Resulting data type. Convert node: Needed when converting between two data types. For example, it converts a floating expression to an integer expression. The fields are: The data type to convert to The data type from which you are converting The expression that is being converted For example: N+2 appears as the following: ##STR1## Each expression tree represents an expression which is stored in the Expression Table 29. An example is now presented for the process of a user operating the debugger program of the present invention. This is described in reference to the following subroutine which is identified as "FOO". 1. SUBROUTINE FOO(A, N) 2. INTEGER*4 A(N) 3. 4. DO I=1, N, 5 5. A(I)=I+2 6. ENDDO 7. 8. END The Type Scope Table includes definitions for all identifiers and their respective classes and scopes. The identifiers for the FOO routine are "FOO" which is the subroutine, "A" which is the array of integers, "I" which is the loop control integer, and "N" which is the upper bound of the array integer. All of the identifiers have the same scope of being within subroutine FOO. The Variable Table for this subroutine contains all of the variables. That is, it contains entries for "FOO", "A", "I", and "N"; however, it also contains entries for synthesized variables "?i1", "?i2", and "?i3" which were produced in the compilation process. The Expression Table for the routine FOO defines "?i1" as a pointer to the current entry into A. Applying induction variable elimination only, it has the expression: ?i1=loc(A)+4*5*((I-1)/5) The synthesized variable "?i2" is defined as the expression of I+2. It has the expression: ?i2=3+5*(I-1)/5 The loop is restructured so that there is no longer a test of I<N but a test of (I+2)<(N+2). Thus, "?i3" is a synthesized variable with the following expression: ?i3=N+2 The Location Range Table defines the location of "FOO" to be at a constant address in the code throughout the entire program. The addresses of "A" and "N" are defined to be relative to an argument pointer on the stack over the address range that is the body of the routine "FOO". "I" does not have a location since all uses to it have been optimized away. Lastly, "?i1", "?i2", and "?i3" are allocated to respective registers within the body of the loop. Therefore, if the user were at a breakpoint at line 5 and requested the value of "I", the debugger would do a look up for the identifier in the Type Scope Table to see if the identifier existed. Next, it would do a look up to the Variable Table to see how the variable is realized in the machine code. The Variable Table then points directly to the Expression Table since "I" is used in several equations. After determining that there are two equations that use "I", the program proceeds to calculate the value. First, it attempts to retrieve a value for "?i1". If it did have a value, the program then algebraically solves the expression for "I". Next, a similar operation is performed on "?i2". Since there are more equations than unknowns, the value for "I" may be inconsistent between equations. For example, this case may arise when the program is at a point between locations where both synthesized loop induction variables are incremented. If so, the user is informed about the inconsistency. If the user places a breakpoint on line 2 ›INTEGER*4 A(N)! neither "?i1" or "?i2" is active and so an informational message is generated to inform the user that the value for "I" is not available. If the user wants to assign a new value to "I" during the debugging session, "I" is checked to be consistent among all of its equations. If it is consistent, the values for "?i1" and "?i2" are calculated from the respective equations by substituting the logical new value of "I". Then, the new calculated values are assigned to those two synthesized variables. If the value is inconsistent, the user is given an error message prohibiting assignment to "I". DETAILED DESCRIPTION OF PROCESS FLOW In view of the above description of tables and operations, reference is now made to FIG. 8 for a description, in flow diagram form, for the generation of the Type Scope Table 28, Expression Table 29, Variable Table 42 and Location Range Table 43. The source file 22 is first subjected to operations in a block 180 to perform lexical analysis of the source file and thereby generate tokens. These tokens are used in operational block 182 for parsing the source file to generate a parse tree and to perform semantic analysis. The operations performed in blocks 180 and 182 are widely used and well known in the field of compiler technology. In block 184, the Type Scope Table 28 is generated from the material produced by processing of the source code in operational blocks 180 and 182. The content of the Type Scope Table 28 is described in reference to FIG. 9 and Table 1 (below). The generated Type Scope Table 28 is provided to the debugger program 30. The Name Space Table 31 is further produced in the operations in block 184 and it is also provided to the debugger program 30. Upon completion of generation of the Type Scope Table 28 and Name Space Table 31, control is transferred to an operational block 186 to build basic blocks from the source code. The building of such basic blocks, noted above, is conventional in compiler technology. Next, in block 188, there is performed the optimization procedure, described above, for decycle loop. Next, in block 190, the XSECTS nodes are annotated with the symbolic expressions produced in conjunction with creating these nodes. Following block 190, further loop optimizations are performed in operational block 192. In operational block 194, an operation is performed to cycle the loops back to introduce the synthesized variables. In block 196, the XSECT nodes are transformed to synthesized variables and these synthesized variables are annotated with the expressions which define the corresponding synthesized variables, as described above. Upon completion of the operations in block 196, code generation is performed in operational block 198 upon the compiler nodes previously produced. This is conventional compiler technology. In operational block 200, the Expression Table 29 is generated and it includes all of the synthesized variables and the corresponding expressions. Table 29 is provided to the debugger program 30. In operational block 202, there is performed the operation necessary to assemble the code. This is conventional compiler technology. Following block 202, there is performed in block 204 the operations required to generate the Location Range Table 43 and the Variable Table 42. These tables are produced by utilizing the machine instructions which have been produced in the assembly operation performed in block 202. The contents of each of these tables has been described above. A representative machine code listing for the routine FOO is shown below. After generation of the Location Range Table 43 and Variable Table 42, operation is transferred to a block 206 to generate the binary machine language instructions for the executable file 46. The operation is completed at an END step 208. Referring now to FIG. 9 there are illustrated fields and relationships for each of the Tables 28, 29, 42 and 43. One of a plurality of entries is shown for each table. There is shown in FIG. 9 an entry for each of the Tables 28, 42, 29 and 43. The Type Scope Table 28 entry includes fields 60 for ID of an identifier, 62 for data type, 64 for lexical scope and 66 for pointer to a Variable Table entry. The Variable Table 42 includes fields 70 for class, 72 for offset, 74 for synthesized flag, 76 for assorted flags, 78 for pointer to Type Scope Table entry, 80 for pointer to Expression Table entry and 82 for pointer to Location Range Table entry. The Expression Table 29 includes fields 84 for identifier, 86 for reason, 88 for uses (list of variables used in the expression), 90 is the expression and 92 is a pointer to Variable Table entry. The Location Range Table 43 includes fields 94 for the record type, field 96 for the variable offset value (home offset) or register enumeration (ephemeral), field 98 for start PC, field 100 for end PC and field 102 for a pointer to a Variable Table entry. Linkages (pointers) between the various tables are indicated by lines. The solid lines represent an explicit pointer and the dashed lines represent an implicit pointer. A line 110 relates the Type Scope Table 28 entry to the Variable Table 42 entry. Line 112 relates the Variable Table 42 entry to the Type Scope Table 28 entry. Line 114 relates the Variable Table 42 entry to the Expression Table 29 entry. Line 116 relates the Variable Table 42 entry to the entry in the Location Range Table 43. Line 118 relates the entry in the Expression Table 29 to the Variable Table 42 entry. Line 120 relates the entry in the Location Range Table to the entry in the Variable Table 42. FIG. 9 is an illustration that defines the various fields within each of the Tables 28, 42, 29 and 43. Examples of the implementations of these tables for the routine FOO, described above, are presented in FIGS. 10, 11 and 12. FIG. 10 is an illustration of the use of these tables for the identifier FOO. Since FOO is itself a routine, only two of the tables are required. These are the Type Scope Table 28 entry and the Variable Table 42 entry. Entries are not required for the Expression Table 29 and Location Range Table 43. Namely, there is no expression for the routine FOO, and it is alive over the entire range of the machine instructions. Referring to FIG. 10, the field 60 includes the name FOO, field 62 for type indicates a function with arguments A, N and the routine returns nothing. Field 64 defines the lexical scope as global. The pointer field 66 indirectly points to the Variable Table 42 entry. Further referring to FIG. 10, the Variable Table 42 entry has class field 70 defined as external definition, the offset field 72 includes the value 0, the field 74 indicates that the variable is user-defined, rather than synthesized, there are assorted flags provided in field 76 and the pointer field 78 explicitly points to the Type Scope Table 28 entry. FIG. 11 is a representation of the user-defined variable N in the routine FOO and this requires use of the Type Scope Table 28, Variable Table 42 and Location Range Table 43. The Expression Table 29 is not required since there is no expression for the variable N. For the entry in Type Scope Table 28, the field 60 is the name of the variable, that is, N. The type is integer*4. The lexical scope field shows that this scope is the subroutine FOO. The pointer field 66 relates to the Variable Table 42 entry indirectly. The Variable Table 42 field 70 for class indicates "argument pointer". The offset field shows that the offset is 0. The flag field 74 shows that the variable is user-defined. Assorted flags are in field 76. The pointer field 78 relates explicitly to the Type Scope Table 28 entry. The pointer field 82 relates implicitly to both of the Location Range Table 43 entries. In the Location Range Table (43) entries shown in FIG. 11, the home offset is for field 94. This field value is either home offset or ephemeral to indicate the location of the variable for the entry. The location is 4, the start PC for field 98 is 80 and the end PC in field 100 is 196. The second Location Range Table 43 entry has field 94 indicating ephemeral register "s0" in field 96. The start PC in field 98 is 84 and the end PC in field 100 is 90. If the program counter is greater than or equal to 84 and is also less than or equal to 90, the value for the variable N is in the register s0. But, if the program count is greater than or equal to 80 and less than or equal to 196, the value is at the location of the argument pointer+4, plus one level of indirection. Otherwise there is no value for N. Referring now to FIG. 12, there is shown the table entries necessary for the synthesized variable "?i4" produced for the routine FOO. In this case there is no requirement to have the Type Scope Table 28. In the Variable Table 42 entry, field 70 indicates that the class is automatic, the offset is 0 in field 72, the variable is synthesized as shown in field 74, and there are various assorted flags in field 76. The pointer field 80 implicitly points to the Expression Table 29 entry. The pointer field 82 implicitly points to the two Location Range Table 43 entries at the lower portion of the Figure. The Expression Table (29) entry in FIG. 12 identifies in field 84 as the variable ?i4. The reason for producing this synthesized variable is that it is a loop induction variable, as indicated in field 86. This variable uses in its definition another synthesized variable identified as "?i2". The expression, field 90, which defines the synthesized variable is ?i4=?i2 +2. The pointer field 92 explicitly points to the Variable Table 42 entry. Further referring to FIG. 12, there are shown two Location Range Table 43 entries. The field 96 entry for home offset indicates that the offset is 0. The start PC count is 142 and the end PC count is 194. The pointer field 102 explicitly points to the Variable Table 42 entry. In the second of the Location Range Table 43 entries, the location field 94 indicates that the location is ephemeral at register s3. The start PC is 142 and the end PC is 152. The pointer field 102 explicitly points to the Variable Table 42 entry. For the ?i4 variable described in the tables in FIG. 12, the value of ?i4 can be determined if the value of the synthesized variable ?i2 can be solved. If the PC.gtoreq.142 and PC.ltoreq.152, the value in register s3 is returned as the value for the variable ?i4. If the PC.gtoreq.142 and PC.ltoreq.194, the value is at the frame pointer+0, see field 96. Otherwise, there is no value available for the synthesized variable ?i4. Detailed examples for each of the Tables 28, 29, 42 and 43 corresponding to the routine FOO (listed above) are presented below. This routine (FOO) was compiled with both the optimization of vectorization and induction variable elimination.
TABLE 1
______________________________________
TYPE SCOPE TABLE
______________________________________
Scope Node Tree: ----------------------
Entries (lexical scope FOO): -----------------------------------
Name: FOO, Type: <## Function
Result: <## Void>
Args: 2 -(
Array: <## Int4>
Bound Pairs: 1-(
{Constant: 1 .. Dynamic Type: <## Int4> .. Assumed})
Int4
Name: A, Type: <## Array <## Int4>
Bound Pairs: 1-(
{Constant: 1 .. Dynamic Type: <## Int4> .. Assumed})
Name: N, Type: <## Int4>
Name: I, Type: <## Int4>
______________________________________
The Type Scope Table 28 is illustrated in Table 1 for the subroutine FOO. This is described in reference to the overall Table 28 description in FIG. 8. The ID field 60 entry in Table 28 corresponds to the names FOO, A, N and I in Table 1. The type field 62 corresponds to the entries in Table 1 following the word "Type:". These include the words Function, Array, and Int4. The term Int4 means the integer 4. The pointer field 66 in FIG. 8 is linked by an implicit pointer (line 110) to the entry in the Variable Table 42.
TABLE 2
______________________________________
VARIABLE TABLE
SYNTHE-
NAME CLASS SIZED OFFSET FLAGS
______________________________________
(0) FOO EXTDEF No 0 ›NEVER REFED!
(1) A ARG.PTR No 0 ›ARGUMENT
FLAG!
›ALLOCATED}
(2) N ART.PTR No 0 ›ARGUMENT
FLAG!
›ADJUSTABLE
DIMENSION!
›ALLOCATED!
(3) I STATIC No 0 ›VALID OFFSET!
›NEVER REFED!
›ALLOCATED!
(4) ?i0 AUTO Yes 0 ›NEVER REFED}
(5) ?i1 AUTO Yes 0 ›NEVER REFED!
(6) ?i2 AUTO Yes 0 ›NEVER REFED!
(7) ?i3 AUTO Yes 0 ›NEVER REFED!
(8) ?i4 AUTO Yes 0 ›!
(9) ?i5 AUTO Yes 0 ›!
(10)
?i6 AUTO Yes 0 ›NEVER REFED!
______________________________________
Table 2 above is an example of a Variable Table for the subroutine FOO listed above. This corresponds to the Variable Table 42 in FIGS. 1 and 9. The name column relates to the pointer field 78 which points to the named variable in the Type Scope Table. The class column corresponds to field 70, the class description in Table 2. Examples of the class include EXTDEF which is an abbreviation for an external definition. This indicates that the location for the variable needs to be determined through what is known as the loader symbol table stored in the executable file. ARG.PTR is an abbreviation for argument pointer. The argument pointer indicates that the variable is an argument to a routine and that the variable has been passed by reference to the routine. This is typically true of FORTRAN arguments. STATIC means that the variable has storage allocated for it, however, the variable is only visible from a single file, that is, the same variable with the same name is statically defined in multiple files and each variable will be a distinct variable. AUTO means that the variable is a stack allocated variable and it typically applies to local variables in both FORTRAN and "C". Further referring to Table 2 and FIG. 9, the offset column for field 72 indicates the starting value for the variable. The synthesized flag column for field 74 indicates whether the variable is a user-defined variable or a synthesized variable. This corresponds to the terms "User-Defined" and "Synthesized" in Table 2. The pointer to Expression Table field 80 in FIG. 9 is implicit by reference (line 114) to the Expression Table. Likewise, the pointer to the Location Range Table, field 82, is implicit by reference (line 116) to the Location Range Table 43. Within the Variable Table 42 entry in FIG. 9, the name, for example, FOO, A, N, I, provides the implied pointer to the Type Scope Table 28.
TABLE 3
______________________________________
EXPRESSION TABLE
NAME REASON USES EXPRESSION
______________________________________
?i0 Simple trip I, N ?i0 =
((-1*MAX(((4+N)/5),1))+((I-1)/5))
?i1 Simple trip I, N ?i1 =
(MAX(((4+N)/5),1)+((-1/5)*(I-1)))
?i2 Outer strip I ?i2 = (I)
?i3 Simple trip ?i2 ?i3 = (?i2+(5*<loop iteration>))
?i4 Loop Induction
?i2 ?i4 = (?i2+2)
Variable
?i5 Loop Induction
?i1 ?i5 = ?i1
Variable
?i6 Loop Induction
A, ?i2 ?i6 = (&A+((?i2-1)*4))
Variable
______________________________________
Referring to FIG. 9, there is shown the Expression Table 29, and Table 3 is a listing for an actual Expression Table for the routine FOO. The identifier field 84 corresponds to the name column in Table 3. The various names are ?i0, ?i1, ?i2, ?i3, etc. The reason column corresponds to the field 86 in the Expression Table of FIG. 6 and is represented by the various phrases including "simple trip", "outer strip" and "loop induction variable". The Uses Column corresponds to the uses field 88 to list the variables used in the expression. Last, the expression column for the expression field 90 corresponds to the expression in each of the entries of the Expression Table 29. For example, the identifier ?i4 has the expression:?i4 =(?i2+2).
TABLE 4
______________________________________
LOCATION RANGE TABLE
VARIABLE
OFF- BOUND- TABLE
TYPE REGISTER SET ARIES ENTRY
______________________________________
<0> Ephemeral s0 -- 84:90 N
<1> Ephemeral s0 -- 94:102
N,
<2> Ephemeral s0 -- 122:130
N
<3> Ephemeral .sup. 0 -- 80:148
A
<4> Ephemeral a2 -- 148:152
?i6
<5> Ephemeral 52 -- 126:152
?i5
<6> Ephemeral s3 -- 142:152
?i4
<7> Ephemeral a2 -- 152:194
?i6
<8> Ephemeral s2 -- 152:194
?i5
<9> Ephemeral s3 -- 152:194
?i4
<10> Home Offset
-- 0 176:194
A
<11> Home Offset
-- 0 148:194
?i4
<12> Home Offset
-- 4 148:194
?i5
<13> Home Offset
-- 8 148.194
?i6
<14> Home Offset
-- 4 80:196
N
<15> Home Offset
-- 0 194:196
?i4
<16> Home Offset
-- 4 194:196
?i5
<17> Home Offset
-- 8 194:196
?i6
______________________________________
The Location Range Table 43 in FIG. 9 includes the record type field 94 which corresponds to the Type column in Table 4. The Table 4 Type column entries are either "Ephemeral" or "Home Offset". Ephemeral means that the variable is located in a register. Home offset means that the variable is located in memory. The Boundaries column corresponds to the start PC field 98 and end PC field 100. For example, in entry <1> the start and end PC (program counter) numbers are 94 and 102 respectively. Last, the pointer to Variable Table entry field 102 in the Location Range Table 43 is the name, such as N, A, ?i6, and this functions as the implied pointer (line 120) back to the Variable Table 42 entry. The Variable Table Entry column corresponds to the pointer field 102 in FIG. 9. Examples for this column are N, A, ?i6, ?i5, etc. The machine language instructions, program counter addresses, opcode and related information for the compiled routine FOO are listed below.
TABLE 5
______________________________________
SYMBOLIC VARIABLE
VALUE WHICH
OF CORRESPONDS
PROGRAM PROGRAM OP- TO MEMORY
COUNTER COUNTER CODE OPERANDS ADDRESSES
______________________________________
0x80001360
F00: ld.w @4(ap),so
N
0x80001364
F00+(0x4):
lt.w #0,s0 N
0x80001368
F00+(0x8):
brs.f F00+(0x3a)
0x8000136a
F00+(0xa):
ld.w 0(ap),a2 A
0x8000136e
F00+(0xe):
ld.w @4(ap),s3
N
0x80001372
F00+(0x12):
ld.w #3,s2
0x80001376
F00+(0x16):
ld.w #4,vs
0x8000137a
F00+(0x1a):
mov s3,v1
0x8000137c
F00+(0x1c):
ld.w .sub.-- mth$d.sub.-- indx+(0x418),v0
0x80001382
F00+(0x22):
add.w v0,s2,v1
0x80001384
F00+(0x24):
st.w v1,0(a2)
0x80001388
F00+(0x28):
add.w #512,a2
0x8000138c
F00+(0x2c):
add.w #128,s2
0x80001390
F00+(0x30):
add.w #-128,s3
0x80001394
F00+(0x34):
lt.w #0,s3
0x80001398
F00+(0x38):
brs.t F00+(0x1a)
0x8000139a
F00+(0x3a)
rtn
______________________________________
For variable N, there are 3 liveness ranges:
Start End Location
______________________________________
1. 0x80001364:0x8000136a - register s0
2. 0x80001372:0x80001376 - register s3
3. 0x80001360:0x8000139c - @(@($ap+4))
______________________________________
A fundamental aspect in the operation of a debugger program is to ascertain the value for a variable at a particular point of execution for the machine instructions. Each machine instruction is identified by a program counter (PC) value. Determining the value of a variable is necessary to the programmer in resolving a problem or understanding the operation of the program. A further aspect to the operation of a debugger is the insertion of a given value into a variable to set its value. In other words, forcing a variable to a given value. These operations for the present invention are described in reference to the flow diagram in FIG. 13. The operation is begun at the start point 250. In a first operational step 252 a programmer is given, or selects, an identifier, a lexical scope and a program counter valve. Referring to the above routine FOO, the programmer may wish to determine the identity of the identifier "I". The lexical scope is the routine FOO. The program counter is the value of the counter at a particular point in the execution of the machine language instructions. In operational block 254 a look (search) is made into the Type Scope Table to search for a type scope entry based on the given identifier and the given lexical scope. The return is a scope entry having these two corresponding fields. The scope entry is ascertained from the Type Scope Table 28 as shown for fields 60 and 64 as shown in FIGS. 9-12. One or more entries may be found based on the given identifier and lexical scope. If no entries are found, the given identifier is not visible. The Name Space Table 31 is used in place of the Type Scope Table 28 for global identifiers. In question block 256, an examination is made to determine if any entries were found in the Type Scope Table 28. If no entries were found, the "=0" exit is taken and the report "UNIDENTIFIED IDENTIFIER" is returned to the programmer. If one or more entries were found, transfer is made to the operational block 258 for a look into the Variable Table 42 from the linkage line 110 (pointer) from the Type Scope Table 28. None, one or more entries may be found. Next, entry is made to the question block 260 to determine how many, if any, variables have been identified in the Variable Table. If none have been identified, the "=0" exit is taken and the report "VARIABLE NOT REALIZED" is returned to the programmer. If one or more variables have been identified in the Variable Table 42, entry is made to a question block 280. Within the question block 280, the programmer defines whether the required operation is reading the value of a variable or writing a value into the given variable. If the "READING" exit is taken, entry is made to operation block 282 and within this operation a look (search) is made into the Expression Table 29 for each entry which includes the given variable in the USES field 88. (See FIG. 9) Next, an attempt is made to solve the expressions in each entry and determine the value for the variable in question. The expression equation is in field 90 of Table 29, as shown in FIG. 9. Following operational block 282, entry is made into a question block 284 which determines if a value has been found for the subject variable by solving the expressions. It may be necessary to recursively cycle between the Expression Table entries and the Variable Table entries to solve for the given variable. If a solution is produced, the "FOUND" exit is taken and the determined value is returned to the programmer as the value of the variable (I) in question. If a value is not found by solving the expressions, exit is made through the "NOT FOUND" exit into an operational block 286. Within the operational block 286, a look is made into the Location Range Table 43 to find a location based on the given program counter valve that exists in the program at the time the inquiry is made to determine the value of the variable. The search into the Location Range Table 43 is made into the PC range defined by fields 98 and 100. If the given program counter is not within a range in the Location Range Table, the "NOT FOUND" exit is taken and the report "VALUE NOT FOUND" is reported to the programmer. If the given program counter value does exist within the range in the Location Range Table 43, the "FOUND" exit is taken and the value of the given variable at a storage location which is defined by field 96 and the offset field 72 in the Variable Table 42 is reported to the programmer. Returning to the question block 280, if the selected operation is "WRITING", entry is made to an operational block 300. Within this block a variable is given a value by the programmer. It is the objective to force a value for the given variable, which variable was selected in operational block 252. From block 300, entry is made to operational block 302 in which a look is made at the Expression Table 29 for each expression that uses the given variable. The given value is applied to the given variable and a calculation is made for a new value for the synthesized variable represented by the expression. See FIG. 9 for the expression field 90 within the Expression Table 29. From block 302, operation is transferred to block 304 in which a look is made at the Location Range Table to determine each location where the given variable and each related synthesized variable resides for the current program counter value. The calculated values for the given variable and the related synthesized variable are assigned to each of the variables for each occurrence. Finally, transfer is made to operational block 305 for reporting back to the programmer that the given variable has been successfully written. The operation is completed at the end step 306. In summary, the present invention provides a method for producing tables for defining variables when source code has been subjected to optimized compiling, for determining a value for variables at a given program counter address and for writing a value into a variable at a selected point in program execution. Although only one embodiment of the invention has been illustrated in the accompanying drawings and described in the foregoing Detailed Description, it will be understood that the invention is not limited to the embodiment disclosed, but is capable of numerous rearrangements, modifications and substitutions without departing from the scope of the invention.
|
Same subclass Same class Consider this |
||||||||||