JPH03103934A - Debugging system dependent upon dynamic change of module entrance - Google Patents

Abstract

PURPOSE:To eliminate the execution of confirmation processing or the like at the time of system operation to prevent the reduction of the execution speed by managing modules having entrance addresses different between system operation and debugging by a control table. CONSTITUTION:Module PRG.A to PRG.C having entrance addresses different between system operation and debugging are generated, and these addresses are managed by a control table MET. Entrance addresses of modules PRG.A to PRG.C in the control table MET are switched to entrance addresses for debugging at the time of debugging and are switched back at the time of system operation. When each of modules PRG.A to PRG.C will be executed, the module to be executed is indicated to a switching monitor MON by the relative position on the control table MET of this module, and this monitor MON reads out the entrance address of the indicated module to start the execution of the module. Thus, the entrance address is only changed to the entrance address for debugging to provide the confirmation processing of interface, and the time required for confirmation processing is shortened.

Description

[Detailed Description of the Invention] [Field of Industrial Application] The present invention relates to a computer system, and more specifically, to a system that divides a large-scale program into a plurality of modules and dynamically changes the module population of the system. Regarding debugging methods.

3. Detailed Description of the Invention [{Already required] Concerning a debugging method by dynamically changing the module population of a system in which a large-scale program is divided into multiple modules, a check process is easily provided and the time required for the process is reduced. BACKGROUND ART As computer systems develop, the scale of the computer systems also increases. Furthermore, as the scale of the system increases, the number of programs also increases.

Configuring such a large program as a one-tree program requires a large amount of development time. For this reason, the aforementioned large-scale program is divided into multiple modules, and an interface is determined for each module to implement its functions. By doing this, it is possible to debug whether processing is being performed normally in each module, improving development efficiency.

As mentioned above, modularization improves development efficiency, but on the other hand, if the agreed upon interface is incorrect when creating a program, not only will the correct result not be obtained, but in some cases, other data areas may be destroyed, resulting in serious problems. may cause.

In order to prevent such serious failures from occurring, conventionally, input interface confirmation processing is provided for each module, and the processing is executed only when the input interface to the module is correct. for example,
If the data to be input into a module must be within a specific range, the verification module checks whether the input data is within a defined range of values. If it is other than that, it is assumed that the module has terminated abnormally, and no processing is performed within the module.

[Problem to be solved by the invention]

As described above, before each module is executed, the interface is checked, it is determined whether the module has data that should be executed normally, and if the data is abnormal before the module is executed, it is rejected.

Such interface confirmation processing is completely wasteful processing when the input interface is correct. In other words, this becomes a factor that reduces system performance. For this reason, during development, we inserted a verification process for such a human-powered interface, and when the module testing period ended, we deleted the verification process. However, after the test of the module is completed, the test may be executed again due to the addition of a function, a change in the function implementation process, a change in the device configuration, etc. In this case, confirmation processing must be executed for early bug detection.

In order to perform this confirmation process again, the deleted confirmation process must be re-installed. Therefore, it is necessary to recompile the module in order to run the confirmation process again, and this compilation has the problem of requiring a lot of time.

Further, there is a problem in that it is not only necessary to simply recompile, but also to change the JCL etc. of each module in order to insert confirmation processing.

The present invention aims at a debugging method by dynamically changing module entrances, which allows for simple verification processes and shortens the time required for them.

[Means and effects for solving the problem] Create a module with different input addresses during system operation and debugging, and manage these addresses in a control table.

During debugging, the entrance address of each module in the control table is changed to the input address during debugging, and returned to the original address during system operation.

When each module is to be executed, the transition monitor is instructed by, for example, the relative position of the module to be executed on the management table, and the transition monitor searches the management table for the instructed module and executes the module.

The migration monitor reads the population address of the specified module and transfers execution to the module, so you can set up an interface confirmation process by simply changing the entry address of each module in this management table to the population address at the time of debugging. .

〔Example〕

Hereinafter, the present invention will be explained in detail using the drawings.

FIG. 1 is a configuration diagram of an embodiment of the present invention. In a system having programs A, B, and C which are modules, when program A calls program B5 6 as a subroutine, program A (functionally expressed as CALL B in Figure 1) is called as a subroutine. MODLILE ENRYTY TABLE MET (MODLILE ENRYTY TABLE) in which the entry address of program B is set in REGI
E) Store the relative address above. Then, a subroutine call is made to the migration monitor MON. Although not shown, C
The PU uses this subroutine call to
N is first executed, the start address of the module entry table MET is added to the contents of the register REG1, and a branch is made to the address of the entry pointed to by the register REC;1.

With the transition monitor as described above, even if the transition monitor is called from program A, the register REG1 indicates the relative address of the module, so CUP is executed from the entrance address of program B as a result. Similarly, when calling program C within program B, the relative address in the module entry table MET of program C is set to register REC.
1 and calls the migration monitor MON, the program will be executed from the entry address of program C. The population addresses of programs B and C are registered in the module entry table MET.
Through this registration, the entrance addresses of programs C and B can be found from the start address and relative position of the module entry table MET. Programs A, B, and C each have an entrance address for debugging in addition to the entrance address for normal system operation. This entry address is set so that, for example, GOTO The entry address to jump to is stored in the population address of the so-called function execution process, which excludes the confirmation process.

On the other hand, in the system as described above, when the interface confirmation process, so-called debugging, of the respective programs A, B, and C is performed, a debugging request command is manually inputted from the system 7 8 to the MET change process S1. This MET update process S1 is a process of increasing the address of the module entry table MET by +α (if the address changes from debugging to system operation, it is a process of decreasing –α). For example, if the population addresses differ by 4 bytes as described above, this process will result in +4.

FIG. 2 is an explanatory diagram of the structure of the module entry table MET and changes during debugging.

From the beginning of the module entry table MET, the entrance address of program A, the entrance address of program B,
When the entry address of program C is stored in the table, a new module entry table MET' is created by the MET update process S1. At this time, the entrance address of program A is its population address + α, and the entrance address of program B, C
The population addresses of each will also be +α. Like this ME
By executing the T update process S1 and incrementing the entry address of each program by +α, for example, when a processing request such as CALL B is generated from program A, the migration monitor MON updates the module entry table MET.
', so each module with confirmation processing added will be executed.

On the other hand, when debugging is finished and the debugging operation is switched to the system operation, the address of the module entry table MET' is changed again to -α in the MET update process S1.
do. This -α becomes the population address of each program A, B, and C in the module entry table MET shown in FIG. 2, and thereafter each module can be executed without the confirmation process.

FIG. 3 is an overall flowchart of switching between system operation and debug operation. When changing from S2 during system operation to S7 during debug operation, first, the 9 10 entry in the module entry table MET is updated in order to execute the debug processing route of the module to be debugged by debugging start processing S3. That is, the process of adding +α to the value of each module in the module entry table MET is executed. In S2 during system operation, as shown in FIG. 4, when a module is called, a jump is made from the address of module ■ stored in the module entry table MET to the entrance a of module ■. Entrance a
stores a command to execute GOTO (g), jumps to this population a, and then GOTOφ gets stuck, resulting in execution from the function execution process ■, and returns upon completion.

On the other hand, in the debugging start process S3, if the module entry table MET is changed and the debugging operation is entered (34)L, the transition monitor transfers control to the module population address in the updated module entry table MET'.

That is, as shown in FIG. 5, the module entry table MET' and the entrance address of module (2) are changed to point to entrance b. For population b, an execution unit called G0TO■ is provided, and the process is executed from ■ (■). ■
is an entry for executing the confirmation process, and after the confirmation process, the function execution process is executed from the function execution process ■ by an executable statement such as GOTO■ (■). In other words, after the confirmation process is executed, the function execution process of the target module is performed.

For example, when changing a module due to a change in functionality, etc.
After executing this confirmation process, a function execution process is performed.

When debugging is finished, debugging processing S5 is executed to restore the module entry table MET' to its original state so that the debugging route is not run. This return process is the module entry table MET
This is the process of changing the population address of ', and Figures 4 and 5
Corresponding to the figure, this is the process of changing from entrance b to entrance a.

After this change process, the module entry table MET
is the entrance only to function execution processing that does not include confirmation processing,
After that, system operation (S6) begins.

The embodiments of the present invention have been described in detail above, but the present invention provides two entrances for each module, for example, an entrance a.
, entry b jumps to function execution processing and confirmation processing, but this is not limited to this; for example, two module entry tables are provided, a table that indicates the number of confirmation processes is used during debugging, and the process is terminated. A table indicating the entrance of a module that does not include confirmation processing may be used later. Further, in the embodiment, relative addresses on the table are stored in registers, but the invention is not limited to this, and management may be performed using, for example, module numbers.

In FIG. 4, when the system is in operation, the entrance a is used as a GOT, and the (2) command is always executed, which is wasteful. Therefore, the entrances (a) and (b) may be replaced, and the MET may be made to directly point to (2).

〔Effect of the invention〕

As described above, according to the present invention, it is possible to prevent a decrease in execution speed during system operation without executing confirmation processing or the like during system operation. Also, when debugging, you can perform debugging by simply changing the entrance, and there is no need to compile each module.
You can start debugging operations in a short time with simple operations.

Furthermore, when debugging is finished, it is possible to switch to system operation in a short time with a similarly simple operation.

[Brief explanation of drawings]

Figure 1 is a diagram of the configuration of an embodiment of the present invention, Figure 2 is an illustration of the MET configuration and changes during debugging, and Figure 3 is an overall diagram of switching between system operation and debug operation. Flowchart: FIG. 4 is an explanatory diagram of processing during system operation, and FIG. 5 is an explanatory diagram of processing during debugging operation. MET...Module entry table, MON/
...Migration monitor.

Claims (1)

[Claims] Modules with different entrance addresses during system operation and debugging are managed in a control table, and the entrance address of each module in the control table is changed to the entrance address at debugging during debugging, and returned to the original address during system operation. A debugging method based on dynamic changes of module entrances.