JPH06274369A - Optimization program debugging method - Google Patents

Abstract

(57) [Summary] [Objective] To provide a debugging method that enables program debugging at the high-level language description level of an object program optimized by a compiler. [Configuration] A variable at a required program point is acquired by referring to a register allocation information table 10 indicating a correspondence between a variable and a register to which the variable is allocated for each section on an object program in which register allocation is constant. To Register allocation information table 1
Zero has information indicating that the variable is not allocated to a register as a result of the compiler determining that the variable is not likely to be used in the future within the valid range of the variable.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a method for enabling program debugging in an information processing system, and in particular, program debugging at a high level language description level of an object program optimized by a compiler.

[0002]

2. Description of the Related Art In order to debug a high-level language, it is necessary to generate an object program according to a certain execution method so that information necessary for debugging can be easily obtained during program execution. The constant execution method for debugging is, for example, (1) a location to which a variable is allocated is constant within the effective range of the variable, (2) an automatic variable or parameter arranged on the stack is The object program corresponding to one line (one statement) of the source program is arranged in a continuous address range, and so on.

On the other hand, the object program is optimized by a compiler in order to move the code that does not need to be executed in the loop to the outside of the loop and to improve the efficiency of the object program by rearranging the code.

[0004]

However, such optimization results in the generation of an object code that does not follow the above-mentioned fixed execution method, and the object program generated by the compiler and the source program are in one-to-one correspondence. This makes it difficult for the debugger to unequivocally refer to or change data in a representation at the source program description level. Therefore, when debugging an optimized object program, the accuracy of the information obtained by debugging is unavoidable. On the contrary, the fixed execution method constraint limits the possibility of optimization.

An object of the present invention is to provide a debugging method compatible with the optimization technique by relaxing the restriction of the above-mentioned execution method and adding new debug information to complement it. Further, another object of the present invention is to realize the debug function even if those execution format constraints are violated by optimization, in order to realize the debug function, the allocation location of the variable, the address of the object program corresponding to the program point of the source program, etc. To provide a debugging method that can add detailed information about the details with a small amount of information to enable debugging of an optimized program at a high-level language description level while minimizing the size of the debugging information. It is in.

The above and other objects and novel features of the present invention will be apparent from the description of this specification and the accompanying drawings.

[0007]

The outline of the representative one of the inventions disclosed in the present application will be briefly described as follows.

(1) According to the structure of the program, variable allocation can be dynamically changed within the effective range by optimization only by outputting variable allocation information as debug information corresponding to the effective range of the variable. The case cannot be dealt with, and when the variable is not used and is not assigned to the register, the fact cannot be displayed during debugging. On the other hand, for each section in the object program in which register allocation is constant, a register allocation information table (corresponding table 10 in FIG. 3) showing the correspondence between variables and registers to which the variables are allocated is referred to, Try to get the variable at the desired program point. Further, the register allocation information table (Comparison Table 10 in FIG. 3) determines that there is no possibility of future use of the variable by the compiler within the effective range of the predetermined variable when acquiring the variable at the required program point. As a result, the variable has information indicating that the variable is not allocated to a register. By referring to this, when the variable to be acquired has no register allocation, that fact is displayed. Further, in order to reduce the information amount of the register allocation information table while suppressing the deterioration of the debug accuracy, as shown in FIG. 4, for the integrated section in which the sections on the object program in which the register allocation is constant are integrated. , Information that counts the number of times a variable is referenced for each register to which the variable is allocated, sets the register with the highest number of references as the allocation register for the variable, and sets the variable and its register as register allocation information in the integration section. Adopt compression processing. (2) As a result of optimization, if a variable that is not assigned to a register or memory is associated with a constant or a value of the variable assigned to a register or memory by a specific mathematical expression, Outputting the register name, memory address value, or offset address value from a specific base register as the allocation information as debug information is not sufficient. With respect to this point, the compiler generates the above formula as an allocation information table (conversion table 11 in FIG. 5), and when acquiring a variable at a required program point, the formula is referenced to acquire the value of the variable. (3) Outputting debug information assuming a specific base register for accessing a stack frame cannot support optimization in which a base address other than a stack pointer is not used for accessing a variable. In this regard, an offset correction value, which is the difference between the stack pointer value at the program point indicated by the program counter and the stack pointer value at the procedure entry in order to access the desired variable from the stack pointer value that changes each time the procedure is called, Information table held in correspondence with the value of the program counter (Comparison table 12 in FIG. 6)
Is generated and the offset correction value is used to access the automatic variables and parameters in the stack frame during debugging. (4) When the line of the source program (which is understood as a concept including a statement in this specification) and the instruction sequence of the object program do not correspond one-to-one in sequence due to optimization of the compiler, the address of each instruction of the object program To the line of the source program from which the instruction originates (line number comparison table 13 in FIG. 7), and based on this, the line of the source program is specified in association with the instruction of the object program. indicate. When the line of the source program and the instruction sequence of the object program do not correspond one-to-one in sequence due to the optimization of the compiler, instead of associating a line number with each instruction, for each line number, the head from that line is derived. A table (line number comparison table 14 in FIG. 7) in which the address of the instruction is associated with the section on the program indicated by the address of the last instruction is generated, and the line of the source program is associated with the instruction of the object program with a small amount of information. Allows you to specify or display. On the other hand, in order to improve the usability for the user, when the address of the instruction of the object program is specified from the line of the source program as a breakpoint, the address of the first instruction or the last instruction is selectively specified by the command. . (5) If there is no table of addresses to call and the jump is detected by the program counter being out of the range of the line currently being executed, the processing is interrupted even when calling the processing routine prepared by the system. However, the debugger overhead increases. In this regard, for each line of the source program, a table is created by associating an address group for calling a predetermined procedure or a predetermined function within the range of the line, and is called by referring to this table. Jumping into a procedure or function and exiting from a called procedure or function are selected only for the procedure or function defined in the table (procedure in FIG. 8).

[0009]

According to the above means, in order to alleviate and complement the conventional object program execution method assumed for debugging, the object program corresponding to the variable allocation location and the program point of the source program is Adding information indicating the address and the like in more detail as new debug information realizes a debug method corresponding to the optimization technology. Furthermore, the information compression method for the debug information realizes the debugging of the optimized program at a high level language description level while keeping the size of the debug information to a minimum.

[0010]

EXAMPLE {1} Debug System FIG. 1 shows an example of a system applied to an optimized program debug system according to the present invention. The system shown in the figure is an overall system relating to the development and debugging of a computer program in a high-level language. This system reads a source program 1 and outputs an object program 2 and debug information 3, and a debugger system 5 that reads the object program 2 and debug information 3 and provides a debug function at a high-level language description level of the program. When the source program 1 is compiled, necessary debug information 3 is created and added to the object program 2. For example, the object program 2 and the debug information 3 are logically separated and formed in the same file. The debug system 5 includes a simulator 6 and a debugger 7. The debugger 6 controls the execution of an object program by the simulator 6, obtains the execution result, and realizes an operation necessary for debugging the program using the debug information.

{2} Debugging Method for Optimizing Register Allocation for Variables First, the debug information on the correspondence between program points and variable allocation states will be described. Compiler 4
Although register allocation processing is performed as part of optimization, in a non-optimized object program in which variables are mechanically allocated without register allocation, variables are stored in constant registers in the valid section of the variables. Alternatively, it is assigned to an address on the memory. The register allocation process optimizes this allocation, and generally this allocation is not constant within the effective range of the variable.

For example, as shown in FIG. 2, when the constant 1 is assigned to the variable a and then the constant 2 is newly assigned to the variable a, these two values are set in the register-allocated program. The registers to which the variable a is allocated need not be the same at two program points. This is because the information of the variable a up to now is lost at the time of assigning a new value. In addition, in FIG. 2, at a program point where it is known that there will be no reference to the variable a in the future, the register to which the variable a is allocated may be allocated for another variable.

The compiler 4 creates a reference table of variables and registers to which the variables are allocated for each range of the program (a range of the value of the program counter) in which the register allocation to the variables is constant, and uses it as debug information. Can be added. This gives the correct value for the variable at any program point. Also, if you set a flag indicating that variables are not assigned to the range of the program where variables are not assigned,
You can see when debugging that the variables are not assigned. FIG. 3 shows an example of a comparison table 10 of such register allocation for the program of FIG. In the comparison table 10 of FIG. 3, the description “no allocation” means a flag indicating that there is no variable allocation. The amount of the debug information as shown in the comparison table 10 can be reduced as compared with the case where the register allocation of the variable at each program point (each program counter value) is used as the debug information. If the debug information can be reduced, the system resources required for debugging, such as the work memory capacity, can be reduced.

Since variable allocation can change frequently within the effective range of variables, the register allocation information for all variables is output globally each time, in other words, the range of the program as shown in FIG. When the comparison table of variables and registers is output by paying attention to each (PC value range), the size of the debug information increases. Therefore, paying attention to each variable, one for each variable has a comparison table of the program range and allocation register information, and does not generate a new table entry for the variable whose allocation is not changed. Each time the allocation is changed, a new entry is created in the variable reference table.

To reduce the register allocation information further than the above, as described above, for one variable, a program range larger than a fixed range of individual register allocation, for example, jumping or jumping in control of the program, is performed. To keep the register allocation information constant for a basic block that is an instruction sequence that does not have a sequence, that is, an instruction sequence that does not involve processing that changes the instruction execution order such as jumps and branches in the range where the context does not change To That is, for each basic block, the reference count of each variable is aggregated for each register to which the variable is allocated, and the register that is most frequently allocated is the allocation register for that variable. Register allocation information in the program range of.

FIG. 4 shows an example of the procedure of compression processing of such a register allocation comparison table. That is, the compiler 4 increments the counter corresponding to the register number at the time of variable reference for each of the basic blocks and for each variable in the focused basic block (step S1),
The register number having the maximum count is set in the reference table as the register number corresponding to the variable (step S
2). Such processing is performed for all references of all variables for all basic blocks through steps S3 to S8. According to such a processing procedure, since the register allocation information is held for each wider program range, the debug information can be reduced. It is thought that reducing the debug information by such a method will reduce the debugging accuracy compared to the above, but since the code has been optimized in the first place, the absolute relationship of one-to-one correspondence between the source program and the object program Since it has been broken, it is important, and desirable, to approve it and to realize relatively easy-to-use and reliable debugging with few resources.

Some optimization of the object program changes the value of the variable itself according to a certain rule, such as reducing the strength of the loop variable. For example, in the program shown in FIG. 5A, as a result of optimization, the variable n is held in the register with a value of 2n. In order to have this information at the time of debugging, it is necessary to have the variable allocation information in the form of a mathematical expression, not in the simple register or memory address format.
In the program of this example, the value actually stored in the register (R6 in this case) is 2n, not the actual value of the variable n, so the data corresponding to the formula for calculating the value of the variable from the value of the register The structure, for example, as shown in FIG. 5B, the data expressing R6 / 2 in the reverse Polish notation may be held as a conversion table 11 from the value of the register to the value in the source program. Although not shown, it goes without saying that the variables in the conversion table 11 are associated with the corresponding program range. The above method is not only applicable to cases involving complicated operations, but
Since the compiler 4 has a constant variable value, even if the variable is replaced with a constant at the time of compilation as part of optimization, if the constant is used as the variable allocation information, the value can be referred to during debugging.

{3} Debugging method for optimization in which stack pointer is exclusively used For referring to station automatic variables and parameters on the stack, the data on the stack frame is referred to as a stack pointer (SP) without using a general-purpose register. ) Is used to describe an embodiment of a debugging method related to optimization. This optimization does not use extra registers like frame pointers for frame access,
Although there is an advantage in execution speed and memory size, since the value of SP changes during program execution, variable allocation cannot be expressed by debug information such as offset from the base register. That is, at the entrance of the procedure,
Offsets such as variables for the stack pointer are originally held as debug information. And the process proceeds,
If you want to stop the execution of the program in any state where the stack pointer value has changed and you want to reference that variable, the value of the stack pointer that is the basis for referencing it has changed, so some means Must be taken to refer to the variable using the offset for the value of the stack pointer at the entry of the procedure. At this time, if the value of the stack pointer is traced each time one instruction is executed, it is possible to refer to the required variable based on the trace information, but such tracing increases the processing overhead and is not realistic. Absent.

Therefore, as debug information, the program counter (PC) is used as a key, and S at the entry point of the procedure is used.
The compiler generates information for obtaining the difference between the value of P and the value of SP at the program point, and adds the information to the debug information. That is, as shown in FIG. 6, a comparison table 12 of the stack pointer (SP) and the program counter (PC) in the function is generated as debug information. As a result, the value of SP at the procedure entry is subtracted by subtracting the value of SP at the procedure entry (subtracting the difference value of SP) from the value of SP at the program point, whatever the value of PC. If the SP value at the procedure entry point is used as the base address, the offsets of automatic variables and parameters are constant (this is originally held as debug information), so when the program is stopped, the desired Variables can be referenced by the debugger.

{4} Enhancement of debug information related to correspondence between source line and object program In the following, source statements (or lines) required for setting breakpoints, displaying source program, stepping, etc., during debugging. This section describes the enhancement of debug information related to the correspondence between the and object programs.

The compiler 4 optimizes a computer such as a pipeline microcomputer to rearrange instruction sources across statement boundaries in order to lubricate the pipeline flow. In addition, there are other optimizations such as loop unrolling that do not preserve the order of statements and instructions. Therefore, unlike the prior art, it is not possible to use a one-to-one correspondence table between a statement and a continuous address range corresponding to the statement. Therefore, as shown in FIG. 7A, a line number comparison table 13 in which, for each address of each instruction, the line of the source statement from which the instruction originates is associated.
When a break is specified for a source statement (line) during debugging, the actual break is applied to the address derived from the first instruction of the statement to specify the program point at the source level. You can enable it.

However, outputting the statement information for each instruction increases the size of the debug information. In order to suppress this, for the source statement, the address of the first instruction and the address of the last instruction corresponding to the statement (line) are output by the compiler 4, and this is output as a line number comparison table as debug information. It should be 14. In this case, as the corresponding memory address when the source statement is specified, the start address and the end address can be used properly according to the purpose. The output contents of this method are shown in FIG. By providing both the beginning and end addresses of a statement, when a breakpoint is set at the program point by the debugger, (1) know the state before statement execution, and (2) know the state after statement execution. The function of can be realized. Therefore, the debugger can selectively specify two types of breakpoints corresponding to the start address and the end address of the output format by a command or the like in order to serve both purposes.

Next, the procedure of the debugging process involving function calls such as step-in / step-out will be described. For example, in step execution where debugging is performed by stopping execution for each statement in a high-level language,
Conventionally, when the value of PC deviates from the address range of the procedure currently being executed, the execution of the instruction corresponding to the statement is interrupted at that timing regardless of the cause. For example, this is a case where a processing such as a jump subroutine exists in the load module corresponding to the description of one statement. Therefore, the processing routine prepared by the system, for example, the calling of a calculation routine (floating point calculation or the like) is also interrupted, and the overhead of the debugger increases. In other words, the processing routine prepared by the system has already been debugged, so it is not necessary to interrupt it. Therefore, by utilizing the fact that these arithmetic routines can be recognized by the compiler based on the call address, the call address is output as debug information only for the actual user routine (routine that has not been debugged yet). As a result, the debug function by step-in / step-out can be efficiently realized. FIG. 8 shows a step-in processing method in the debugger for that purpose. In other words, the call address of only a substantial user routine is used as debug information and 1
As a method of realizing step-in (moving to the processing of a called statement) at the calling point in the instruction execution processing for each statement, when the next calling address is acquired in step execution (step S10), this is specified as the debug information. If it exists as a call address (a call address intended only for a substantial user routine) (step S11), step into that call point (step S12) and execute a debugging instruction for break ( Step S1
3), the process ends. If it does not exist as a call address (step S11), execution proceeds to the next statement (step S14).

Although the invention made by the present inventor has been specifically described based on the embodiments, the present invention is not limited thereto, and needless to say, various modifications can be made without departing from the scope of the invention. Yes. For example,
One line of the source program can be read as one statement of the source program. Further, the register is not limited to a so-called single register such as a flip-flop having a constant word length of 16 bits or 32 bits, and may be a memory. It is called a register in the specification.
Further, in the comparison table of various debug information in the specification, it is not necessary that all the entries always exist, and it is sufficient that the entries are dynamically formed and held as the debug processing progresses.

[0025]

The effects obtained by the typical ones of the inventions disclosed in the present application will be briefly described as follows.

That is, in order to alleviate and complement the conventional object program execution method assumed for debugging, the allocation location of variables, the address of the object program corresponding to the program point of the source program, etc. are described in more detail. By adding the information shown in 1) as new debug information, it is possible to realize a debug method corresponding to the optimization technique. Furthermore, by using the information compression method for debug information, it is possible to debug an optimized program at a high-level language description level.
This can be achieved by minimizing the size of debug information. Due to the above, you can debug even optimized programs without sacrificing debug capabilities,
It is possible to improve the development efficiency of programs in high-level languages.

[Brief description of drawings]

FIG. 1 is a block diagram showing an example of a system applied to an optimized program debugging method according to the present invention.

FIG. 2 is an explanatory diagram of an example in which register allocation to variables is not constant.

FIG. 3 is an explanatory diagram of an example of a register allocation comparison table.

FIG. 4 is an explanatory view of an example processing procedure of generating a compressed register allocation comparison table.

FIG. 5 is an explanatory diagram showing an example of a case where register allocation is not exact and a value conversion table from registers.

FIG. 6 is an example of a comparison table of stack pointer values and program counter values in a function.

FIG. 7 is an explanatory diagram showing two examples of line information output formats in which addresses and line numbers are associated with each other.

FIG. 8 is an explanatory diagram of an example of a step-in processing method at a calling point.

[Explanation of symbols]

 1 Source program 2 Object program 3 Debug information 4 Compiler 5 Debugger system 6 Simulator 7 Debugger 10 Register allocation comparison table 11 Conversion table 12 Comparison table 13, 14 Line number comparison table

[Procedure amendment]

[Submission date] October 18, 1993

[Procedure Amendment 1]

[Document name to be amended] Statement

[Name of item to be corrected] Figure 6

[Correction method] Change

[Correction content]

FIG. 6 is an explanatory diagram of an example of a comparison table of stack pointer values and program counter values in a function.

 ─────────────────────────────────────────────────── ─── Continuation of the front page (72) Hiromi Nagayama, 5-20-1 Kamimizuhoncho, Kodaira-shi, Tokyo Incorporated company, Hitachi, Ltd. Semiconductor Business Division (72) Tsutomu Hayashi 5 Kamimizumoto-cho, Kodaira-shi, Tokyo Hitachi Co., Ltd., Semiconductor Company, Ltd., Hitachi Ltd. (72) Koji Yoneyama, Kojimizuhonmachi, Kodaira-shi, Tokyo, 5-20-1 Company, Ltd., Semiconductor Company, Ltd. (72) Hideya Fujita, Tokyo 5-20-1 Kamimizuhoncho, Kodaira-shi Hitachi Ltd. Semiconductor Division (72) Inventor Yoichi Sudo 5-22-1 Kamimizuhoncho, Kodaira-shi, Tokyo Inside Hitachi Microcomputer System Ltd.

Claims (9)

[Claims] 1. A debug method of an optimized program, which enables debugging of an object program optimized in a high level language by a compiler at a high level language description level, wherein register allocation is performed. An optimization program characterized by acquiring a variable at a required program point by referring to a register allocation information table showing a correspondence between a variable and a register to which the variable is allocated for each section on the object program which is constant. Debug method. 2. The register allocation information table is
Information indicating that the variable is not assigned to a register as a result of the compiler determining that there is no possibility of future use of the variable within the valid range of the given variable when acquiring the variable at the required program point When the variable to be acquired has no register allocation, the fact is displayed.
Debugging method for the described optimization program. 3. With respect to an integrated section in which sections on an object program in which register allocation is constant are integrated, the reference counts of variables are totaled for each register to which the variable is allocated, and the register with the highest reference count is concerned. The debugging method of the optimization program according to claim 1, wherein the variable allocation register is used as the variable allocation register, and the variable and its register are used as register allocation information in the integration section. 4. A debugging method of an optimizing program, which enables debugging at high level language description level of an object program optimized by a compiler, wherein a source program written in a high level language is the result of optimization. When a variable that is not assigned to a register or memory is associated with a constant or a value of a variable assigned to a register or memory by a specific mathematical expression, the compiler assigns the mathematical expression to the allocation information table. A method for debugging an optimization program, which is characterized in that the value of the variable is acquired by referring to the formula when acquiring the variable at the required program point. 5. A debugging method of an optimized program, which enables debugging of an object program optimized by a compiler in a high-level language description level, the source program described in a high-level language, wherein the compiler is a variable. Access to a desired variable from the value of the stack pointer that changes each time the procedure is called when optimization is performed to save the registers allocated to the base address by not using the base address other than the stack pointer. In order to do this, an information table having an offset correction value, which is the difference between the stack pointer value at the program point indicated by the program counter and the stack pointer value at the procedure entry, is associated with the value of the program counter, and the desired program counter The offset corresponding to the value Get the stack pointer value as the base address value in the procedure the inlet from the correction value, debugging method of optimization program characterized by referring to the predetermined variable from the offset value of the base address value and the required variables. 6. A debugging method of an optimizing program, which enables debugging at high-level language description level of an object program optimized by a compiler, wherein a source program written in high-level language is optimized. When the lines of the source program and the instruction sequence of the object program do not sequentially correspond one-to-one with each other, a table is generated in which the address of each instruction of the object program is associated with the line of the source program from which the instruction originates. With reference to this, a debugging method for an optimizing program characterized in that a line of a source program is designated or displayed in association with a command of an object program. 7. A debugging method of an optimizing program, which enables debugging at high-level language description level of an object program optimized by a compiler, wherein a source program written in a high-level language is optimized. When a line of a source program and a sequence of instructions of an object program do not correspond one by one in sequence, instead of associating a line number with each instruction, for each line number, A table in which an address and a section on the program indicated by the address of the end instruction are associated with each other, and the row of the source program is specified or displayed in association with the instruction of the object program by referring to the table. Optimize program debugging method. 8. The breakpoint, when the address of the instruction of the object program is specified from the line of the source program, the address of the start instruction or the end instruction is selectively specified by the command. Debugging method for the described optimization program. 9. A debugging method of an optimization program, which enables debugging of an object program optimized by a compiler in a high-level language description level, the source program described in a high-level language, each line of a source program , A table is created that associates the address groups for calling a predetermined procedure or a predetermined function within the range of the line, jumps into the procedure or function to be called, and the inside of the procedure or function to be called. A method for debugging an optimizing program, characterized in that the jump out from is selected only for the procedure or function defined in the table.