JPH04321139A - Debug back-up device - Google Patents

Abstract

PURPOSE:To accurately break the execution of each task working in a multi- task OS by using a means which breaks the execution of a program in terms of hardware with no reliance on a task context. CONSTITUTION:A CPU 11 is provided with a hardware break point register 12 serving as a breaking means which breaks the execution of a program in terms of hardware, a software tarp generating means 13 which shifts the control to a processing routine registered previously when a certain instruction is carried out, and a program counter 14 which stores the address value of the program under execution. The execution of a task is broken when the instruction contained in the task is rewritten into a TRAP instruction. Furthermore the original instruction that is broken with rewrite into the TRAP instruction is executed again after the register 12 is set to the address of the original instruction.

Description

[Detailed description of the invention]

0001

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a debugging support device for supporting debugging of software when developing software necessary to operate hardware such as a microprocessor.

0002

2. Description of the Related Art In order to operate hardware such as a microprocessor, software, a so-called program, is required. When developing this program, we actually run the developed program or the program under development on the hardware and check whether the hardware operates as intended by the program.
It is necessary to find and correct program defects.

[0003] The work of searching for and correcting problems in a program is called debugging. When debugging this program, break (interrupt) the program execution once after executing the program up to a certain address.
Then, by checking whether the contents of memory, registers, etc. at that point are the correct values corresponding to the parts of the program that have been executed up to that point, and if they are not correct, by checking from what point they are correct. , it is very useful to know the address where the program no longer works properly.

A breakpoint register is known as a means for breaking the execution of a program using hardware as described above. This breakpoint register is provided in the CPU, and by executing an instruction set in the breakpoint register, control is transferred to a pre-registered processing routine. The transfer of control to this pre-registered processing routine is called the occurrence of a trap.

[0005] When using breakpoint registers, there is a problem in that only that many breakpoints can be set at the same time. Therefore, a known method is to rewrite the instruction that generates the trap and the instruction of the program to be debugged (debugged program) to break the execution of the program. Such a method is called a software break. With this method, a break can be generated simply by rewriting an instruction, so it is possible to arbitrarily set the addresses and number of addresses at which program execution is to be broken.

[0006] The conventional method of breaking the execution of a program using software as described above will be specifically explained below.

FIG. 13 is a schematic diagram showing the software configuration of a conventional debugging support device.

In FIG. 13, reference numeral 1 indicates a debugged program to be debugged, and 3 indicates a debugger which is a system program for debugging.

FIG. 14 is a block diagram showing the hardware configuration of a conventional debugging support device.

In FIG. 14, reference numeral 5 is a keyboard for inputting data, 6 is a display (CRT) for displaying data, and 7 is a magnetic storage device for storing data and programs. 8 is an internal bus, 9 is a read-only memory (ROM) that stores programs and data for controlling this debug support device, 10 is a random access memory (RAM) that stores programs to be debugged, etc., 11 is a central bus. It is a processing unit (CPU).

The CPU 11 includes a trace trap generating means 16 that transfers control to a pre-registered processing routine each time one instruction of the program is executed, and a trace trap generating means 16 that transfers control to a pre-registered processing routine when a certain instruction is executed. The program counter (PC) 14 stores the address (PC value) of the program currently being executed.

Next, the operation of the conventional debugging support device configured as described above will be explained.

FIG. 15 shows a program to be debugged 1 set with a breakpoint and executed, the execution of the program once breaking at that breakpoint, the contents of memory and registers at that point being checked, and then the address at which the break occurred. 16 to 21 are schematic diagrams showing the state of the program to be debugged 1 at each point in time.

Here, for example, a breakpoint is set in the program to be debugged 1 using a debugging support device, and the program is executed in the order of addresses from the start address of the program to be debugged 1 up to the breakpoint.
Consider a case where the contents of registers and memory at the time when program execution is broken at a breakpoint are checked, and then the program to be debugged is executed again from the address of the breakpoint.

FIG. 16 is a schematic diagram showing the initial state of the program to be debugged 1. As shown in FIG. In this initial state, the PC value points to the start address of debugged program 1, and the program has breakpoint BP set.
MOV R1, R2'' instructions are executed and a break occurs, and the contents of the memory and registers at that point are checked and debugging is performed.

First, as shown in FIG. 16, the breakpoint BP is set to "MOV" by the command output by the debugger 3.
R1, R2" instruction address (step S1). When the breakpoint BP is set, the debugger 3 sets the breakpoint B as shown in FIG.
The instruction at the address where P is set “MOV R1,
Rewrite “R2” to a TRAP instruction (Step S2)
. This TRAP instruction is an instruction that generates a software trap when executed.

Next, the program to be debugged 1 is executed by the command output by the debugger 3 (step S
3). As mentioned above, the program to be debugged 1 already has a TR.
Since the AP command is set, as shown in Figure 18,
When the PC value reaches the break point BP, the TRAP instruction of the program to be debugged 1 is executed, a trap is generated, the program execution is broken, and control is returned to the debugger 3 (step S4).

Here, after the contents of the memory and registers are checked by the command output by the debugger 3, breakpoint B is set by the command output by the debugger 3.
The program is re-executed from the address of P, that is, the address of the current PC value (step S5). At this time, the instruction “MOV R1, R
2", as shown in FIG. 19, the debugger 3 rewrites the TRAP instruction to the "MOV R1, R2" instruction (step S6), generates a trace trap by the trace trap generating means 16, and executes the "MOV R1, R2" instruction.
R1, R2'' instructions are executed (step S7).

That is, by temporarily removing the breakpoint BP and setting a trace trap, the instruction of the program to be debugged 1 that was once destroyed by the rewriting of the instruction in step S2, specifically, "MOV R1" is removed.
, R2'' instruction is executed at this point.

[0020] Since the trace strap is attached, "M"
After the "OV R1, R2" instruction is executed, a trap occurs and control is returned to the debugger 3 (step S8), as shown in FIG. , as shown in FIG. 21, the "MOV R1, R2" instruction is rewritten to a TRAP instruction (step S9). After this, the program is re-executed from the address next to the TRAP instruction (step S20).

[0021] Here, steps S2, S6, S7,
Each process in S8, S9, and S10 is executed inside the debugger 3, so it is invisible to the user using the debugging support device. From the user's perspective, each of the above processes sets breakpoint B in debugged program 1.
P is set, the program execution is interrupted at the breakpoint BP, and after checking the contents of the register and memory at that point, the program to be debugged is executed again from the address where it was interrupted.

[0022] When the execution of the program to be debugged 1 is broken using the method described above, even the memory for saving the attributes of the breakpoint and the instruction code of the address where the breakpoint was set (in this case, "MOV R1, R2") is saved. If this can be secured, a debugging support device that can set any number of breakpoints can be realized.

[0023]

[Problem to be Solved by the Invention] By the way, there is a multitasking operating system (multitasking OS) that can efficiently allocate processing time to individual independent programs (tasks) and execute the programs in a time-sharing manner. Although it has become widespread in recent years, the conventional debugging support device as described above has a problem in that it cannot accurately break the execution of a group of tasks running on this multitasking OS.

1, FIG. 3, FIG. 22 to FIG. 28 below.
Please refer to the following for an explanation of this issue.

FIG. 1 is a schematic block diagram showing the software configuration of a debugging support device for debugging a group of tasks running on a multitasking operating system.

In FIG. 1, reference numeral 2 indicates each task T1.
, T2, and T3 use common task routines, 3 is a debugger that is a system program for debugging, and 4 is a program that efficiently allocates processing time to each independent program (task). It is a multitasking operating system (multitasking OS) that executes tasks in a time-sharing manner.

FIG. 3 shows each task T1 when the task group shown in FIG. 1 is time-divisionally executed by the multitasking OS 4.
, T2, and T3 are timing charts showing execution states.

FIG. 22 shows tasks T1, T2, and T2 shown in FIG.
12 is a flowchart showing the processing content of the CPU 11 when the execution of T3 is broken by a conventional debugging support device.

FIGS. 23 to 28 are schematic diagrams showing the state of the task common routine 2 at each point in time.

[0030] The multitasking OS 4 switches the execution of tasks according to the execution priority of each task and the executable state of each task. For example, when a certain task becomes impossible to execute, the multitasking OS 4 selects and executes a task with a higher execution priority among other executable tasks.

Here, for example, the execution priority of each task is set such that the first task T1 has the highest execution priority, the second task T2 has the next highest priority, and the third task T3 has the lowest execution priority among the three tasks. It is assumed that the multitasking OS 4 executes the first task T1 when all three tasks are executable.

[0032] For example, task common routine 2 is a program that executes input/output to a magnetic disk,
Considering the case where the first task T1, the second task T2, and the third task T3 use the task common routine 2 in this order to output input/output requests to the magnetic disk 7, each task is configured as shown in FIG. executed in the same order.

In FIG. 3, the first task T1 is first executed, and the task common routine 2 is called from the first task T1. While task common routine 2 is being executed,
The first task T1 enters a state of waiting for completion of input/output, and execution switches to the second task T2. The task common routine 2 is called again from the second task T2. While the second task T2 is executing the task common routine 2, the second task T2
2 enters a state of waiting for input/output completion, and execution switches to the third task T3. Next, the task common routine 2 is called from the third task T3. Third task T3 is common routine 2
While this is being executed, the third task T3 enters a waiting state for input/output completion, or the first task T1 enters an executable state because the input/output is completed, and execution switches to the first task T1.

FIGS. 22 to 22 show the processing contents of the CPU 11 when a conventional debugging support device is used to set a breakpoint in the task common routine 2 to break the execution of the task, and then execute the program again from the address where the break occurred. This will be explained with reference to FIG.

FIG. 23 is a schematic diagram showing the initial state of the task common routine 2.
After the program is executed up to the "R1, R2" instructions, there is a break, the contents of the memory and registers at that point are checked, and debugging is performed.

First, as shown in FIG. 23, the breakpoint BP is set to "MOV" by the command output by the debugger 3.
R1, R2" instructions (step S11). When the breakpoint BP is set, the debugger 3 sets the instruction "MOV R1" at the address where the breakpoint BP is set, as shown in FIG.
, R2'' is rewritten to a TRAP instruction (Step S1
2). This TRAP instruction is an instruction that generates a software trap when executed.

Next, the first task T1 is executed according to the command output by the debugger 3 (step S13). Since the TRAP instruction has already been set in the task common routine 2 as described above, the first task T1 is broken when the TRAP instruction of the task common routine 2 is executed, as shown in FIG. , debugger 3
Control returns to (step S14).

Here, after the contents of the memory and registers are checked by the command output by the debugger 3, breakpoint B is set by the command output by the debugger 3.
The program is re-executed from the address of P, that is, the address of the current PC value (step S15). At this time, the instruction “MOV R1,” which was rewritten to the TRAP instruction first,
Since it is necessary to execute “R2”, as shown in Figure 26,
Debugger 3 uses the TRAP instruction as “MOV R1, R2”
The instruction is rewritten (step S16), a trace trap is generated by the trace trap generating means 16, and the “MO”
Execute the “V R1, R2” command (step S17
).

That is, by temporarily removing the breakpoint BP and setting a trace trap, the original instruction "MOV R1, R" of the task common routine 2, which was once destroyed by the rewriting of the instruction in step S12, is removed.
2" is executed at this point. If the execution of the task is not switched in step S18, since a trace trap is applied, after the "MOV R1, R2" command is executed, as shown in FIG. A trap is generated and control returns to the debugger 3 (step S19).

After this, in order to set the breakpoint BP again, the debugger 3 selects "MOV" as shown in FIG.
R1, R2'' instructions are rewritten to TRAP instructions (step S20). After this, the program is re-executed from the address next to the TRAP instruction (step S2).
1).

As described above, if the task is not switched in step S18, a trace trap is applied and normal operation occurs. However, information for determining whether to apply a trace trap is usually included in task context information that is rewritten when a task is switched. Therefore, when the task is switched in step S18,
Since the information for determining whether to apply a trace trap is cleared, the second task T2 is executed without applying a trace trap, and task common routine 2 is called and executed from the second task T2. .

Here, the task common routine 2 is in a state as shown in FIG. That is, breakpoint BP
has not been released, but the TRAP command has been temporarily removed and the original "MOV R1, R2" command has been set. Therefore, the execution of the second task T2 is not broken and the task common routine 2 is executed as is (step S22). This is the third step in step S18.
The task is switched to task T3 and task common routine 2 is started.
The same applies when the is being executed.

Normally, the breakpoint BP is not released, so even if the switch is made to the second task T2, the breakpoint BP is not released.
When task common routine 2 is called from task T2, execution of the task must be broken. but,
Since the right to execute the trace trap has returned to the first task T1, the trace trap will not be applied unless the information for applying the trace trap is set (step S19).

[0044] Here, steps S12, S16, S
17, S18, S19, S20, and S21 are executed inside the debugger 3, and are therefore invisible to the user using the debugging support device. From the user's perspective, each of the above-mentioned processes is executed after setting a breakpoint BP in the task common routine 2, and while the first task T1 is being executed, the program is executed at the breakpoint BP of the task common routine 2. After interrupting and checking the contents of the register and memory at that point, task common routine 2 is executed again from the address where it was interrupted. However, the breakpoint has not been canceled, and even though the second task T2 and the third task T3 have executed the task common routine 2, it is not possible to break the execution of the program.

A user using a debugging support device may set a breakpoint in the task common routine 2, but the second task T2 and the third task T
Since the execution of task No. 3 is not broken, debugging of the task group is proceeded on the assumption that the second task T2 and the third task T3 have not been executed. Therefore, in this case, if the contents of the memory and the contents of the register are rewritten by the second task T2 or the third task T3, the user will not be able to find out the cause and will be confused.

The present invention has been made to solve the above-mentioned problems, and its purpose is to provide a debugging support device that can accurately break the execution of each task running on a multitasking OS. do.

[0047]

[Means for Solving the Problems] A debugging support device according to the present invention is a debugging support device for debugging a plurality of programs that are executed individually and time-sharingly by a multitasking operating system. Trap instructions are the first software means of rewriting the original instructions that make up the program into instructions that set breakpoints by transferring control to a pre-registered processing routine when executed, and the memory that makes up the program. A second hardware means breaks the execution of the program at that address when the address is specified, and the first means rewrites the instruction in the program to a trap instruction and the
control means for causing a break in the execution of the program by specifying it in the second means, causing the original instructions of the program rewritten to the trap instructions to be executed after the break is released, and then causing the instructions in the program to be broken again by the second means; ing.

[0048]

[Operation] In the debugging support device of the present invention, when executing the original instructions of the program that have been rewritten by setting a trap instruction, which is the first means for setting a breakpoint, the program is The address of the instruction is specified to a second means of breaking execution. As a result, even if the task has been switched at the time when the original instruction that was rewritten when the breakpoint was set by the trap instruction is executed, the execution of the task is accurately broken.

[0049]

DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of the present invention will be described below with reference to FIGS. 1 to 12.

FIG. 1 is a block diagram showing the software configuration of the debugging support device of the present invention, which is basically the same configuration as the conventional one.

In FIG. 1, reference numeral 1 is a debugged program consisting of a task common routine 2 and a plurality of individually independent programs (tasks T1, T2, T3). Reference numeral 3 is a debugger which is a system program for debugging, and 4 is a multi-task operating system (multi-task OS) that efficiently allocates processing time to multiple tasks T1, T2, and T3 and executes each task in a time-sharing manner. ).

FIG. 2 is a block diagram showing the hardware configuration of the debug support device of the present invention.

In FIG. 2, reference numeral 5 is a keyboard for inputting data, 6 is a display (CRT) for displaying data, and 7 is a magnetic storage device for storing data and programs. disk,
8 is an internal bus, 9 is a read-only memory (ROM) that stores programs and data for controlling this debug support device, 10 is a random access memory (RAM) that stores programs to be debugged, etc., and 11 is a central processing unit. (CPU).

[0054] The CPU 11 includes a hardware breakpoint register 12 which is a break means for breaking the execution of a program using hardware, and a software trap which transfers control to a pre-registered processing routine when a certain instruction is executed. It is provided with a generating means 13 and a program counter (PC) 14 in which the address (PC value) of the program currently being executed is stored.

Note that the program to be debugged 1 is a RAM
10, debugger 3, multitasking OS
4 is stored in ROM9 or RAM10.

Note that when the task group shown in FIG. 1 is executed in a time-sharing manner by a multitasking OS, the execution state of each task is the same as in the conventional example shown in the timing chart of FIG.

FIG. 4 is a flowchart showing the processing content of the CPU 11 when the execution of the task shown in FIG. 1 is broken by the debug support device of the present invention.

FIGS. 5 to 10 are schematic diagrams showing the state of the task common routine 2 at each point in time.

FIG. 11 is a flowchart showing the processing contents of a pre-registered processing routine activated by the software trap generating means 13 in the debugging support device of the present invention.

FIG. 12 is a flowchart showing the processing contents of a pre-registered processing routine that is activated when an instruction set in the hardware breakpoint register 12 is executed.

It is assumed that the multitasking OS 4 and each task operate in the same manner as in the conventional example described above.

FIG. 5 is a schematic diagram showing the initial state of the task common routine 2.

[0063] Here, "" of task common routine 2 will be explained.
It is assumed that the execution of the program is temporarily broken when the "MOV R1, R2" instructions are executed, and the contents of the memory and registers are checked before debugging is performed.

First, as shown in FIG. 5, the breakpoint BP is set to "MOV" by the command output by the debugger 3.
R1, R2'' addresses (step S31).

[0065] When breakpoint BP is set,
As shown in Figure 6, the debugger 3 executes the instruction "MOV R1, R" at the address where the breakpoint BP is set.
2'' is rewritten to a TRAP instruction (step S32). This TRAP instruction is an instruction that generates a software trap when executed.

Next, the first task T1 is executed according to the command output by the debugger 3 (step S33). At this time, task common routine 2 already has TRA as described above.
Since the P command is set, the first
When the task T1 executes the TRAP instruction of the task common routine 2, a trap occurs and breaks, and control is transferred to the software trap processing routine (step S34).

In the software trap processing routine of FIG. 11, if the hardware breakpoint HBP is set (step S51), a trap is set by the TRAP instruction set at the address of the hardware breakpoint HBP, and the Since the TRAP instruction set at the address has been temporarily returned to the original instruction, the TRAP instruction is reset to the address pointed to by the hardware breakpoint HBP (step S52). The instruction “M” that was previously rewritten to the TRAP instruction in step S32
In order to execute "OV R1, R2", the TRAP instruction is rewritten as "MOV R1, R2" instruction (step S53), and then, as shown in FIG. 8, the hardware breakpoint register 12 is set to the value of that address. (Step S54), “MOV R1, R2
”The command is executed (step S55).

That is, the TRAP instruction is temporarily removed and the instruction "MOV R1, R2" of the task common routine 2 is executed. Here, if the execution of the task is not switched in step S36, since the hardware breakpoint HBP is set, the first task T
1 executes the "MOV R1, R2" instruction (step S37), a hardware breakpoint trap is activated (step S38), and a hardware breakpoint trap processing routine is activated as shown in FIG. 9 (step S39). ).

In the hardware breakpoint trap processing routine of FIG. 12, a TRAP instruction is set again at the address where the break was applied (step S61). Next, as shown in FIG. 10, the hardware breakpoint HBP is unset and control is transferred to the debugger.

Here, the program is executed again from the breakpoint address, ie, the address of the current PC value, by the command output by the debugger 3 (step S40). As can be seen from FIG. 10, the first task T1
When execution is broken and control is transferred to the debugger, the "MOVR1, R2" instructions have already been executed, so the program can be executed as is. If the task has been switched in step S36 of FIG. 4, the second task T2 is executed (step S41), and the second task T2 calls the task common routine 2 (step S42). At this point, the task common routine 2 is in a state as shown in FIG.

Hardware breakpoint register 1
2 is not included in the context of the task, so it remains as is even if the task is switched. Therefore, the execution of the second task T2 is broken (step S43). After the hardware breakpoint processing flow is executed (step S44), the processing returns to the debugger. After checking the contents of memory and registers, “M”
The program is executed again from the address following the "OV R1, R2" instruction (step S45).

In the embodiment described above, even if breakpoints are set at multiple locations in each task, execution of the task can be broken in the same way. That is, a break in the execution of a task is performed by rewriting the instruction in the task to a TRAP instruction. In other words, an arbitrary number of breakpoints can be set simultaneously by simply rewriting the instruction at the breakpoint address to a TRAP instruction. Furthermore, the original instruction that was destroyed by being rewritten to a TRAP instruction is re-executed after setting the breakpoint register to the address of the instruction. This makes it possible to set multiple breakpoints simultaneously by using one breakpoint register, and to accurately break the execution of the task even if the task is switched.

[0073]

As explained above, according to the present invention, after re-executing an instruction that has been rewritten and destroyed by setting a breakpoint, the task By using a means to break program execution in hardware without depending on the context, control is returned to the debug support device after executing the destroyed instruction, so it can run on a multitasking OS. It is possible to obtain a debugging support device that can accurately break the execution of each task being executed.

[Brief explanation of drawings]

FIG. 1 is a schematic block diagram showing the software configuration of a conventional debugging support device and the present invention for debugging a group of tasks running on a multitasking operating system.

FIG. 2 is a block diagram showing the hardware configuration of the debug support device of the present invention.

FIG. 3 is a timing chart showing the execution state of each task when the task group shown in FIG. 1 is time-divisionally executed by a multitasking OS.

FIG. 4 is a flowchart showing the processing contents when the execution of the task shown in FIG. 1 is broken by the debugging support device of the present invention.

FIG. 5 is a schematic diagram showing a state of a task common routine in an initial state of the flowchart of FIG. 4;

FIG. 6 is a schematic diagram showing the state of a task common routine at a certain point in the flowchart of FIG. 4;

7 is a schematic diagram showing the state of a task common routine at a certain point in the flowchart of FIG. 4; FIG.

FIG. 8 is a schematic diagram showing the state of a task common routine at a certain point in the flowchart of FIG. 4;

9 is a schematic diagram showing the state of a task common routine at a certain point in the flowchart of FIG. 4; FIG.

10 is a schematic diagram showing the state of a task common routine at a certain point in the flowchart of FIG. 4; FIG.

FIG. 11 is a flowchart showing the processing contents of a pre-registered processing routine activated by software trap generating means in the debugging support device of the present invention.

FIG. 12 is a flowchart showing the processing contents of a pre-registered processing routine that is activated when an instruction set in a hardware breakpoint register is executed.

FIG. 13 is a schematic diagram showing the software configuration of a conventional debug support device.

FIG. 14 is a block diagram showing the hardware configuration of a conventional debug support device.

[Figure 15] Set a breakpoint in the program to be debugged and execute it, the program execution will temporarily break at that breakpoint, the contents of memory and registers at that point will be checked, and then the program will start again from the address where the break occurred. 12 is a flowchart showing the processing contents when execution is started.

FIG. 16 is a schematic diagram showing the state of the debugged program in the initial state of the flowchart in FIG. 15;

FIG. 17 is a schematic diagram showing the state of the debugged program at a certain point in the flowchart of FIG. 15;

FIG. 18 is a schematic diagram showing the state of the debugged program at a certain point in the flowchart of FIG. 15;

FIG. 19 is a schematic diagram showing the state of the debugged program at a certain point in the flowchart of FIG. 15;

FIG. 20 is a schematic diagram showing the state of the debugged program at a certain point in the flowchart of FIG. 15;

FIG. 21 is a schematic diagram showing the state of the debugged program at a certain point in the flowchart of FIG. 15;

FIG. 22 is a flowchart showing processing details when the conventional debugging support device breaks execution of the task shown in FIG. 1;

FIG. 23 is a schematic diagram showing the state of the task common routine in the initial state of the flowchart of FIG. 22;

24 is a schematic diagram showing the state of a task common routine at a certain point in the flowchart of FIG. 22; FIG.

25 is a schematic diagram showing the state of the task common routine at a certain point in the flowchart of FIG. 22; FIG.

26 is a schematic diagram showing the state of the task common routine at a certain point in the flowchart of FIG. 22; FIG.

FIG. 27 is a schematic diagram showing the state of the task common routine at a certain point in the flowchart of FIG. 22;

FIG. 28 is a schematic diagram showing the state of the task common routine at a certain point in the flowchart of FIG. 22;

[Explanation of symbols]

1 Program to be debugged 2 Task common routine 3 Debugger 4 Multitasking operating system (
Multitasking OS) 12 Hardware breakpoint register 1
3 Software trap generation means T1, T2
, T3 task

Claims (1)

[Claims] 1. A debugging support device for debugging a plurality of programs that are executed independently and time-sharingly by a multitasking operating system, wherein instructions constituting the program are registered in advance by their execution. a first software means for rewriting an instruction to transfer control to a processing routine; a second means for breaking the execution of the program at the specified address by specifying a memory address constituting the program; and the first means. By rewriting the instruction in the program to the instruction and specifying its address to the second means, the execution of the program is broken, and after the break is released, the original instruction of the program rewritten to the instruction is executed. and control means for causing the second means to break the instructions of the program again.