JPH06175882A - Program debugging method - Google Patents

Abstract

PURPOSE:To easily perform program debugging by confirming the execution order or middle result of a module while grasping the entire configuration of a program. CONSTITUTION:With module identification information as augument, an instruction to call a program debugger is added to the respective modules of the debugging object program. The program debugger displays the module relation diagram of the debugging object program (22), possesses the module identification information of the executing module (23), confirms it, decides the position of the executing module (24) and displays that the module is under executing on the module relation diagram (25). When the content display or content change of any specified area is instructed, the command is analyzed (26) and processing is performed according to the instructed contents (27).

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a program debugging method. In particular, the present invention relates to a method for debugging a program that is configured by connecting a plurality of modules, and relates to a method for debugging while dynamically monitoring a running program.

[0002]

2. Description of the Related Art Conventionally, a cross simulation method is well known as a method for debugging a program. Generally, the cross-simulation method takes out the instructions of a program one by one and simulates the operation according to the instruction specifications. In this method, when cross-simulation is stopped, the contents of a specific area are displayed and checked, or if the contents are changed, it must be defined in advance by a command. Also, the command contents had to be confirmed and the process performed according to the command each time the command was simulated. Japanese Unexamined Patent Publication No. 62-274436 describes a method of simulating the operation of a microcomputer and the input / output operation as one method of cross simulation. In the prior art, there has not been a program debugging method that displays a relational diagram of modules that make up a program and dynamically displays a program module that is being executed.

[0003]

SUMMARY OF THE INVENTION An object of the present invention is to provide a method of displaying a program structure and debugging the program while monitoring the execution order of the program. In debugging a program, confirming that the execution order of the program is as expected is one of the useful means for verifying the operation of the program. In the prior art, it was not possible to explicitly know the execution sequence of the program on the module relation diagram during the simulation of the program operation.
Therefore, the execution order is to be inferred by analyzing the output result after the simulation is completed, and in the case of a complicated operation, it takes a lot of time and labor to correctly know the execution order from the output result. An object of the present invention is to eliminate this and improve debugging efficiency. Another object of the present invention is to provide a means for confirming an intermediate result of a program while monitoring the execution of the program with a module relation diagram showing the configuration of the program. Confirming whether the intermediate result of the program matches the expected value is an effective means of verifying the operation of the program. It is well known to simply specify a module name in advance with a command and stop the execution of the program at that module to check the results on the way, but it is unclear how far the program execution progresses. At the stage of, it is difficult to specify an appropriate module. In the present invention, since the execution position of the program can be explicitly known on the module relation diagram, the program can be stopped at an appropriate module and the intermediate result can be confirmed.

[0004]

Generally, a large program is constructed by connecting a plurality of modules.
Each module constituting the program usually has a relationship between a parent module and a child module, and the parent module calls the child module as needed. Generally, a program has a hierarchical structure in which a plurality of these parent-child relationships exist. One of the means of the present invention is to display the program as a module relation diagram showing the parent-child relationship. In addition, each module
At the beginning and the end of the module, an instruction for calling the program debugger with the module identification information as an argument is incorporated. The program to be debugged transfers control to the program debugger before and after execution of module-specific processing each time control is transferred to each of the modules that compose it. The program debugger, to which control is passed from the module, receives the module identification information from the module and displays that it is being executed on the module relation diagram. In the module relation diagram, it is not necessary to display all layers, and any layer may be displayed. In that case, if the module identification information is deeper than that of the displayed hierarchy, it is displayed that the execution is performed by going back to the displayed parent module. Each time the control is passed from each module, the program debugger stops the execution or displays or changes the contents of the specific area according to the specification, and the module of the calling source
Control can be passed to Le. By this means, the execution of the program can be stopped before and after the module-specific processing is executed, and the contents of the specific area can be displayed and changed.

[0005]

The present invention has the following actions. Displaying the module relationship diagram showing the parent-child relationship between the modules that make up the program helps to understand the overall structure of the program. Incorporating an instruction to call the program debugger in each module makes it possible to transfer control to the program debugger when the program is executed. Displaying which module is currently being executed in the module relation diagram allows the movement to be dynamically known while looking at the overall configuration, rather than simply listing the execution order. Facilitate verification of. Module
It is useful to understand the structure of a program step by step from a macro structure to a detailed structure so that the relational diagram can be displayed in any hierarchy. Displaying the execution status of the module back to the parent module is also effective for stepwise verification. Being able to specify the position to confirm the result in the middle of the program in the module relation diagram facilitates the specification and helps determine which position should be confirmed. Providing the program debugger with the function of displaying and changing the contents of a specific area makes it possible to confirm and change the intermediate results of the program and facilitate program debugging.

[0006]

EXAMPLE An example of the present invention will be described with reference to FIGS. FIG. 1 is a basic configuration diagram of the present invention. In FIG. 1, reference numeral 11 denotes an operating system (hereinafter referred to as OS) mounted on a workstation or the like, which has a multitask control function. 12 is a program debugger. Reference numeral 13 is a debug target program. 1
2 and 13 operate as independent tasks by the multitask control function of the OS 11. Reference numeral 14 represents that each module of the program to be debugged transfers control to the program debugger. 15 indicates that the program debugger returns control to each module.

FIG. 2 is a block diagram of the program debugger. In FIG. 2, reference numeral 21 is an overall control unit for controlling the entire program debugger. Reference numeral 22 denotes a module relation diagram display section for displaying a module relation diagram, which inputs a source program or an object program of a debug target program, and displays a module relation diagram as shown in FIG. 3, for example. Reference numeral 23 is a module identification information acquisition unit for acquiring module identification information passed by each module of the program to be debugged, and 24 is an execution module for recognizing the module identification information and determining the position of the module relation diagram. It is a position determination unit. 25 is the execution module position determination unit 2
4 is an execution module display unit that displays that the module is being executed in accordance with the determination result of No. 4. Reference numeral 26 is a command analysis unit for analyzing an instruction command for confirming an intermediate result of the program, and 27 is a command execution unit for displaying or changing the contents of the specific area according to the command.

FIG. 3 is an example of a module relation diagram, which means that the left module calls the right module. A module A of 31 calls modules B, C and D shown as 32, 33 and 34, a module B of 32 calls modules E and F shown at 35 and 36, and a module of 34 D calls the module G shown at 37. Fig. 4 shows the structure of each module that constitutes the debug target program by PAD (Problem Analys
is Diagram) is a diagram. Reference numeral 41 is a program debugger calling section for calling the program debugger before executing the processing unique to the module, 42 is processing unique to the module, and 43 is a program debugger calling for calling the program debugger after completion of the processing unique to the module. It is a department. Program debugger calling units 41 and 43
Passes the control to the program debugger with the module identification information and the information for identifying whether it is a call before or after the execution of the processing peculiar to the module as an argument. The instruction to call the program debugger is automatically added by designating the debug mode when compiling the module.

The operation procedure will be described with reference to FIGS. First, an instruction program debugger calling unit 4 that compiles the debug target module in the debug mode and calls the program debugger shown in FIG. 4 for each module.
1 and 43 are incorporated. Next, when the operator inputs a command or the like, the OS 11 of FIG. 1 activates the program debugger 12. The program debugger 12 uses the processing modes 22, 22, 23 shown in FIG.
6 is executed, but at the first activation, an instruction to execute the module relation diagram display unit 22 is given, a module relation diagram as shown in FIG. 3 is displayed on the screen, and a standby state is set. . Next, the OS 11 of FIG. 1 activates the debug target program 13 according to a command input instruction of the operator. The debug target program 13 is sequentially executed according to the contents of the program, but each time the control is transferred to each module, the program debugger calling unit 4 of FIG.
1 transfers control to the program debugger and passes the module identification information to the program debugger. In the program debugger, the overall control unit 21 shown in FIG.
The module identification information acquisition unit 23 is determined to be a control mode and control is passed to the module identification information acquisition unit 23. The module identification information acquisition unit 23 acquires the execution module identification information, and the execution module position determination unit 2
4 obtains the position on the module relation diagram displayed on the screen according to the information. The execution module display unit 25 displays that the execution is being performed at the position obtained by the execution module position determination unit 24.

The module relation diagram may be designed so that it can be displayed up to an arbitrary depth (hierarchy). In that case, if the specific module indicated by the module identification information is not displayed in the module relational diagram, it is being executed by sequentially tracing back to the parent module of the displayed module. The message is displayed. This makes it possible to know which part of the program is currently being executed (which module is being executed or which child module of which module is being executed). In addition, as the display indicating that it is being executed, there is a method of changing the display color of the module name or changing the brightness.

At the time of executing the module, the overall control unit 21 determines whether or not a command for displaying or changing the content of the specific area is registered. If the command is registered, the command analysis unit 26 and the command execution are executed. The unit 27 performs processing according to the content of the command. The command for changing the content of the specific area or the command for displaying the content may be registered when the module-related diagram is displayed, or can be received and registered by the program debugger even when the program to be debugged is executed. By specifying a specific module on the module relation diagram or instructing with a command, the execution of the program is stopped in the program debugger called by the specific module, and the contents of the specific area You can display or change the contents of a specific area. After that, the stop of the execution of the program is released and the execution is continued. When control is transferred to the program debugger after the module-specific processing is completed, the same processing as above is performed, but the message indicating that it is being executed is erased from the module and the parent module is displayed. To do. After confirming the operation of the program, each module may be recompiled in a normal mode that does not incorporate an instruction for passing control to the program debugger, or may be returned without executing anything. Prepare a dummy program debugger and replay the program debugger of the present invention.
You may

[0012]

The execution order can be monitored by displaying the modules being executed in the module relation diagram, which makes it possible to explicitly grasp how far the modules are currently executed. At the same time, it is possible to easily detect an error regarding the execution order of the modules. In addition, the fact that the module relation diagram can be displayed at an arbitrary depth enables the stepwise confirmation of the execution order. In addition, instructing the position to check the results during program execution on the module relation diagram eliminates the error of the instruction compared to instructing with the text format command, and the module relation diagram can be used to confirm the entire configuration. Since it is possible to give instructions while watching, it is easy to select an appropriate confirmation position. As described above, there is an effect that the verification of the program operation is facilitated and the debugging efficiency is improved.

[Brief description of drawings]

FIG. 1 is a basic configuration diagram of the present invention.

FIG. 2 is a block diagram of a program debugger of the present invention.

FIG. 3 is a diagram showing an example of a module relation diagram.

FIG. 4 is a PAD diagram in which a program debugger calling unit is added to a module.

[Explanation of symbols]

 11 Operating System 12 Program Debugger 13 Debugging Target Program 21 Overall Control Section 22 Module Related Diagram Display Section 23 Module Identification Information Acquisition Section 24 Execution Module Position Determining Section 25 Execution Module Display Section 26 Command Analysis Section 27 Command Execution Section 31 ~ 37 modules 41, 43 Program debugger calling section 42 Module specific processing section

Claims (1)

[Claims] 1. In a program debugging method for debugging a program configured by connecting a plurality of modules, an instruction for calling a program debugger using module identification information as an argument is incorporated in each module, and the program is executed. The above-mentioned program debugger is called by each module in the inside, and the above-mentioned program debugger recognizes the module identification information passed from each above-mentioned running module and makes the above-mentioned program as a module relation diagram showing a parent-child relationship of a plurality of modules to an arbitrary depth A program debugging method comprising displaying and displaying which part of the program is being executed in the module relation diagram.