JPH0193841A - System for evaluating program execution in data processing system - Google Patents

Abstract

PURPOSE:To collect the executing history of a module level even in a large scale system by converting a program module loading address to a unit address before a test, preparing a table and recording the unit executing history information of a program module. CONSTITUTION:When a debugger 5 is activated with a processor 1, the name, etc., of the program module is read from a module map file 9 and conversion from the loading address to the unit address is executed in a converting part 7 and the name, etc., is stored to a table 8. A control mechanism 3 is operated in each successive execution of an instruction and the corresponding bit of a unit executing history recorder 4 is turned on. Then, information from the device 4 are read in an editing part 6 and the unit executing history of a range to correspond to the module name in the table 8 are collated, edited and outputted to an output device 10.

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention relates to a software debugger used for program testing in a data processing system.

[Conventional technology]

As data processing systems have become increasingly large-scale in recent years, there has been an increasing demand for ensuring software quality.

As a means of ensuring software quality, the concept of test coverage, which evaluates the presence or absence of execution at the instruction level and the presence or absence of execution in program modules, is becoming popular. In order to realize this, devices and debuggers have been devised.

Conventional devices and debuggers have been able to collect execution history at the instruction level at high speed using hardware.

Furthermore, the execution history of a program module is collected by inserting a trap instruction at the beginning of a program module and generating an interrupt when the program module is executed.

[Problem that the invention seeks to solve]

The above conventional technology is suitable for large-scale data processing systems.
There is no consideration given to the collection and editing of the execution history at the program module level of the entire system, and a large number of instruction execution history recording devices are used.

The problem is that it is difficult to apply to large-scale data processing systems because it is necessary to have a 18-J history of execution at the instruction level, and it is necessary to embed trap instructions in every program module. .

With the present invention, even when the data processing system to be tested is large-scale, it is possible to quickly collect and edit the execution history at the program module level with a small amount of hardware and without changing the program contents. I have to.

[Means for solving problems]

The above purpose is to record the execution history of a unit, which is a subset of a program module divided into a fixed size, by using the instruction address register of the data processing system name, excluding the lower part corresponding to the unit, as the unit address. Unit execution history recording control mechanism stored in a recording device, name of a program module loaded into the main memory in a data processing system.

and a module map file storing the loading address of the program module on the main memory, and a program module name from the module map file before the test starts.

Module/unit address conversion within the Lutebugger, which has means for reading the program module loading address, converting the program module loading address into the above unit address, and storing the program module name in the module unit address correspondence table. and the unit execution history information of the unit execution history recording device, collate the unit execution history in the range corresponding to the program module name in the module/unit address correspondence table, and based on this result, read out the unit execution history information of the unit execution history recording device. Edit execution history,
This is accomplished by a module execution history editing section within the debugger that calculates and edits the execution ratio of program modules corresponding to all program modules and outputs the same to an output device.

[Effect]

In the present invention, when a test target program is executed, the execution history of a program module is not directly collected, but unit execution history information, which is a component of a program module, is recorded in a unit execution history recording device. After the test is completed, the program module is executed using the contents of the unit execution history recording device and the information in the module/unit address correspondence table created by converting the program module loading address into a unit address before the start of test execution. get.

In the present invention, since a hardware mechanism is used to collect the program execution history, there is no need to change the contents of the program for test execution. Furthermore, since there is no need to record the execution history for each instruction, the capacity of the recording device for recording the execution history of the program module and the hardware mechanism for controlling it can be reduced.

〔Example〕

An embodiment of the present invention will be described below with reference to FIGS. 1 and 2. FIG. 1 shows the configuration of an embodiment, and FIG. 2 shows an explanation of the processing of the debugger.

In FIG. 1, 1 is a processor, 2 is an instruction address register in the processor, 3 is a unit execution record history control mechanism in the processor, 4 is a unit execution history recording device, 5 is a debugger loaded in the processor, and 6 is a unit execution record history control mechanism in the processor. Reference numeral 7 represents a module execution history browsing section within the debugger, numeral 7 represents a module/unit address conversion section within the debugger, numeral 8 represents a module unit address correspondence table within the debugger, numeral 9 represents a module map file, and numeral 10 represents an output device.

In addition, the unit in FIG. 1 is a set of 128-byte instructions and tosses the constituent unit of the program module.

Below is the debugger processing according to Figure 2. :explain.

Debugger 5 on processor 1? : Upon startup, as shown in step 1, the debugger 5 reads the name of the program module operating within the data processing system and the loading address of the program module onto the main memory from the module map file 9, and then as shown in step 2. The converting section 7 converts the module rope ink address into a unit address by removing the unit unit part, that is, the lower 7 bits, and stores the program module name and unit address in the module unit address correspondence table. Next, when the test target program is executed as shown in step 3, the unit history recording control mechanism 5 in the processor 1 is activated each time the instructions are sequentially executed, as shown in step 4.
The corresponding bit of the unit execution history recording device pointed to by the address excluding the bottom seven pits of the instruction address register 2 in the processor 1 is turned on. Next, as shown in step 5, the module execution history editing section 6 in the debugger 5
reads the unit execution history information from the unit execution four-layer recording device 4, and then checks the unit execution history in the range corresponding to the program module name in the module/unit address correspondence table as shown in step 6. Execute the program module based on the results
The editing and execution ratios of program modules for all program modules Ki are collected in total i-=. Next, as shown in step 7, the module execution history editing unit 6 executes the program module kjlW.

The program module execution ratio is output to the output device 10.

According to this embodiment, since the execution history is not collected for each instruction in order to collect the execution history of the program module,
The storage capacity of the M(2S) device for storing the execution history is 1/128th that of storing the execution history on an instruction-by-instruction basis.

〔Effect of the invention〕

According to the present invention, instead of editing the execution history of a program module based on information collected for each instruction, a method is adopted in which the execution history of a program module is edited based on execution history information collected for each unit, which is a set of instructions. ing.

Therefore, the capacity of the storage device for recording the execution history can be reduced.

Furthermore, since the execution history of program modules is collected by hardware, there is an advantage that there is no need to change the contents of the program to be tested.

[Brief explanation of the drawing]

FIG. 1 is a block diagram of an embodiment of the present invention, and FIG. 2 is a flowchart of the processing of the debugger and device. 1... Processor, 2... Instruction address register,
5... Debugger, 6... Module execution history editing section, 7... Module/unit address conversion section, 8.
...Module unit address compatible tapes h, q...
・Module map file, 1o...Output device. , I::・j11゛τ. , ------cho (1'll!: □th f concave

Claims (1)

[Claims] 1. In a data processing system that sequentially executes instructions recorded in the main memory, a mechanism that indicates the loading address and name of a program module loaded onto the main memory, and a portion in which the program module is divided into fixed sizes. a unit execution history recording device for recording the execution history of a unit that is a set; a hardware mechanism that controls when unit execution history information is stored in the unit execution history recording device; Read execution history information,
Means for editing the execution history of a program module from a mechanism indicating the loading address of the program module on the main memory and the program module name, and a means for editing the program module execution history for all program modules within a specified range within the data processing system. A program execution evaluation method for a data processing system, characterized by providing a means for calculating a Yule execution ratio.