JP3159155B2 - Method and apparatus for debugging program - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

The present invention relates to a method and an apparatus for debugging a program, and more particularly to a method and an apparatus for debugging a task running on a real-time OS.

[0002]

2. Description of the Related Art When developing a program, one large program is usually divided into many small subprograms for development. Most subprograms often call another subprogram to perform processing. When debugging such a program, the debugger often does not debug the entire large program from the beginning, but sequentially debugs the lower-level subprograms sequentially toward the upper-level subprograms. In this case, since there is no defect in the lower subprogram after the completion of debugging, there is no problem if the upper subprogram is treated as a black box when debugging the upper subprogram.

A program debugging operation often uses step execution in which a program is executed one instruction at a time and changes in registers, memories, and the like are examined. In this case, a subprogram that has been debugged is replaced with a subprogram. It is not necessary to confirm the change by step-executing the subroutine, but to confirm the change after executing the subprogram at once. For this reason, most debuggers that perform program debugging work have a function called procedure step execution that executes the subprogram at once if the instruction to be stepped is a subprogram call instruction. I have.

A real-time OS may be used when some parallel processing or processing involving management of the passage of time is required due to the configuration of a program. The real-time OS is an OS that operates while switching a plurality of programs divided into units called tasks according to the situation. The task being executed is switched by issuing a system call to the OS or generating an event due to an interrupt. Such a task is developed by being divided into several subprograms as in a normal program.

When debugging a plurality of tasks operating in parallel on such a real-time OS, if a subprogram (or function) is included in the main program constituting the task, the subprogram called by the CALL instruction is used. RET when the program returns to the main program
(Return) When a program that does not use an instruction is used, it is required that the processing can be completed normally.

As a prior art which has fulfilled such a demand, there is a procedure / step processing method disclosed in Japanese Patent Application Laid-Open No. 9-152980.

FIG. 1 is a functional block diagram of a debugger 10 that implements this procedure / step processing method.
The debugger 10 has a function of executing a program to be debugged and allowing a user to debug the state of CPU resources such as registers and memories and external devices. When considering only the execution of a program to be debugged, the debugger generally analyzes the debug instruction by the analysis unit 12.
And a real-time emulation unit 14 that continues execution until an event break set by the user or the debugger program itself is detected, a step execution unit 16 that executes only one instruction, and executes an instruction for each function. And a procedure / step execution unit 18. The procedure / step execution unit 18 includes an instruction determination unit 20 and a function execution unit 22.

FIG. 2 is a flowchart for explaining the execution of the procedure steps by the debugger 10.

First, a procedure / step execution unit 18
The command determination unit 20 determines whether the command to be executed is a CALL command in the program being step-executed (step S1), and if the command is not the CALL command (No),
Only the instruction is executed by the step execution unit 16 (step S11), and the process ends.

In the case of the CALL instruction (Yes), the return address is saved on the stack (step S2). The address of the stack to be saved is indicated by the stack pointer.

Next, the event set by the user is saved, and all event breaks are invalidated (step S3). This is to prevent the occurrence of an event break during the real-time emulation because the real-time emulation is used for executing the function.

Next, an access event break is set at the address of the stack where the return address was saved in step S2 (step S4). Note that an event break is to interrupt the execution of the program to be debugged.

Next, the function execution unit 22 and the real-time emulation unit 14 start real-time emulation of the function (step S5).

An access event break is detected by accessing the address of the stack where the return address is saved (step S6).

The real-time emulation is continued until the program counter PC matches the return address (step S7).

If the program counter PC matches the return address, the real-time emulation is interrupted (step S8).

Next, the access event break set in step S4 is released (step S9).

Finally, the event of the user saved in step S3 is restored (step S10), and the procedure
The step execution processing ends.

According to the procedure steps described above, the return address is stored in the address of the saved stack.
Since an access event break is set, even when a function not using the RET instruction is executed in a procedure step, the processing can be interrupted.

[0020]

In a multitask system, tasks having individual stack areas as shown in FIG. 3 are executed in parallel via a real-time OS. When all the tasks are completed, the task calls its own task termination system call and notifies the real-time OS of the task termination. When the real-time OS detects the end of the task, the real-time OS releases the stack area of the task that issued the system call. Therefore, in the conventional method in which the processing is interrupted under the condition of “PC = return address”, the procedure / step execution is performed. The operation could not be terminated.

For example, consider a program that operates as shown in FIG.

FIG. 4 shows the time at the left end, the program (task, function, real-time OS) being executed at the center, and the stack state immediately after executing the instruction at the right end at the right end. There are three tasks, task 1, task 2, and task 3. Function 1 is a subprogram included in task 1, and function 2 is a subprogram included in task 2. Each task 1, 2, 3 has a corresponding stack 1, 2,
3 respectively. In these stacks, the addresses indicated by the stack pointers are indicated by diagonal lines (however, when the real-time OS processing is being performed, the stack may have a stack for the OS, or the timing of stack switching may be different, so that the case different from FIG. There is.).

For example, what is being executed at time T1 is the program of task 1, and at this time, the instruction "CAL
When "L SYSCALL" is executed, the return address A to the stack 1 is stored at the address indicated by the stack pointer of the stack 1 for the task 1, and the real-time OS
Execution moves to. (The stacks 2 and 3 for task 2 and task 3 already have return addresses E and G at this point.
Is stored, which means that each task has time T
1 before).

Next, at time T2, the real-time OS
Is completed, the process returns to the address A of the task 1 under the management of the OS itself.

Next, at time T3, the instruction "CALL"
When "FUNC1" is executed, the return address D to the stack 1 is stored in the stack 1, and the execution shifts to the function 1.
During execution of function 1, the instruction "CALL SYSCALL"
When "2" is executed, the return address B to the function 1 is stored in the stack 1, and the execution shifts to the real-time OS.

Next, at time T5, the real-time OS
Is completed, the process returns to the address B of the function 1 under the management of the OS itself.

Next, when the instruction "CALL FUNC3" is executed at the time T6 during the execution of the function 1, the return address C to the function 1 is stored in the stack 1 and the execution shifts to the real-time OS.

Next, at time T7, the real-time OS
Is completed, the process returns to the address C of the function 1 under the management of the OS itself.

In execution of the function 1, when the RET instruction is executed, the processing returns to the address D of the task 1.

As seen from the time T9 to T13, if the execution is transferred to the task 2 by the management of the real-time OS after calling the SYSCALL4 in the task 1,
In task 2, stack 2 is used, and stack 1 does not change. In addition, the stack pointer is changed to indicate the stack 2 as the stack switches.

At time T13, execution shifts to task 1 under the control of the OS itself, and it is assumed that the command "CALL SYSCALL6", which is a task end system call, is executed at time T14. By “CALL SYSCALL6”, the return address X to the task 1 is set in the stack 1
(Although it never returns). Also, FIG. 4 shows that the stack 1 exists after the time T14, but normally, in order to release unnecessary resources, when the real-time OS detects the end of the task,
The area of the stack 1 is released and treated as a free area.

In the above processing, as described above,
The operation of returning to the task from the real-time OS is managed by the OS itself. Further, in the real-time OS, since the return address of the function can be managed for each task, the function can be independently called for each task.

In the program as described above, when debugging a task: When a system call is called, the process returns to the invoking task as it is (processing at time T1 to T2). When a system call is called internally and the function ends after returning to the invoking task (processing at time T3 to T8). When calling a system call, returning to the invoking task after executing another task ( (Processing from time T9 to T13) For example, since the stack of task 1 is independent of other tasks, execution can be interrupted at the place where the task returns to its own task under the condition of PC = return address.

On the other hand, when the task is terminated when the task termination system call is invoked (processing at time T14)
Is because the real-time OS releases the stack 1 of the task 1 and makes the stack 1 an empty area.
Does not match the return address, so execution is not interrupted.

As described above, a program using the real-time OS calls a specific system call from a task in order to switch a task, and some system calls are for terminating the task itself. When the system call for terminating the invoking task is called, the debugging process is not interrupted.

An object of the present invention is to provide a debugging method and apparatus capable of terminating a debugging execution operation even when a system call for terminating its own task is called in a multitask system using a real-time OS. It is in.

Another object of the present invention is to provide a recording medium on which a program for executing a debugging method is recorded.

[0038]

According to the present invention, a procedure / step execution of a system call that terminates its task (the caller of the system call) is provided.
By allowing the debugger to retain the internal information of the real-time OS, determining the type of system call called from the program to be debugged, and in the case of the invoking task end system call, setting an event break inside the real-time OS and executing it When the processing of the real-time OS ends, the program execution is interrupted.

A method of debugging a plurality of tasks executed in parallel on a real-time OS according to the present invention includes a step of retaining internal information of the real-time OS, a step of determining whether or not the information is a CALL instruction; If the CALL instruction is a self-task termination system call, it is determined whether or not the CALL instruction is a self-task termination system call by referring to the internal information. Setting an event break inside the OS and executing a procedure step; and detecting the event break,
Terminating the execution of the procedure step.

An apparatus for debugging a plurality of tasks executed in parallel on the real-time OS includes a means for holding internal information of the real-time OS, a means for determining whether or not the instruction is a CALL instruction; , That CAL
Means for determining whether or not the L instruction is a self-task termination system call by referring to the internal information; and, if the L instruction is a self-task termination system call, an event break in the real-time OS by referring to the internal information. And set
It has means for executing a procedure step, and means for terminating the execution of the procedure step after detecting the event break.

Further, according to the present invention, there is provided a recording medium recording a program for debugging a plurality of tasks executed in parallel on a real-time OS, wherein the program is a step of holding internal information of the real-time OS, and a CALL instruction. Determining whether or not the CALL instruction is a self-task termination system call by referring to the internal information; and If so, setting an event break inside the real-time OS with reference to the internal information and executing a procedure step; and after detecting the event break,
Terminating the execution of the procedure step.

[0042]

FIG. 5 is a functional block diagram of a debugging device (or debugger) of the present invention. This debugger 40 differs from the conventional debugger shown in FIG. 1 in the function of the procedure / step execution unit 24, and further has an OS information table 34.

The procedure / step execution unit 24 includes an instruction determination unit 26 for determining whether the instruction is a CALL instruction, a function determination unit 28 for determining whether the CALL instruction is a self-task termination system call, An execution unit 30 executes an end function, and an execution unit 32 executes a normal function other than the task end function.

Before describing a debugging method using this debugger, a method for calling a system call will be described.

As a method of calling a system call, there are a method of directly calling a system call from a task and an indirect calling method of passing a system call ID to a real-time OS and branching from an OS entry which is a common entrance in the OS. .

FIG. 6 is a flowchart of the internal processing of the real-time OS showing the system call direct calling method. FIG. 7 is an internal processing flowchart of the real-time OS showing the system call indirect calling method. These figures also show the OS code area.

In the system call direct calling method, the address of a system call is described as an operand of a CALL instruction on a task, such as CALL SYSCALL1.

On the other hand, in the indirect calling method, a system call ID is registered using a register or the like as in MOV RG1, SYSCALL_ID1 CALL OS_ENTRY.
Pass as an argument to the S entry. The OS entry branches to a corresponding system call based on the system call ID.

In the direct call method, the type of the system call can be determined by analyzing the operand of the CALL instruction, and in the indirect call method, by analyzing the argument to the OS entry.

The end address of the system call (OS) is determined based on the result of the determination, and the determined OS
By setting an event break at the end address and performing real-time emulation, execution can be interrupted at the point where the system call (OS) processing has been completed. Therefore, the OS information held in the table 34 of the debugger includes: rules for specifying a system call; direct call or indirect call; types of registers and memory used as arguments; System call address or system call ID OS entry address System call (OS) end position information is required.

FIG. 8 is a flowchart showing the operation of the debugger 40 of FIG. The execution process of the procedure / step will be described with reference to this flowchart.

First, the procedure / step execution unit 24
The command determining unit 26 determines whether the command to be executed is a CALL command in the program being step-executed (step S1), and if the command is not the CALL command (No),
Only the instruction is executed by the step execution unit 16 (step S2), and the process ends.

In the case of the CALL instruction (Yes), the function discriminating unit 28 reads out “rules for specifying system calls” and “information of the own task termination system call” from the OS information table 34, and It is determined whether or not (Step S3).

FIGS. 9 and 10 are flowcharts showing the processing of the function determining section 28. FIG. 9 shows the processing when the system call is directly called, that is, the processing when the system call is directly called, and FIG. 10 shows the processing when the system call is called via the OS entry, that is, the case when the system call is called indirectly. Is shown.

In the direct call shown in FIG. 9, the function discriminating unit 28 extracts the own task end system call information (symbol / address) from the OS information table 34, calculates the start address of the own task end system call, and holds it. I do. On the other hand, after acquiring the operand (call destination address) of the CALL instruction, the function determining unit refers to the held start address to obtain the start address of the invoking task termination system call. If the call destination address matches the start address, the process proceeds to the process of the task termination function execution unit 30. If not, the process proceeds to the process of the normal function execution unit 32.

In FIG. 10, the function discriminating unit 28 is provided by the OS
The OS entry address is extracted from the information table 34, and the own task termination system call ID (number / address) is extracted and held. On the other hand, the function determining unit
After the operand (call destination address) of the ALL instruction is obtained, the OS entry address is obtained by referring to the stored OS entry address.

If the call destination address matches this OS entry address, an argument is obtained. By referring to the held own task end system call ID, it is determined whether the argument matches the own task end system call ID. If they match, the process proceeds to the task termination function execution unit 30, and if they do not match, the process proceeds to the normal function execution unit 32.
Further, even when the OS entry address does not match the callee address, the process proceeds to the normal function execution unit 32.

Referring back to FIG. 8, when the function discriminating section 28 determines that the call is not the invoking task end system call, the normal function executing section 32 executes a normal procedure step (step S4). This normal procedure step is the same as the procedure step described in FIG.

If it is the self-task termination system call, the task termination function execution unit 30 saves the event set by the user and releases or invalidates all event breaks (step S5).

FIG. 11 is a flowchart that is almost the same as the processing flow of the task function execution unit shown in FIG. 8, but additionally includes processing for determining the OS end address.

In FIG. 11, the task termination function execution unit 3
0 indicates a system call (O
Extract the end position information (symbol / address) of S),
Calculate and hold the OS end address. On the other hand, the task termination function execution unit determines the stored OS termination address.

Returning to FIG. 8, after the execution, an event break is set to the determined OS end address (step S).
6).

Next, the task termination function execution unit 30 and the real-time emulation unit 14 start real-time emulation of the task termination function (step S7).

When an event break is detected after execution by accessing the OS end address (step S
8), the real-time emulation is interrupted (step S9).

Next, the post-execution event break set in step S6 is released (step S10).

Finally, the event of the user saved in step S5 is restored (step S11), and the execution of the task end function ends.

According to the debugger described above, even if the own task termination system call is called, the real-time O
The program execution can be interrupted when the processing of S is completed.

Such a debugger can be constituted by a program.

[0069]

According to the present invention, the procedure step execution of the system call that terminates the invoking task is executed by causing the debugger to hold the internal information of the real-time OS and executing the system call called from the program to be debugged. In the case of the self-task termination system call, an event break is set in the real-time OS and executed, so that the program execution is interrupted when the processing of the real-time OS ends. In the task system, even when a system call for terminating the invoking task is called, the debug execution operation can be terminated.

[Brief description of the drawings]

FIG. 1 is a functional block diagram of a debugger that executes a conventional procedure / step processing method.

FIG. 2 is a flowchart illustrating execution of a procedure step by the debugger of FIG. 1;

FIG. 3 is a diagram showing a program to be debugged.

FIG. 4 is a diagram for describing a program that performs a specific operation.

FIG. 5 is a functional block diagram of the debugging device of the present invention.

FIG. 6 is a flowchart of internal processing of a real-time OS showing a system call direct calling method.

FIG. 7 is an internal processing flowchart of a real-time OS showing a system call indirect call method;

8 is a flowchart showing the operation of the debugger of FIG.

FIG. 9 is a flowchart illustrating a function determination process.

FIG. 10 is a flowchart illustrating a function determination process.

FIG. 11 is a flowchart illustrating processing of a task function execution unit.

[Explanation of symbols]

 12 Debug instruction analysis unit 14 Real-time emulation unit 16 Step execution unit 24 Procedure step execution unit 26 Instruction determination unit 28 Function determination unit 30 Task termination function execution unit 32 Normal function execution unit 34 OS information table 40 Debugger

──────────────────────────────────────────────────続 き Continued on the front page (58) Field surveyed (Int.Cl. ⁷ , DB name) G06F 11/28-11/36 G06F 9/46

Claims (15)

(57) [Claims] 1. A method for debugging a plurality of tasks executed in parallel on a real-time OS, wherein: a step of retaining internal information of the real-time OS; a step of determining whether or not the real-time OS is a CALL instruction; If so, a step of determining whether or not the CALL instruction is an invoking task termination system call by referring to the internal information; Setting an event break therein and executing a procedure step; and detecting the event break,
Debugging method, wherein the step of executing comprises the step of exit, the. 2. The debugging method according to claim 1, wherein the internal information includes a rule for specifying a system call, information on a self-task termination system call, and information on a termination position of the system call. . 3. The step of judging whether or not the CALL instruction is an invoking task termination system call, wherein the system call is specified when the system call is directly invoked from a task. Is determined to be a direct call method, and based on the information of the invoking task termination system call, the head address of the invoking task termination system call is calculated. If the addresses match, CAL
3. The debugging method according to claim 2, wherein the L instruction is determined to be a self-task termination system call. 4. The method according to claim 1, wherein the step of determining whether the CALL instruction is an invoking task termination system call is performed in the case of an indirect call system in which a system call ID is passed to a real-time OS to branch from an OS entry. Is determined based on the rule for specifying the indirect call method, and the OS entry address is obtained based on the information of the invoking task termination system call.
If the address matches the address described as the operand of the L instruction, an argument is obtained, and if the argument matches the own task system call ID, the CALL instruction is determined to be the own task end system call. Item 2. The debugging method according to Item 2. 5. The debugging method according to claim 3, wherein the event break is set at a system call end address calculated from the system call end position information. 6. An apparatus for debugging a plurality of tasks executed in parallel on a real-time OS, means for holding internal information of the real-time OS, means for determining whether or not the command is a CALL instruction, If so, means for determining whether or not the CALL instruction is an invoking task termination system call by referring to the internal information; Means for setting an event break therein and executing a procedure step;
Means for ending the execution of the step, and a debugging device comprising: 7. The debugging device according to claim 6, wherein the internal information includes a rule for specifying a system call, information on a self-task termination system call, and information on a termination position of the system call. . 8. The means for judging whether or not the CALL instruction is an invoking task termination system call, specifies the system call when the system call is a system for directly calling a system call from a task. Is determined to be a direct call method, and based on the information of the invoking task termination system call, the head address of the invoking task termination system call is calculated. If the addresses match, CAL
8. The debugging device according to claim 7, wherein the L instruction is determined to be a self-task termination system call. 9. The method according to claim 1, wherein said means for determining whether or not the CALL instruction is an invoking task termination system call comprises: Is determined based on the rule for specifying the indirect call method, and the OS entry address is obtained based on the information of the invoking task termination system call.
If the address matches the address described as the operand of the L instruction, an argument is obtained, and if the argument matches the own task system call ID, the CALL instruction is determined to be the own task end system call. Item 7. The debugging device according to Item 7. 10. The debugging device according to claim 8, wherein the event break is set at an end address of the system call calculated from the end position information of the system call. 11. A recording medium on which a program for debugging a plurality of tasks executed in parallel on a real-time OS is recorded, the program comprising: a step of retaining internal information of the real-time OS; Determining whether or not the CALL instruction is a self-task termination system call by referring to the internal information; and if the CALL instruction is a self-task termination system call, Setting an event break inside the real-time OS with reference to the internal information and executing a procedure step;
Ending the execution of the step; and a recording medium. 12. The recording medium according to claim 11, wherein said internal information includes a rule for specifying a system call, information on a self-task termination system call, and information on a termination position of a system call. . 13. The step of judging whether or not the CALL instruction is a self-task termination system call, wherein the system call is specified when the system call is a system for directly calling a system call from a task. Is determined to be a direct call method, and based on the information of the invoking task termination system call, the head address of the invoking task termination system call is calculated. If the addresses match, CAL
13. The recording medium according to claim 12, wherein the L instruction is determined to be a self-task termination system call. 14. The method according to claim 1, wherein the step of determining whether or not the CALL instruction is an invoking task termination system call includes: Is determined based on the rule for specifying the indirect call method, and the OS entry address is obtained based on the information of the invoking task termination system call.
If the address matches the address described as the operand of the L instruction, an argument is obtained, and if the argument matches the own task system call ID, the CALL instruction is determined to be the own task end system call. Item 13. The recording medium according to Item 12. 15. The recording medium according to claim 13, wherein said event break is set at an end address of a system call calculated from end position information of said system call.