JP2677249B2 - Program debugging method and debugger for multiprocessor system - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a program debugging technique for a multiprocessor system, and more particularly to a specific CP
The present invention relates to a program debugging technique that enables debugging with a breakpoint at U.

[0002]

2. Description of the Related Art A debugger for debugging an OS (operating system) of a processor system is called a kernel debugger. Generally, in a processor system that does not have a hardware breakpoint mechanism,
The kernel debugger directly writes the break instruction on the text of the OS to realize the debugging by the breakpoint. Such a method is generally called a software breakpoint control method, and it is not limited to a single processor system, but is disclosed in, for example, Japanese Patent Application No. 5-14.
It is also used in debugging multiprocessor systems, as seen in 5646.

[0003]

However, when the software breakpoint control method is applied to the multiprocessor system, the break instruction written on the text is executed by all CPUs capable of executing the logic including the break instruction. Therefore, a break occurs in the CPU that first executed the break instruction. For this reason, the specific C desired by the operator
It becomes difficult to proceed with debugging by catching the time when the PU executes the break instruction.

The present invention has been proposed in view of such circumstances, and an object thereof is to advance debugging in a multiprocessor system by catching a time point when a particular CPU desired by an operator reaches a breakpoint. Is to be able to.

[0005]

In order to achieve the above object, the present invention is characterized in that in the first invention, the following steps are taken. (A) A step of setting CPU designation information corresponding to a breakpoint address in the breakpoint management table. (B) A step of shifting all CPUs under the control of a debugger when a break point exception occurs, with the only CPU that first generated the exception as a master CPU and all the remaining CPUs as slave CPUs. (C) In the CPU that has become the master CPU, its own CPU
Is a CPU included in the CPU designation information corresponding to the address of the generated breakpoint exception in the breakpoint management table. (D) A step of advancing to a stage of analyzing and executing a debug command from an operator in the CPU that has become the master CPU when it is determined that the CPU is the corresponding CPU. (E) A step of returning all the CPUs from the debugger control to the original state by determining that the breakpoint exception this time is invalid when it is determined that the CPU is not the corresponding CPU.

Further, in the second aspect of the present invention, a configuration for executing the following procedure is adopted in place of the procedure (E). (E-1) If it is determined that the CPU is not the corresponding CPU, the CPU that has become the master CPU is the slave CPU that has caused the breakpoint exception at the address of the generated breakpoint exception in the breakpoint management table. And a step of determining whether or not there is a slave CPU whose CPU designation information is included in the CPU designation information corresponding to the breakpoint address. (E-2) When it is determined that the corresponding slave CPU exists, the existing slave CPU is changed to the master CPU, the CPU that has become the master CPU is changed to the slave CPU, and the new master CPU is added. Became C
In the PU, the step of proceeding to the stage of analyzing and executing the debug command from the operator. (E-3) A step of returning all CPUs from the debugger control to the original state when it is determined that the corresponding slave CPU does not exist.

As a debugger applied to such a program debugging method, a common entrance processing section which is called when a breakpoint exception occurs and performs a save processing of register information or the like regarding the calling CPU, and the common entrance processing section Is called from the master CPU information already C
A master / slave CPU determination unit that determines a slave CPU when PU information is set, and determines a master CPU by setting own CPU information when not set, and the master / slave CPU determination unit And master CPU
If the CPU is determined to be the master CPU, the master CPU is executed by the CPU that has become the master CPU, and if the master / slave CPU determination unit determines that the CPU is a slave CPU, the CPU is the slave CPU. In the master CPU control section, all CPUs other than itself are slave CPUs under the debugger control. Debugger system synchronization part to shift and CP set in the breakpoint management table corresponding to the breakpoint address
Based on the U specification information, it is determined whether a breakpoint exception has occurred in the CPU specified by the operator, and if it has not occurred, all CPUs are returned to their original state from under debugger control, and an exception occurs. Although it is occurring C
If PU is a slave CPU, its slave C
Breakpoint control unit for each CPU that changes PU to a new master CPU, and command analysis that analyzes and executes debug commands from the operator only when a breakpoint exception occurs in the CPU specified by the operator / Execution unit.

[0008]

For example, when it is desired to catch and debug the time when a specific CPU (denoted by α) of a plurality of CPUs reaches the breakpoint address (denoted by β), the information of the CPU α corresponding to the breakpoint address β is stored. Set it in the breakpoint management table. When a breakpoint exception occurs in any of the CPUs during the operation of the multiprocessor system, the only CPU that generated the exception first is the master CPU, all the remaining CPUs are slave CPUs, and all the CPUs are controlled by the debugger. Move down. Next, in the CPU that has become the master CPU, its own CPU C corresponding to the address of the generated breakpoint exception in the breakpoint management table.
It is determined whether or not the CPU is included in the PU designation information. Then, when it is determined that such a CPU,
That is, when the CPU α causes a breakpoint exception at the breakpoint address β, the CPU α proceeds to the stage of analyzing and executing the debug command from the operator. However, the CPU that is not the corresponding CPU, that is, the CPU that caused the breakpoint exception first is CPU α.
If not, the breakpoint exception this time is invalidated, and all CPUs are returned to the original state from under the debugger control. By the above operation, the debugging can be advanced by catching the time when the specific CPU α desired by the operator reaches the breakpoint address β.

In a multiprocessor system, a plurality of CPUs execute processing in parallel, so that a breakpoint exception may occur at a plurality of CPUs almost at the same time. In such a case, there is no problem if the CPU α desired by the operator becomes the CPU that caused the exception first and becomes the master CPU, but another CPU becomes the master CPU and the CPU α desired by the operator becomes the slave CPU. In the above-mentioned configuration, the specific C
Even though PUα has reached the breakpoint address β, it misses that opportunity. Therefore, in the second invention, C which is the master CPU
If PU is not the corresponding CPU α, its master C
In the PU, a slave CPU that has caused a breakpoint exception at the address of the generated breakpoint exception in the breakpoint management table, and the CPU designation information corresponding to the breakpoint address includes the CPU information. It is determined whether or not there is a slave CPU that is present. When it is determined that the corresponding slave CPU does not exist, all CPUs are returned to the original state from under the control of the debugger, but when it is determined that the corresponding slave CPU exists, the slave CPU, that is, CPU α Is changed to a master CPU, and the CPU that has been the master CPU is changed to a slave CPU, and the new CPU becomes a CPU α.
In the above, the process proceeds to the stage of analyzing and executing the debug command from the operator.

[0010]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Next, embodiments of the present invention will be described in detail with reference to the drawings.

Referring to FIG. 1, a multiprocessor system to which an embodiment of the present invention is applied includes a plurality of CPUs 1.
5 to 5, a shared memory 6 shared by these CPUs 1 to 5, a secondary storage device 7 such as a magnetic disk device,
It is composed of a console 8 and a system bus 9 which connects these to each other. The CPUs 1 to 5 are processors of the same type, for example, R300 manufactured by MIPS.
A CPU such as 0 or R4000 is used. Further, in FIG. 1, 100 is an OS (operating system) to be debugged, and 200 is a debugger (kernel debugger).

FIG. 2 is a block diagram of the main part of the debugger 200. The debugger 200 includes a common entrance processing unit 10 that is called from exception processing when a breakpoint exception occurs during operation of a multiprocessor system, and a master CP.
A master / slave CPU discriminating unit 11 that separates a master CPU and a slave CPU depending on whether or not the CPU information can be set first in the U information 15, and a master CPU control unit 12 that is executed by the CPU that has become the master CPU. And the slave CP executed by the CPU that has become the slave CPU
The U control unit 13, the common exit processing unit 14 that returns to the state at the time of calling the debugger 200, the breakpoint management table 16 in which various pieces of information regarding breakpoints are set, the CPU that has become the master CPU, and the slave It includes a slave command flag 17 and a slave command information structure 18 that are referenced and updated with the CPU that has become the CPU.

The master CPU control unit 12 includes a debugger system synchronization unit 121, a CPU-specific break point control unit 122, and a command analysis / execution unit 123. The slave CPU control unit 13 includes a command request standby unit 131.
And a command request processing unit 132.

FIG. 3 shows a breakpoint management table 16
An example of the contents of one entry is shown. In the figure, 161 is a breakpoint address designated by the operator, and this breakpoint address 161 is publicly known.
The instruction of OS100 corresponding to is replaced with a break instruction that causes a breakpoint exception. Also, 162 indicates the original instruction replaced with the break instruction, and 163 is a CPU information field corresponding to the breakpoint address 161, in which information (for example, CPU number) for specifying the CPU the operator desires to break is provided. Is set.

FIG. 4 is a flow chart showing an example of processing of the CPU-specific break point control unit 122 of the master CPU control unit 12, FIG. 5 is a flow chart of command exchange between the master CPU and slave CPUs, and FIG. 6 is a slave command information structure. A configuration example of the body 18 is shown respectively. Hereinafter, the operation of this embodiment will be described with reference to the drawings.

When setting a breakpoint in the OS 100 by the debugger 200, the operator also specifies which CPU the breakpoint is valid for.
The effective CPU may be one CPU or plural CPUs. When the operator requests a breakpoint setting from the console 8 by the debugger 200,
The location of the address in the OS 100 which is requested to set a breakpoint is replaced with a break instruction, and the breakpoint address 161 and the original instruction 162 are set in the breakpoint management table 16 as shown in FIG. Further, the CPU information field 163 is set with the information of the CPU specified by the operator and in which the breakpoint is valid.

When a breakpoint exception occurs in any of the CPUs during the operation of the multiprocessor system, the common entrance processing unit 10 of the debugger 200 is called from the exception processing in the CPU that generated the breakpoint exception.

In the common entrance processing section 10, the C point is set so that it can be returned to the time when the breakpoint exception occurs later.
Saves PU register information, etc., master / slave C
The PU discriminating unit 11 is called.

The master / slave CPU discriminating unit 11 refers to the master CPU information 15, and if nothing is set therein, the own CPU can become the master CPU. Set to
Debugger system synchronization unit 12 of master CPU control unit 12
Call 1. On the other hand, when other CPU information has already been set in the master CPU information 15, it becomes a slave CPU and calls the command request standby unit 131 of the slave CPU control unit 13. Note that when referring to the master CPU information 15, the master CPU information 15 is locked by the lock function.
When the lock cannot be locked, it is referred to for the first time. If nothing is set, the lock is released after setting the own CPU information.

Therefore, the breakpoint exception is the only C
If it occurs only in PU, the CPU is the master CPU
Becomes On the other hand, if the breakpoint exceptions occur in a plurality of CPUs at substantially the same time, the CPU that first wrote its own CPU information in the master CPU information 15 is the master CPU.
And the remaining CPU that generated the breakpoint exception
Is a slave CPU.

Next, in the CPU which has become the master CPU and called the debugger system synchronization section 121, the C
In order to shift all the CPUs other than the PUs under the control of the debugger as slave CPUs, the other CPUs are requested to enter the control of the debugger 200 through interprocessor communication. The other CPU that has received this request calls the common entrance processing unit 10 of the debugger 200 to save the register information of its own CPU and the like, and then calls the master / slave CPU determination unit 11, at which point the master CP
Since other CPU information has already been set in the U information 15, it becomes a slave CPU and calls the command request standby unit 131. Note that the CPU that cannot become the master CPU when a breakpoint exception has occurred is already the slave C.
Since it is a PU, the debugger system synchronization unit 121
The request to move to the debugger control by is ignored.

Through the above processing, when a breakpoint exception occurs, only the first CPU that has generated the exception becomes the master CPU, all the remaining CPUs become slave CPUs, and all the CPUs are under the control of the debugger. It has been moved.

When the processing of the debugger system synchronization section 121 on the master CPU side is completed, the CPU-specific break point control section 122 is called and the processing shown in FIG. 4 is executed on the master CPU side.

First, the address of the current breakpoint exception of the own CPU (master CPU) is the breakpoint address 161 set in the breakpoint management table 16 of FIG. 3, and the CPU corresponding to the breakpoint address. C in the information field 163
Whether or not PU information is included is checked based on the register save information of its own CPU (S1). If the result of the determination is YES, that is, if the own CPU has caused an exception at the breakpoint address set in the breakpoint management table 16 and the own CPU is the CPU designated by the operator, command analysis / The execution unit 123 is called (S2). As a result, the process proceeds to the stage where the debug command from the operator is analyzed and executed. The operation during debugging by the operator will be described below.

The command analysis / execution unit 123 analyzes the debug command input from the operator from the console 8 and executes the intended operation. As a result, various debug commands can be executed on the CPU that has become the master CPU, register save information for each CPU, and shared memory 6
The contents of can be investigated. Further, in this embodiment, the debug execution unit can be temporarily transferred to the slave CPU. This is performed as follows.

When the operator inputs an instruction to temporarily move the execution unit to a certain slave CPU and execute the debug command in the slave CPU, the master CPU starts the processing of FIG. Information necessary for the slave command information structure 18 (commands to be executed by the slave CPU, information to be transmitted, etc.) is set in the command field and information field (S11), and the flag corresponding to the slave CPU in the slave command flag 17 is set. It is set to 1 (S12) and waits for the flag to be changed to 0 (S13). Each slave CPU
5, the command request standby unit 131 monitors that the flag corresponding to its own CPU in the slave command flag 17 becomes 1 as shown in FIG. 5 (S21). When the flag becomes 1, the command request is sent. The processing unit 132 is called, and in this command request processing unit 132, the process according to the command and information set in the slave command information structure 18 is executed, and at the end of the execution, if there is a return value, the slave command information The return value field of the structure 18 is set (S22). Then, as a command end notification by the slave CPU, the flag corresponding to the self CPU in the slave command flag 17 is set to 0 (S2
3) Then, the process returns to the command request waiting unit 131 again. Master C
When the PU side command analysis / execution unit 123 detects that this flag is set to 0, the return value is acquired from the slave command information structure 18 (S14). As a result, the next debug command can be executed again.

The above operation is continued until the operator issues a command to be restored, and when the debugger issues a command to be restored,
The command analysis / execution unit 123 transmits a return command from the debugger to all slave CPUs using the slave command flag 17 and the slave command information structure 18, and the master CPU itself also calls the common exit processing unit 14. To return to the point at which the exception occurred from under debugger control. Each slave CPU that received a return command from the debugger
Respectively call the common exit processing unit 14 to return to the original state.

On the other hand, if the determination result of the process S1 in FIG. 4 is NO, that is, if the CPU that became the master CPU is not the CPU designated by the operator, the breakpoint address 161 set in the breakpoint management table 16 is set. Whether there is a slave CPU that has caused a breakpoint exception at the point of, and whose CPU information is included in the CPU information field 163 of the breakpoint management table 16
A check is performed based on the register save information of each slave CPU (S3). If such a slave CPU does not exist, the breakpoint exception at this time is regarded as invalid, and all CPUs are returned to the original state from under the control of the debugger 200 (S5). This is because the master CPU uses the slave command flag 17 and the slave command information structure 18 to transmit a return command from the debugger to all the slave CPUs to call the common exit processing unit 14,
It is realized by calling the common exit processing unit 14 itself.

If there is a corresponding slave CPU as a result of the determination in the process S3 of FIG. 4, the current master CPU uses the slave command flag 17 and the slave command information structure 18 to find the corresponding slave CPU. The master CPU change command is transmitted to the slave CPU, and the slave CPU itself becomes the slave CPU and calls the command request standby unit 131 by the slave CPU. On the other hand, the slave CPU, which has received the command for changing the master CPU, changes the master CPU information 15 to become the master CPU, calls the command analysis / execution unit 123, and enables the debugging operation by the operator.

The embodiments of the present invention have been described above.
The present invention is not limited to the above embodiments, and various other additions and changes are possible. For example, if it is determined NO in step S1 of FIG. 4, all CPUs may be immediately returned from the debugger control to the original state.

[0031]

As described above, according to the present invention,
It becomes possible to debug with a breakpoint only on a specific CPU. As a result, it becomes possible to perform debugging focusing on each individual CPU, and the operation and state of the multiprocessor system can be known in detail.

According to the second aspect of the present invention, even if the CPU desired by the user and the other CPUs cause the breakpoint exception at approximately the same time, the CPU desired by the user is set as the master CPU. It is possible to proceed with debugging.

[Brief description of the drawings]

FIG. 1 is a block diagram showing a configuration example of a multiprocessor system to which an embodiment of the present invention is applied.

FIG. 2 is a configuration diagram of a main part of a debugger.

FIG. 3 is a diagram showing an example of contents of one entry of a breakpoint management table.

FIG. 4 is a flowchart illustrating a processing example of a CPU-specific break point control unit of a master CPU control unit.

FIG. 5 is a flowchart of command exchange between a master CPU and a slave CPU.

FIG. 6 is a diagram showing a configuration example of a slave command information structure 18.

[Explanation of symbols]

 1 to 5 ... CPU 6 ... Shared memory 7 ... Secondary storage device 8 ... Console 9 ... System bus 10 ... Common entrance processing unit 11 ... Master / slave CPU discrimination unit 12 ... Master CPU control unit 13 ... Slave CPU control unit 14 ... Common exit processing unit 15 ... Master CPU information 16 ... Breakpoint management table 17 ... Slave command flag 18 ... Slave command information structure 100 ... Operating system (OS) 121 ... Debugger system synchronization unit 122 ... Breakpoint control unit for each CPU 123 Command analysis / execution unit 131 Command request waiting unit 132 Command request processing unit 161 Break point address 162 Original instruction 163 CPU information field

 ─────────────────────────────────────────────────── ─── Continuation of the front page (56) Reference JP-A-2-153442 (JP, A) JP-A-3-15949 (JP, A) JP-A-6-332747 (JP, A) JP-A-6- 75820 (JP, A) JP 4-314141 (JP, A) JP 4-248635 (JP, A) JP 2-64826 (JP, A) JP 5-20120 (JP, A) Japanese Patent Laid-Open No. 5-313946 (JP, A) Special Table 5-508046 (JP, A)

Claims (5)

(57) [Claims] 1. A program debugging method for a tightly coupled multiprocessor system in which a plurality of CPUs share a memory, and (A) a step of setting CPU designation information corresponding to a breakpoint address in a breakpoint management table. (B) A step of shifting all CPUs under the control of a debugger when a break point exception occurs, with the only CPU that first generated the exception as a master CPU and all the remaining CPUs as slave CPUs. (C) In the CPU that has become the master CPU, its own CPU
Is a CPU included in the CPU designation information corresponding to the address of the generated breakpoint exception in the breakpoint management table. (D) A step of advancing to a stage of analyzing and executing a debug command from an operator in the CPU that has become the master CPU when it is determined that the CPU is the corresponding CPU. (E) A step of returning all the CPUs from the debugger control to the original state by determining that the breakpoint exception this time is invalid when it is determined that the CPU is not the corresponding CPU. A program debugging method for a multiprocessor system, comprising: 2. In place of the step (E) of claim 1, (E-1) when it is determined that the CPU is not the corresponding CPU, the CPU which has become the master CPU stores in the breakpoint management table. Whether or not there is a slave CPU that has caused a breakpoint exception at the address of the breakpoint exception that has occurred and in which CPU information is included in the CPU designation information corresponding to that breakpoint address. Step to determine if. (E-2) When it is determined that the corresponding slave CPU exists, the existing slave CPU is changed to the master CPU and the own CPU that has been the master CPU
Is changed to a slave CPU and the CPU, which has become the new master CPU, proceeds to the step of analyzing and executing a debug command from the operator. (E-3) A step of returning all CPUs from the debugger control to the original state when it is determined that the corresponding slave CPU does not exist. A program debugging method for a multiprocessor system characterized by executing a program. 3. In the step (B), (B-1) it is judged whether or not the CPU information is set in the master CPU information, and if not set, the own CPU information is set and the own CPU is set. Master CPU, already CPU
If the information is set, the step of making the own CPU a slave CPU. (B-2) A step in which the CPU that has become the master CPU requests another CPU to shift to the debugger-controlled state through inter-processor communication. 3. The program debugging method for a multiprocessor system according to claim 1, wherein the program debugging method is realized by. 4. In a program debugging method of a tightly coupled multiprocessor system in which a plurality of CPUs share a memory, a common entrance processing unit for performing save processing of register information about the CPU, and CPU information is already set in the master CPU information. If it is, the master / slave CPU determination unit that determines the slave CPU if it is not set and determines the master CPU by setting its own CPU information, the master CPU executed by the CPU that has become the master CPU A control unit, a slave CPU control unit executed by the CPU that has become a slave CPU, and a common exit processing unit that performs processing for returning to the original state from under debugger control, and a CPU other than itself in the master CPU control unit. As a slave CPU to move under debugger control. And Temu synchronization unit, which is set in the break point management table in correspondence with breakpoint address CP
Based on the U designation information, the CPU-specific breakpoint control unit for determining whether or not the occurred breakpoint exception has occurred in the CPU designated by the operator, and the debug command from the operator is analyzed and executed. Using a kernel debugger having a command analysis / execution unit, in the CPU that has caused the breakpoint exception, execute the common entry processing unit to save register information and the like, and then execute the master / slave CPU determination unit. According to the determination result, the master CPU control unit or the slave CPU control unit is executed, and in the master CPU executing the master CPU control unit, the debugger system synchronization unit is executed to debug all other CPUs as slave CPUs. After shifting to control, the CPU-specific break point By executing the command control unit, it is determined whether or not the generated breakpoint exception has occurred in the CPU designated in the breakpoint management table, and the command analysis /
A program debugging method for a multiprocessor system, characterized in that an execution unit is executed. 5. In a debugger of a tightly coupled multiprocessor system in which a memory is shared among a plurality of CPUs, a common entrance processing unit that is called when a breakpoint exception occurs and saves register information and the like regarding the calling CPU, When the common entrance processing unit calls and the CPU information is already set in the master CPU information, the slave CP
Master / slave CP that judges U, and if not set, sets own CPU information and judges as master CPU
The CPU that is called when the U discriminating unit and the master / slave CPU discriminating unit have determined that the master CPU is the master CPU.
And a slave CPU control unit that is called when the master / slave CPU determination unit determines that the CPU is a slave CPU and that is executed by the CPU that has become the slave CPU. A common exit processing unit for returning to the state of the above, further, in the master CPU control unit, a debugger system synchronization unit that shifts all CPUs other than itself to slave CPUs under debugger control, and a breakpoint address Based on the CPU designation information set in the breakpoint management table,
CP with breakpoint exception specified by operator
It is judged whether or not it is occurring in U, and if it is not occurring, all CPUs are returned to the original state from under the control of the debugger. If it is occurring, but the originating CPU is a slave CPU, The slave CPU is the new master CP
Breakpoint control unit for each CPU to change to U and CP for which a breakpoint exception is specified by the operator
A debugger for a multiprocessor system, comprising: a command analysis / execution unit that analyzes and executes a debug command from an operator only when it occurs in U.