JP7401751B2 - Information processing program, information processing method, and information processing system - Google Patents

Description

The present invention relates to an information processing program, an information processing method, and an information processing system.

During the development and operation of a server system, an operation analysis of the server system using a test program may be performed in each phase of performance analysis, power evaluation, operation test, or field investigation. When an error is detected during execution of a test program, an analysis of the internal operation of the hardware is performed. Then, based on the results, the cause of the error is estimated, a simulation model is created, and debugging is performed using the simulation model.

As methods for analyzing the internal behavior of hardware, there are methods that use simulation to obtain and display waveform data and communication history of various buses, and methods that obtain and display the instruction execution history left in the memory of the actual device.

Note that there has conventionally been a technology that has a function of monitoring, analyzing, recording, and displaying operation information related to pipeline control in an information processing apparatus having an in-order execution type processor (see, for example, Patent Document 1).

Furthermore, processors are known that are equipped with a mechanism called out-of-order, which executes instructions that have all the data necessary for processing, regardless of the order of instructions written in a program.

Japanese Patent Application Publication No. 9-244912

Server systems are becoming larger and more complex, and the number of man-hours required for operation analysis is increasing. Among system behavior analysis tasks, analyzing the internal behavior of hardware such as processors is the most difficult and difficult to observe. In recent years, processors have become more complex due to increases in the number and types of hardware modules included in processors and the adoption of out-of-order technology, making it more difficult to predict the cause of errors when executing test programs. For this reason, there was a problem in that debugging time became long.

In one aspect, the present invention aims to provide an information processing program, an information processing method, and an information processing system that can reduce debugging time.

In one embodiment, operational information regarding the operation of a plurality of hardware modules in the processor is obtained for each predetermined occurrence event when the test program is executed by the processor, and based on the operational information, the test program is executed. Generating debugging information including information indicating a correspondence relationship between the described software operation and the hardware operation by the hardware used when executing the test program, and outputting the debugging information to a computer. An information processing program to be executed is provided.

In one embodiment, an information processing method is also provided.
Also, in one embodiment, an information processing system is provided.

In one aspect, the present invention can reduce debugging time.

FIG. 1 is a diagram illustrating an example of an information processing system according to a first embodiment. FIG. 3 is a diagram illustrating an example of an information processing system according to a second embodiment. FIG. 3 is a diagram showing an example of the internal configuration of a core and a tracer module. FIG. 3 is a diagram showing an example of each stage of pipeline processing. 3 is a flowchart illustrating an example of an operation information acquisition process. FIG. 3 is a diagram illustrating an example of operation information acquired in each instruction execution cycle. FIG. 3 is a diagram illustrating an example of hardware of a debugging work execution server. FIG. 2 is a block diagram illustrating a functional example of a debugging work execution server. 3 is a flowchart illustrating an example of a process for generating and displaying debugging information. 3 is a flowchart illustrating an example of a data registration process. It is a figure which shows the example of registration of a data table. FIG. 3 is a diagram showing an example of a data table for registering write data. 7 is a flowchart illustrating an example of a process for displaying an execution completion command and related information. 3 is a flowchart illustrating an example of the flow of instant data display processing. 3 is a flowchart illustrating an example of a pipeline flush process. FIG. 6 is a diagram illustrating an example of how debugging information is displayed on a display. FIG. 3 is a diagram showing a processing flow of an example of debugging work.

Hereinafter, embodiments for carrying out the invention will be described with reference to the drawings.
(First embodiment)
FIG. 1 is a diagram showing an example of an information processing system according to the first embodiment.

The information processing system 10 includes a processor 11, a storage device 12, a debug device 13, and a display device 14.
The processor 11 is, for example, an arithmetic processing device such as a CPU (Central Processing Unit) or a DSP (Digital Signal Processor). Processor 11 may include multiple processor cores. Processor 11 executes a test program stored in storage device 12. The processor 11 may be an arithmetic processing device that performs out-of-order execution or pipeline processing, may be an arithmetic processing device that has a superscalar processing mechanism, or may be an arithmetic processing device that performs processing that is a combination of these. It may be.

The processor 11 also includes a plurality of hardware modules 11a1, 11a2, . . . , 11an that execute test programs, and an acquisition circuit 11b.
The hardware modules 11a1 to 11an perform operations according to the test program.

The acquisition circuit 11b acquires operational information regarding the operations of the hardware modules 11a1 to 11an for each predetermined event that occurs during execution of the test program. The predetermined events include, for example, instruction decoding processing, register write processing, and address translation processing from virtual addresses to physical addresses. Examples of operation information include decoded instruction data, numbers of registers written (hereinafter referred to as physical general-purpose registers), write data, and numbers of registers written in the test program (hereinafter referred to as logical general-purpose registers). be.

Note that when pipeline processing is performed, these pieces of operation information are acquired together with a pipeline number (hereinafter referred to as pipeline ID (IDentification)) assigned to the instruction that generated the operation information.

The acquisition circuit 11b has, for example, a RAM (Random Access Memory), and holds the acquired operation information in the RAM. The acquisition circuit 11b may output the retained operation information and store it in the storage device 12 when the execution of the test program is completed. Note that the acquisition circuit 11b does not acquire operational information every cycle, but acquires operational information for each predetermined event that occurs, so that the amount of data held in the RAM can be reduced.

The hardware modules 11a1 to 11an and the acquisition circuit 11b may include, for example, an electronic circuit for a specific purpose such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field Programmable Gate Array).

The storage device 12 is a volatile storage device such as a RAM, or a nonvolatile storage device such as a flash memory, an EEPROM (Electrically Erasable Programmable Read Only Memory), or an HDD (Hard Disk Drive).

The debug device 13 includes a processing section 13a and a storage section 13b.
The processing unit 13a is, for example, a processor such as a CPU or a DSP as an arithmetic processing device. The processing unit 13a may include multiple processors or multiple processor cores. Further, the processing unit 13a may include an electronic circuit for a specific purpose such as an ASIC or an FPGA.

The processing unit 13a executes the program stored in the storage unit 13b. For example, the processing unit 13a executes an information processing program as described below.
The storage unit 13b is a volatile storage device such as a RAM, or a nonvolatile storage device such as a flash memory, EEPROM, or HDD.

The storage unit 13b stores various programs and also stores various data used when the processing unit 13a executes the programs. Further, the storage unit 13b may store a test program executed by the processor 11.

When the processing unit 13a starts executing the information processing program, the processing unit 13a first obtains the operation information output by the acquisition circuit 11b (step S1). If the operational information output by the acquisition circuit 11b is stored in the storage device 12, the processing unit 13a acquires (reads) the operational information from the storage device 12. Note that the operation information output by the acquisition circuit 11b may be transmitted to the debug device 13 by a communication device (not shown). Further, the processing unit 13a may temporarily store the acquired motion information in the storage unit 13b.

Based on the acquired operation information, the processing unit 13a generates debugging information including information indicating the correspondence between the software operation described in the test program and the hardware operation by the hardware used when executing the test program. Generate (step S2). For example, if the software operation described in the test program is an addition process using a certain logical general-purpose register, the debug information includes the number and write data of the physical general-purpose register used in the addition process.

Then, the processing unit 13a outputs the generated debugging information (step S3). For example, the processing unit 13a outputs debugging information to the display device 14 for display. FIG. 1 shows a display example of debugging information.

In the example of FIG. 1, SW (software) operation information and used HW (hardware) operation information are shown as information about the instruction execution completion time and the instructions completed at that time. The SW operation information and the used HW operation information indicate the correspondence between software operations and hardware operations. In the example of FIG. 1, the SW operation information specifies "add" indicating addition processing, "r1" indicating the number of the logical general-purpose register to be used, and two values to be added, "0x10" and "0x10". . Further, as used HW operation information, "r1" representing the number of the physical general-purpose register to be used and write data "0x20" written as a result of the addition process are shown. In this example, the numbers of the logical general-purpose register and the physical general-purpose register are the same, so they match. However, when the processor 11 performs register renaming during out-of-order execution, the logical general-purpose register and the physical general-purpose register have different numbers and do not match.

Note that the processing unit 13a may output debugging information to the storage unit 13b and store it.
Although not shown in FIG. 1, the processing unit 13a then uses, for example, a simulator (simulation software) to generate expected behavior information representing the expected behavior by the test program, and causes the display device 14 to display the generated expected behavior information. Then, the user performs debugging work by comparing, for example, the expected operation information displayed on the display device 14 with the debugging information. After identifying the problem location through debugging, the investigation is focused on the hardware module related to the identified problem location.

The debugging information obtained by the above method includes information that shows the correspondence between software operations and the operations of the hardware actually used, so it is easy to understand the correspondence between the two and identify the location where the problem occurs. becomes easier. This increases debugging efficiency and reduces debugging time. Therefore, it is possible to improve the efficiency of the operation analysis work of the system including the processor 11 and shorten TAT (Turn Around Time).

Note that the processing content of the processing unit 13a of the debug device 13 may be performed by the processor 11 after the acquisition circuit 11b acquires the operation information. In that case, the above information processing program will be executed by the processor 11.

(Second embodiment)
FIG. 2 is a diagram illustrating an example of an information processing system according to the second embodiment.
The information processing system 20 of the second embodiment includes a test target server system 21 and a debugging work execution server 22. The test target server system 21 includes a processor 31, a main storage device 32, and an external storage device 33.

The processor 31 is, for example, an arithmetic processing device such as a CPU or a DSP, and has the same functions as the processor 11 shown in FIG. However, in the information processing system 20 of the second embodiment, the processor 31 includes a plurality of (m) processor cores (hereinafter simply referred to as cores) 31a1, 31a2, . . . , 31am, and a tracer module 31b.

Each of the cores 31a1 to 31am has a function of performing out-of-order execution, a function of performing superscalar processing, and a function of performing pipeline processing.
The tracer module 31b has the same function as the acquisition circuit 11b shown in FIG. An example of the internal configuration of the tracer module 31b will be described later.

The main storage device 32 is a volatile storage device such as a DRAM (Dynamic Random Access Memory), and the external storage device 33 is a nonvolatile storage device such as a flash memory, EEPROM, or HDD.

Note that the test target server system 21 may include a communication interface, an input/output interface, etc., but illustration thereof is omitted in FIG. 2.
The debugging work execution server 22 has the same functions as the debugging device 13 shown in FIG. A hardware example of the debugging work execution server 22 will be described later.

FIG. 3 is a diagram showing an example of the internal configuration of the core and tracer module.
Each of the cores 31a1 to 31am has a plurality of hardware modules. For example, as shown in FIG. 3, the core 31a1 includes a plurality of (n) hardware modules 41a1, 41a2, . . . , 41an. Each of the cores 31a2 to 31am similarly has n hardware modules.

Each of the hardware modules 41a1 to 41an is, for example, a circuit that performs processing at each stage of pipeline processing, which will be described later. Each of the hardware modules 41a1 to 41an is connected to another one of the hardware modules 41a1 to 41an, for example, via a flip-flop (not shown).

The tracer module 31b has a controller 31b1 and a RAM 31b2. The controller 31b1 is connected to each of the hardware modules of the cores 31a1 to 31am, and determines whether a predetermined event has occurred based on signals output from each hardware module. When the controller 31b1 determines that a predetermined event has occurred, the controller 31b1 acquires operation information indicating the operation of the hardware module related to the event and writes it into the RAM 31b2.

FIG. 4 is a diagram showing an example of each stage of pipeline processing.
The stages of pipeline processing (hereinafter referred to as pipeline stages) include a stage ST1 that performs branch prediction, a stage ST2 that performs instruction fetch, and a stage ST3 that performs instruction decoding. Furthermore, the pipeline stages include a stage ST4 that performs fixed-point calculations, a stage ST5 that performs floating-point calculations, a stage ST6 that performs memory access, a stage ST7 that performs branch processing, and a stage ST8 that performs commit (termination processing).

Stage ST4 includes a stage ST4a that issues fixed-point arithmetic instructions in order of priority, and a stage ST4b that executes fixed-point arithmetic. Stage ST5 includes a stage ST5a that issues floating point arithmetic instructions in order of priority, and a stage ST5b that executes floating point arithmetic. Stage ST6 includes a stage ST6a that issues memory access commands in priority order, a stage ST6b that performs address calculation (conversion), and a stage ST6c that executes memory access. Stage ST7 includes a stage ST7a that issues branch instructions in order of priority, and a stage ST7b that performs branch control according to the branch instructions.

An example of the operation information acquisition process by the test target server system 21 will be described below.
FIG. 5 is a flowchart illustrating an example of the operation information acquisition process.
First, the processor 31 reads, for example, a test program stored in the external storage device 33 and starts executing the test program (step S10). The controller 31b1 of the tracer module 31b sets the module number i, which indicates the number of the hardware module whose state is to be checked, to 0 (step S11). Then, the controller 31b1 checks the state (module state) of the hardware module with module number i (step S12).

Then, when the hardware module with module number i generates the following event in the pipeline stage shown in FIG. 4, the controller 31b1 acquires the following operation information (step S13: YES).

When the hardware module with module number i fails in branch prediction at stage ST1, the controller 31b1 acquires information indicating the failure in branch prediction outputted by the hardware module as operation information.

When the hardware module with module number i decodes an instruction in stage ST3, the controller 31b1 acquires instruction data that is the decoding result output by the hardware module. The controller 31b1 also obtains the pipeline ID assigned to the decoded instruction. When multiple instructions are decoded, the controller 31b1 obtains a pipeline ID for each instruction.

When the hardware module with module number i writes to a physical general-purpose register in stages ST4 to ST7, the controller 31b1 acquires the physical general-purpose register number and write data output by the hardware module.

When the hardware module with module number i generates store data in stages ST4b and ST5b, the controller 31b1 acquires the store data output by the hardware module and the pipeline ID assigned to the store instruction.

When the hardware module with module number i completes the load instruction in stage ST6c, the controller 31b1 acquires the load data output by the hardware module and the pipeline ID assigned to the load instruction.

When the hardware module with module number i completes address translation in stage ST6b, the controller 31b1 acquires the virtual address and physical address output by that hardware module. Further, the controller 31b1 obtains the pipeline ID assigned to the memory access instruction (load instruction or store instruction).

When the hardware module with module number i completes the processing of stage ST8, the controller 31b1 acquires the following operation information output by that hardware module. The controller 31b1 acquires the current program counter value, the number of instructions that have completed execution, and the pipeline ID assigned to the instructions that have completed execution. Furthermore, the controller 31b1 acquires the number of the logical general-purpose register written in the test program regarding the instruction that has completed execution, and the number of the physical general-purpose register actually used when executing the instruction. The controller 31b1 also acquires the pipeline ID assigned to the instruction that caused the write to the physical general-purpose register and the authority level at the time of completion of the instruction execution.

When the hardware module with module number i reads or writes to an architecture register in the processing of stages ST1 to ST8, the controller 31b1 acquires the number of the architecture register output by that hardware module.
The controller 31b1 also acquires flag information indicating that a read or write has been performed, and read data or write data output by the hardware module.

When an exception (abnormality) occurs in the processing of stages ST1 to ST8 in the hardware module with module number i, the controller 31b1 acquires information output by the hardware module indicating that an exception has occurred.

When a pipeline flush occurs in the hardware module with module number i during the processing of stages ST1 to ST8, the controller 31b1 acquires information indicating that a pipeline flush has occurred that is output by the hardware module.

When the hardware module with module number i outputs information indicating the occurrence of any of the above events, the controller 31b1 acquires operational information related to the event and writes it into the RAM 31b2 (step S14). After the process in step S14, or when the operation information is not acquired (step S13: NO), while i<N (the total number of observation target hardware modules) (step S15: NO), the controller 31b1 calculates i=i+1. (Step S16). After the processing in step S16, the processing from step S12 is repeated.

When i=N (step S15: YES), if the execution of the test program has not finished (step S17: NO), the instruction execution cycle is advanced by the cores 31a1 to 31am that execute the test program (step S18). After the processing in step S18, the processing from step S11 is repeated.

When the execution of the test program is completed (step S17: YES), the controller 31b1 outputs the operation information stored in the RAM 31b2 and stores it in the storage device (main storage device 32 or external storage device 33) (step S19). ). This completes the operation information acquisition process.

Note that the order of the above processing is an example, and the order may be changed as appropriate. Further, the operation information does not need to be stored in the main storage device 32 or the external storage device 33, and may be transmitted to the debugging work execution server 22 through a communication interface (not shown), for example.

FIG. 6 is a diagram illustrating an example of operation information acquired in each instruction execution cycle. In FIG. 6, "N/A" indicates that the corresponding operation information has not been acquired.
When the instruction execution cycle is 980 cycles, by decoding the instruction, the instruction data "DATA" which is the decoding result of two instructions and the pipeline ID (decoded instruction pipeline ID) assigned to each instruction "0, 1" ” has been obtained.

When the instruction execution cycle is 990 cycles, the physical general-purpose register number "0" and write data (physical general-purpose register write data) "20" are acquired by writing to the physical general-purpose register.

Even when the instruction execution cycle is 995 cycles, the physical general-purpose register number "3" and write data "30" are acquired by writing to the physical general-purpose register.
When the instruction execution cycle is 1000 cycles, the execution of two instructions is completed, so the program counter value is "100", the number of executed instructions is "2", and the pipeline ID assigned to the executed instruction (execution completed instruction Pipeline ID) “0” has been acquired.

Furthermore, the logical general-purpose register numbers "1, 2" written in the test program regarding the executed instruction and the physical general-purpose register numbers "0, 2" actually used when executing that instruction are obtained. . In this example, since the numbers of the logical general-purpose registers and the numbers of the physical general-purpose registers are different, it can be seen that register renaming was performed as a result of out-of-order execution, for example. In addition, the pipeline ID (target instruction pipeline ID) “0, 1” assigned to the instruction that instructed the write to the physical general-purpose register with the above number and the authority level “N” at the time of instruction execution completion are obtained. has been done. "N" represents normal.

Next, an example of the hardware of the debugging work execution server 22 will be shown.
FIG. 7 is a diagram illustrating an example of hardware of a debug work execution server.
The debugging work execution server 22 includes a CPU 51 , a RAM 52 , an HDD 53 , an image signal processing section 54 , an input signal processing section 55 , a medium reader 56 , and a communication interface 57 . The above units are connected to a bus.

The CPU 51 is a processor that includes an arithmetic circuit that executes program instructions. The CPU 51 loads at least part of the program and data stored in the HDD 53 into the RAM 52, and executes the program. Note that the CPU 51 may include multiple processor cores, the debug work execution server 22 may include multiple processors, and the processes described below may be executed in parallel using multiple processors or processor cores. good. Furthermore, a set of multiple processors (multiprocessor) may be referred to as a "processor."

The RAM 52 is a volatile semiconductor memory that temporarily stores programs executed by the CPU 51 and data used for calculations by the CPU 51. Note that the debugging work execution server 22 may include a type of memory other than RAM, or may include a plurality of memories.

The HDD 53 is a nonvolatile storage device that stores software programs such as an OS (Operating System), middleware, and application software, and data. The program includes, for example, an information processing program that causes the debugging work execution server 22 to execute an information processing method for generating debugging information. Note that the debugging work execution server 22 may include other types of storage devices such as flash memory and SSD (Solid State Drive), or may include a plurality of nonvolatile storage devices.

The image signal processing unit 54 outputs an image to a display 54a connected to the debugging work execution server 22 in accordance with instructions from the CPU 51. As the display 54a, a CRT (Cathode Ray Tube) display, a liquid crystal display (LCD), a plasma display (PDP), an organic electro-luminescence (OEL) display, etc. can be used. .

The input signal processing unit 55 acquires an input signal from an input device 55a connected to the debugging work execution server 22, and outputs it to the CPU 51. As the input device 55a, a pointing device such as a mouse, a touch panel, a touch pad, or a trackball, a keyboard, a remote controller, a button switch, or the like can be used. Further, a plurality of types of input devices may be connected to the debugging work execution server 22.

The medium reader 56 is a reading device that reads programs and data recorded on the recording medium 56a. As the recording medium 56a, for example, a magnetic disk, an optical disk, a magneto-optical disk (MO), a semiconductor memory, etc. can be used. Magnetic disks include flexible disks (FDs) and HDDs. Optical discs include CDs (Compact Discs), DVDs (Digital Versatile Discs), Blu-ray (registered trademark), and the like.

For example, the media reader 56 copies programs and data read from the recording medium 56a to other recording media such as the RAM 52 and the HDD 53. The read program is executed by the CPU 51, for example. Note that the recording medium 56a may be a portable recording medium, and may be used for distributing programs and data. Furthermore, the recording medium 56a and the HDD 53 are sometimes referred to as computer-readable recording media.

The communication interface 57 is an interface that is connected to the network 57a and communicates with other information processing devices via the network 57a. The communication interface 57 may be a wired communication interface connected to a communication device such as a switch via a cable, or a wireless communication interface connected to a base station via a wireless link.

Note that the communication interface 57 may be connected to the server system under test 21 via the network 57a, or may be directly connected to the server system under test 21.

The test target server system 21 shown in FIG. 2 can also be realized with the same hardware configuration as above, but in that case, the CPU 51 would include the tracer module 31b as shown in FIG.

Next, the functions and processing procedures of the debugging work execution server 22 will be explained.
FIG. 8 is a block diagram showing a functional example of the debugging work execution server.
The debug work execution server 22 includes an operation information acquisition section 60 , a debug information generation section 61 , a debug information output section 62 , a debug work execution section 63 , and a storage section 64 .

The operation information acquisition section 60, the debug information generation section 61, the debug information output section 62, and the debug work execution section 63 can be implemented using, for example, a program module executed by the CPU 51. The storage unit 64 can be implemented using, for example, a storage area secured in the RAM 52 or the HDD 53.

The motion information acquisition unit 60 acquires motion information. If the operational information acquisition unit 60 can directly access the external storage device 33 of the test target server system 21, the operational information acquisition unit 60 acquires the operational information stored in the external storage device 33 by reading it. When the test target server system 21 transmits operational information to the debugging work execution server 22 , the operational information acquisition unit 60 acquires the operational information by receiving the operational information using the communication interface 57 . The motion information acquisition unit 60 temporarily stores the acquired motion information in the storage unit 64.

The debugging information generation unit 61 generates debugging information based on the operation information stored in the storage unit 64.
The debugging information output unit 62 displays debugging information on the display 54a.

The debugging work execution unit 63 uses, for example, a simulator to generate expected behavior information representing the expected behavior of the test program, and causes the display 54a to display the generated expected behavior information. The debugging work execution unit 63 may identify the problematic operation of the processor 31 based on the debugging information and the expected operation information, and display the result on the display 54a.

The storage unit 64 stores acquired operational information, generated (or in the process of being generated) debugging information, and the like.
FIG. 9 is a flowchart showing an example of the process of generating and displaying debugging information. In addition, below, the operation information shown in FIG. 6 will be explained by dividing it into the following types A to J.

The operation information of type A is the program counter value, the number of executed instructions, and the executed instruction pipeline ID.
Type B operation information is instruction data and decode instruction pipeline ID.

The operation information of type C is the authority level.
Type D operation information is architecture register number, architecture register write data, and architecture register read data.

The operation information of type E is a physical general-purpose register number, physical general-purpose register write data, completed physical general-purpose register number, completed logical general-purpose register number, and target instruction pipeline ID.
The operation information of type F is store data, store instruction pipeline ID, load data, and load instruction pipeline ID.

The operation information of type G is a virtual address, a physical address, and a load/store instruction pipeline ID.
The operation information of type H is branch prediction failure information.

Type I operation information is exception occurrence information.
The operation information of type J is pipeline flush information.
Furthermore, hereinafter, the above-mentioned instruction execution cycle will be referred to as simulation time.

The debug information generation unit 61 sets the simulation time t to the simulation start time t _start (step S20). The debugging information generating unit 61 reads the operational information acquired by the tracer module 31b at the simulation time t from among the operational information stored in the storage unit 64 (step S21).

Then, the debug information generation unit 61 determines whether or not the read operation information includes operation information of types B, E, F, and G (step S22). When the debugging information generation unit 61 determines that there is operation information of types B, E, F, and G, it performs a data registration process to be described later (step S23).

After the processing in step S23, or when it is determined that there is no operation information of type B, E, F, or G, the debugging information generation unit 61 determines whether to write to the physical general-purpose register based on the read operation information. It is determined whether or not (step S24). When the debugging information generation unit 61 determines that there is a write to the physical general-purpose register, it performs a write data registration process to be described later (step S25).

After the processing in step S25, or when it is determined that there is no write to the physical general-purpose register, the debugging information generation unit 61 determines whether or not there is an execution completion instruction based on the read operation information (step S26). If it is determined that there is an execution completion instruction, the debugging information output unit 62 performs a process of displaying the execution completion instruction and related information, which will be described later (step S27).

After the processing in step S27, or when it is determined that there is no execution completion instruction, the debugging information generation unit 61 determines whether or not the read operation information includes data of types D, H, and I (step S28). If it is determined that there is data of type D, H, or I, the debugging information output unit 62 performs an immediate data display process to be described later (step S29).

After the process in step S29, or when it is determined that there is no data of type D, H, or I, the debugging information generation unit 61 determines whether or not there is a pipeline flush based on the read operation information. (Step S30). If it is determined that there is a pipeline flush, the debug information generation unit 61 and the debug information output unit 62 perform pipeline flush processing, which will be described later (step S31).

After the processing in step S31, or when it is determined that there is no pipeline flush, the debugging information generation unit 61 determines whether the simulation time t has reached the end simulation time t _end (step S32). The end simulation time t _end represents the last simulation time (instruction execution cycle) at which the processor 31 acquires the operation information.

If the debugging information generation unit 61 determines that the simulation time t has not reached the end simulation time t _end , it increments the simulation time t by 1 (step S33), and repeats the processing from step S21. If the debugging information generation unit 61 determines that the simulation time t has reached _{the end} simulation time tend, it ends the debugging information generation and display processing.

Note that the order of processing shown in FIG. 9 is an example, and the order may be changed as appropriate. For example, the processes in steps S28 and S29 may be performed before the processes in steps S22 and S23.

FIG. 10 is a flowchart showing an example of the flow of data registration processing.
When the data registration process is started, the debug information generation unit 61 determines whether or not the read operation information includes decoded instruction data (step S40). If the debugging information generation unit 61 determines that there is instruction data, it registers the instruction data in the data table constructed in the storage unit 64 (step S41). The instruction data is written in a write field for instruction data in an area in which operation information linked to the decode instruction pipeline ID is written in the data table.

After the processing in step S41, or when it is determined that there is no instruction data, the debugging information generation unit 61 determines whether or not the read operation information includes conversion data of physical/logical general-purpose register numbers (step S42). ). The presence or absence of physical/logical general-purpose register number conversion data can be determined from, for example, the completed physical general-purpose register number and the completed logical general-purpose register number among the operation information shown in FIG. In the example of FIG. 6, since the completed physical general-purpose register number and the completed logical general-purpose register number are different, it is determined that conversion data exists (register renaming has been performed).

When the debugging information generation unit 61 determines that there is conversion data, it registers the physical/logical general-purpose register numbers (in FIG. 6, the completion physical general-purpose register number and the completion logical general-purpose register number) in the data table (step S43). ). The physical/logical general-purpose register number is written in the write field for the physical/logical general-purpose register number in the area in which the operation information linked to the target instruction pipeline ID is written in the data table.

After the processing in step S43, or when it is determined that there is no conversion data, the debugging information generation unit 61 determines whether or not there is store data in the read operation information (step S44). If it is determined that there is store data, the debug information generation unit 61 registers the store data in the data table (step S45). The store data is written in a write field for store data among the areas in the data table where the operation information linked to the store instruction pipeline ID is written.

After the processing in step S45, or when it is determined that there is no store data, the debugging information generation unit 61 determines whether or not the read operation information includes load data (step S46). If it is determined that there is load data, the debug information generation unit 61 registers the load data in the data table (step S47). The load data is written in a field for writing load data in an area in which operation information linked to the load instruction pipeline ID is written in the data table.

After the processing in step S47, or when it is determined that there is no load data, the debugging information generation unit 61 determines whether or not the read operation information includes address conversion data (step S48). The presence or absence of address translation data can be determined, for example, by whether or not the operation information shown in FIG. 6 includes a virtual address and a physical address. If a virtual address and a physical address are included, it is determined that address translation data exists (address translation has been performed).

If the debugging information generation unit 61 determines that there is address translation data, it registers the virtual address and physical address in the data table (step S49). The physical/logical general-purpose register number is written in the virtual address and physical address write fields in the data table where the operation information linked to the load/store instruction pipeline ID is written.

After the process in step S49, or when it is determined that there is no address translation data, the debug information generation unit 61 ends the data registration process.
Note that the order of the above processing is an example, and the order may be changed as appropriate.

FIG. 11 is a diagram showing an example of registration of a data table.
In the data table in the example of FIG. 11, the storage position of the motion information associated with the pipeline ID (0, 1, 2, . . . , MAX (maximum value)) is specified by a pointer. This pipeline ID is used as the above-mentioned execution completion instruction pipeline ID, decode instruction pipeline ID, target instruction pipeline ID, store instruction pipeline ID, load instruction pipeline ID, or load/store instruction pipeline ID. ing.

For example, as shown in FIG. 11, instruction data "0x2a0803e0", physical general-purpose register number "0", logical general-purpose register number "1", etc. are registered as operation information linked to pipeline ID = 0. . In addition, instruction data “0x9b084ee8”, store data “0x20”, load data “N/A”, virtual address “0x1000”, physical address “0x1000”, etc. are registered as operation information linked to pipeline ID = 2. has been done.

In this way, the debugging information generation unit 61 generates debugging information by collecting operation information for each pipeline ID. Thereby, appropriate debugging information can be generated even for the processor 31 that performs complex processing using pipeline processing. Furthermore, by collecting logical general-purpose register numbers and physical general-purpose register numbers in association with each other from operation information, it is possible to generate appropriate debugging information even when register renaming occurs.

In the write data registration process of FIG. 9, the debugging information generation unit 61 registers write data in the data table for write data registration built in the storage unit 64.
FIG. 12 is a diagram showing an example of a data table for registering write data.

In the data table for registering write data, the physical general-purpose register number indicating the physical general-purpose register to which the write was performed and the write data are written. If the same physical general-purpose register number is already registered in the data table for write data registration, the write data will be overwritten.

FIG. 13 is a flowchart illustrating an example of a process for displaying execution completion commands and related information.
First, the debugging information output unit 62 causes the display 54a to display the simulation time t, authority level, and program counter value included in the read operation information (step S50). Furthermore, the debugging information output unit 62 reads out the instruction data linked to the execution completion instruction pipeline ID and registered in the data table from the storage unit 64 and displays it on the display 54a (step S51).

After that, the debugging information generation unit 61 determines whether the physical general-purpose register number linked to the execution completion instruction pipeline ID has been registered in the data table as shown in FIG. 11 (step S52). . If it is determined that the physical general-purpose register number has been registered, the debugging information output unit 62 reads out the logical general-purpose register number registered in the data table together with the physical general-purpose register number from the storage unit 64 and displays it on the display 54a. It is displayed (step S53). Further, the debugging information output unit 62 reads out the physical general-purpose register number and the write data registered in the data table for write data registration shown in FIG. 12 from the storage unit 64 and displays them on the display 54a. Step S54).

After the processing in step S54, or if it is determined that the physical general-purpose register number has not been registered, the debugging information output unit 62 determines whether the store data linked to the execution completed instruction pipeline ID has been registered in the data table. It is determined whether or not (step S55). If it is determined that the store data has been registered, the debugging information output unit 62 reads the store data and the virtual address and physical address registered in the data table together with the store data from the storage unit 64 and displays them on the display 54a. It is displayed (step S56).

After the process of step S56 or when it is determined that the store data has not been registered, the debugging information output unit 62 determines whether the load data linked to the execution completion instruction pipeline ID has been registered in the data table. is determined (step S57). If it is determined that the load data has been registered, the debugging information output unit 62 reads the load data and the virtual address and physical address registered in the data table together with the load data from the storage unit 64 and displays them on the display 54a. It is displayed (step S58).

After the process of step S58 or when it is determined that the load data has not been registered, the debugging information output unit 62 (or the debugging information generating unit 61) outputs the operation information linked to the execution completion instruction pipeline ID into a data table. (Step S59).

Thereafter, the debugging information output unit 62 finishes displaying the execution completion instruction and related information.
Note that the above processing order is an example, and the display order of various types of operation information may be changed as appropriate.

FIG. 14 is a flowchart showing an example of the flow of the instant data display process.
The debug information output unit 62 determines whether the read operation information includes architecture register read/write data (read data or write data) (step S60). If it is determined that there is architecture register read/write data, the debugging information output unit 62 causes the display 54a to display the simulation time t and the architecture register read/write information included in the read operation information (step S61). The architecture register read/write information includes an architecture register number and architecture read/write data.

After the processing in step S61, or when it is determined that there is no architecture register read/write data, the debugging information output unit 62 determines whether or not the read operation information includes branch prediction failure information (step S62). . If it is determined that there is branch prediction failure information, the debugging information output unit 62 causes the display 54a to display the simulation time t and the branch prediction failure information included in the read operation information (step S63).

After the processing in step S63, or when it is determined that there is no branch prediction failure information, the debugging information output unit 62 determines whether or not the read operation information includes exception occurrence information (step S64). If it is determined that there is exception occurrence information, the debugging information output unit 62 causes the display 54a to display the simulation time t and the exception occurrence information included in the read operation information (step S65).

After the processing in step S65, or when it is determined that there is no exception occurrence information, the debugging information output unit 62 ends the immediate data display processing.
Note that the above processing order is an example, and the display order of various types of operation information to be immediately displayed may be changed as appropriate.

FIG. 15 is a flowchart showing an example of the flow of pipeline flush processing.
The debugging information output unit 62 causes the display 54a to display the simulation time t and pipeline flush information included in the read operation information (step S70).

Then, the debug information generation unit 61 deletes all information registered in the data table as shown in FIG. 11 (step S71), and ends the pipeline flush process.

FIG. 16 is a diagram showing an example of how debugging information is displayed on the display.
In the example of FIG. 16, the authority level "N" (normal), the program counter value "00000100", and the instruction data "2a0803e0" are shown as information about the addition instruction completed when the simulation time t is "1000". . Further, "add r1, 0x10, 0x10" represents r1=0x10+0x10. “r1” indicates that the logical general-purpose register number is “1”. “r1 write:0x20” indicates that write data “0x20” has been written to the physical general-purpose register with physical general-purpose register number “1”.

Further, as information about the addition instruction completed at the same time, authority level "N", program counter value "00000104", and instruction data "2a0803e2" are shown. Furthermore, "add r2, r1, 0x10" represents r2=r1+0x10. "r2" indicates that the logical general-purpose register number is "2". “r2 write:0x30” indicates that write data “0x30” has been written to the physical general-purpose register with physical general-purpose register number “2”.

Further, as information about the store instruction completed when the simulation time t is "1020", authority level "N", program counter value "00000108", and instruction data "9b084ee8" are shown. Further, "store r1,0x1000" indicates that the data of the logical general-purpose register with the logical general-purpose register number "1" is stored at the address "0x1000" of the main storage device 32 in FIG. “store: VA=0x1000, PA=0x1000, data=0x20” indicates that store data “0x20” is stored at virtual address (VA) “0x1000” and physical address (PA) “0x1000”.

Further, as information about the load instructions completed at the same time, authority level "N", program counter value "0000010c", and instruction data "8b084ee8" are shown. Moreover, "load r1,0x1000" indicates that data at address "0x1000" of the main storage device 32 in FIG. 2 is loaded into the logical general-purpose register with the logical general-purpose register number "1". “r1 write:0x20” indicates that load data “0x20” has been written to the physical general-purpose register with physical general-purpose register number “1”. “load: VA=0x1000, PA=0x1000, data=0x20” indicates that the load data “0x20” was loaded from the virtual address (VA) “0x1000” and the physical address (PA) “0x1000”.

As information about the store instruction completed when the simulation time t is "1036", authority level "N", program counter value "00000110", and instruction data "8b080ee8" are shown. Further, "store r1,0x0" indicates that the data of the logical general-purpose register with the logical general-purpose register number "1" is stored at the address "0x0" of the main storage device 32 in FIG.

It is shown that an exception has occurred when the simulation time t is "1068". It is also shown that a pipeline flush occurred at the same time.
As information about the branch (jump) instruction completed when the simulation time t is "1080", authority level "H" (high), program counter value "00000000", and instruction data "f940d661" are shown. “jump 0x1000” indicates that a branch is to be made to the instruction at address “0x1000”.

It is shown that a failure in branch prediction has occurred when the simulation time t is "1132". It is also shown that a pipeline flush occurred at the same time.

It is shown that when the simulation time t is "1150", write data "0x10" is written to the architecture register with the architecture register number "arch_reg1".

Further, as information about the write instruction to the architecture register completed at the same time, authority level "H", program counter value "00001000", and instruction data "3944014a" are shown. Further, “write arch_reg1,0x10” indicates that write data “0x10” is written to the architecture register with the architecture register number “arch_reg1”.

In the display example above, the operation contents such as "add r1, 0x10, 0x10" are not included in the debugging information generated as described above, but are calculated based on the decoded instruction data and the test program. , can be generated by the debug information output unit 62.

After displaying the debugging information, the debugging work execution unit 63 generates expected behavior information representing the expected behavior obtained when the test program is executed by, for example, a simulator, and displays it on the display 54a. For example, the user performs debugging work by comparing the displayed expected operation information with the debugging information.

For example, if an error occurs in which the data stored in the main storage device 32 differs from the expected value included in the expected operation information, the user can identify the location of the problem by comparing the debugging information and the expected operation information. conduct.

For example, first, when loading data, it is verified whether the data or address differs from the expected value. If the data or address differs from the expected value when the data is loaded, it is further verified whether the data or address differed from the expected value during the previous data store. If the data or address differs from the expected value at the time of data storage, it is further verified whether data different from the expected value was generated in the previous arithmetic processing when creating the store data. If data different from the expected value is generated in the arithmetic processing, it is further verified whether data different from the expected value was read when the previous architectural register was read. As described above, by following the operations in order, it is possible to identify the location where the problem occurs.

After identifying the problem location through debugging, the investigation is focused on the hardware module related to the identified problem location.
Note that the debugging work execution unit 63 may identify the location where the problem occurs based on the debugging information and the expected operation information.

FIG. 17 is a diagram showing a processing flow of an example of debugging work.
The debugging work execution unit 63 generates expected behavior information representing the expected behavior obtained when the test program is executed by a simulator or the like (step S80). Then, the debugging work execution unit 63 performs the above-described verification processing based on the debugging information and the expected behavior information to identify the problem behavior (problem occurrence location) (step S81). Note that the debugging work execution unit 63 may display the identification result on the display 54a.

The debugging information output unit 62 displays debugging information including information indicating the correspondence between the software operation and the actually used hardware operation on the display 54a, thereby confirming the correspondence between the two. It becomes easier to understand and identify the location where the problem occurs.

This increases debugging efficiency and reduces debugging time. Therefore, it is possible to improve the efficiency of the operation analysis work for the server system under test 21 and shorten the TAT.
Note that, as described above, the above processing contents can be realized by causing the debugging work execution server 22, which is a computer, to execute a program.

The program can be recorded on a computer-readable recording medium (for example, the recording medium 56a). As the recording medium, for example, a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc. can be used. Magnetic disks include FDs and HDDs. Optical discs include CDs, CD-Rs (recordables)/RWs (rewritables), DVDs, and DVD-Rs/RWs. A program may be recorded on a portable recording medium and distributed. In that case, the program may be copied from the portable recording medium to another recording medium (for example, HDD 53) and executed.

Although one aspect of the information processing program, information processing method, and information processing system of the present invention has been described above based on the embodiments, these are only examples, and the present invention is not limited to the above description.

10 Information Processing System 11 Processor 11a1 to 11an Hardware Module 11b Acquisition Circuit 12 Storage Device 13 Debugging Device 13a Processing Unit 13b Storage Unit 14 Display Device

Claims (6)

Information regarding the operation of a plurality of hardware modules in the processor for each predetermined occurrence event when a test program is executed by the processor, the number of a first register specified in a first instruction of the test program. and a number of a second register used when executing the first instruction,
Based on the operation information, the correspondence relationship between the software operation described in the test program and the hardware operation by the hardware used when executing the test program is shown, and the number of the first register and the Generate debugging information including information associated with the number of the second register ,
outputting the debugging information;
An information processing program that causes a computer to perform processing. The operation information is linked to a pipeline number assigned to each of the plurality of instructions when each of the plurality of instructions of the test program is decoded,
2. The information processing program according to claim 1, which causes the computer to execute a process of generating the debug information by collecting the operation information linked to each pipeline number. The first register is different from the second register ,
3. The computer according to claim 1 or 2, wherein the computer executes a process of generating the debugging information by correlating and collecting the first register number and the second register number from the operation information. The information processing program described. Claim 1: Generating expected behavior information representing expected behavior by the test program, and causing the computer to execute a process of identifying problematic behavior of the processor based on the generated expected behavior information and the debugging information. The information processing program according to any one of items 3 to 3. The computer is
Information regarding the operation of a plurality of hardware modules in the processor for each predetermined occurrence event when a test program is executed by the processor, the number of a first register specified in a first instruction of the test program. and a number of a second register used when executing the first instruction,
Based on the operation information, the correspondence relationship between the software operation described in the test program and the hardware operation by the hardware used when executing the test program is shown, and the number of the first register and the Generate debugging information including information associated with the number of the second register ,
outputting the debugging information;
Information processing method. a plurality of hardware modules that execute test programs; and an acquisition circuit that acquires operational information regarding the operations of the plurality of hardware modules and outputs the operational information for each predetermined event that occurs during execution of the test program. , a processor comprising:
The operation information outputted by the acquisition circuit is acquired, and based on the operation information, the correspondence relationship between the software operation described in the test program and the hardware operation by the hardware used when executing the test program. a debug device that generates debug information including information indicating and outputs the debug information;
An information processing system with

Images