JPH11272501A - Debugger processing method and real-time OS processing method - Google Patents

Abstract

(57) [Summary] [PROBLEMS] In a multitasking system, a task break function is ensured without increasing task switching time. A monitor program obtains an execution task ID by a system call to a real-time OS when a debug target task breaks, compares it with a debug target task ID specified by a user, and resumes execution if not equal. If they are equal, a system call for stopping the task dedicated to the debugger is issued to the real-time OS 102 to stop the task. This eliminates the need for the real-time OS 102 to store the execution task ID in the specific area, thereby reducing the task switching time and avoiding the problem that a task that has been stopped once is woken up again by a subsequent user task. .

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a processing method of a debugger for supporting efficient debugging of application software running on a computer, and a parallel operation of the application software running on the computer as a task as an execution unit. Real-time OS (Real Time Operating System) controlled as (multitask)
In the processing method.

[0002]

2. Description of the Related Art A debugger for computer application software has at least functions necessary for system debugging, such as loading a program to be debugged, reading and writing a memory and a CPU register, executing a program, and stopping. On the other hand, a task-level debugger as a conventional debugger (hereinafter referred to as a task-level debugger, and for the sake of distinction, a debugger for system debugging is referred to as a system debugger) is at least executed in task units. This is a device having functions necessary for task debugging such as stop and stop.

The functions of the system debug device and the task level debug device for executing and stopping a program have the following differences. In other words, the task-level debugger switches between a run (RUN) state and a ready (RE)
The debugged task is controlled by making a transition to an (ADY) state or a suspend (SUSPEND) state.

[0004] A suspended task is in a suspended state, but is in an interruptible state at a system level, and a task with a higher priority can be executed. Therefore, the entire system does not stop. On the other hand, when the program is stopped in the system debug device, the monitor program loops in the interrupt disabled state, leaving control to the debugger, and the entire system stops.

[0005] The configuration of a conventional real-time OS and its control method are described in, for example, the µITRON 3.0 standard handbook (published by personal media). In a conventional method of processing a monitor program of a task-level debugging device, for example, as described in Japanese Patent Application Laid-Open No. 3-113648, an area of an execution task ID (Identification) before the occurrence of a break is set as a break processing. The execution task ID is obtained by reading, and the execution task ID is compared with the debug target task ID specified and stored by the user. If the execution task ID and the debug target task ID do not match, the execution task ID is obtained again from the address at which the break occurred. A processing method has been adopted in which task execution is resumed, and if they match, control is transferred to the debugger, and the entire system is stopped, or the running task is shifted to a suspended state and stopped.

FIG. 4 is a flowchart showing the processing contents of the debugged task 403 and the monitor program 401 in the processing method described above. Here, the processing of the monitor program 401 represents processing that operates as an NMI handler when activated by an NMI (Non Maskable Interrupt). In addition, the monitor program 401 may include other known processes such as an initialization routine (not shown) and other interrupt handlers.

First, when the debugged task 403 generates a break, that is, executes a break instruction causing a break such as an illegal instruction (step T1), the NM
The control is transferred to the I handler, and after performing preprocessing such as register saving (step T2), an execution task ID is obtained (step T3). The execution task ID is the real-time O
By S, the task is stored in a specific area every time the task is switched, and the acquisition of the execution task ID is realized by reading out the data of the area.

Next, it is determined whether or not the execution task ID is equal to the task ID to be debugged (step T).
4) If equal, transfer control to the debugger to stop the entire system, or shift the running task to the suspended state and stop it (not shown); if not equal, execute from the address of the interrupted task again Resume. The task running before the interruption is called the task interrupted as described above due to the occurrence of the interruption factor.

[0009]

However, the above-mentioned conventional task level debugger has the following two problems. First, monitor program 4
01, the real-time OS must store the execution task ID in a specific area every time the task is switched, so that the task switching time increases. It is.

A second problem is that when the execution task ID before the occurrence of a break matches the task ID to be debugged by the processing of the monitor program 401, the task is shifted to the suspended state and stopped.
Depending on the processing of the system call issued by the succeeding execution task (for example, when the processing of issuing a system call that wakes up the stopped task is performed again), the stopped state of the task may not be maintained, and the user intends. There is a problem that the debugging operation cannot be continued as expected.

It is therefore an object of the present invention to provide a debugger processing method that can reduce the task switching time in a real-time OS. Another object of the present invention is to provide a real-time OS processing method that can reduce the task switching time. Still another object of the present invention is to allow a task to be reliably stopped regardless of the processing of a system call issued by a subsequent execution task, and to continue debugging as intended by the user. An object of the present invention is to provide a processing method of a real-time OS.

[0012]

According to a first aspect of the present invention, there is provided a debugger processing method for supporting debugging at a task level. As a break processing, an execution task ID before a break occurs is acquired by a system call. And a second step of comparing one execution target task ID designated and stored by the user with a debug target task ID.
Step, debug target task ID and execution task I
If D is not equal, the execution of the task is resumed from the address where the break has occurred again, and if equal, the execution of the task is stopped.

According to this method, in the real-time OS responding to the system call, the process of storing the execution task ID at the time of task switching can be omitted, so that the task switching time of the real-time OS can be reduced and the system load can be reduced. can do. According to a second aspect of the present invention, there is provided the debugger processing method according to the first aspect, wherein the execution of the task is stopped by a system call.

According to this method, it is possible to make the normal task stop and the task stop state by the break processing different from each other, and the task stopped by the break processing is replaced by the system call issued by the subsequent execution task. Regardless of the processing, it is possible to surely bring the apparatus to a stop state.
A real-time OS processing method according to a third aspect is a method for realizing the debugger processing method according to the first aspect, and executes a system call process for notifying an execution task ID of a currently executing task. Features.

According to this method, the process of storing the execution task ID at the time of task switching can be omitted, so that the task switching time can be reduced and the system load can be reduced. The real-time O according to claim 4
The processing method of S is a method for realizing the processing method of the debugger according to claim 1, wherein each of the task states managed by the real-time OS includes a normal run state, a ready state, a wait state, and a suspend state. In addition to,
A debug suspend (DEBUG SUSPEND) state, which is a stop state that transitions according to a debugger instruction, is added, and a system call processing for transitioning the task to the debug suspend state and a system call processing for returning the task from the debug suspend state to the original state are executed. It is characterized by being possible.

According to this method, when the task by the break processing is stopped, the task can be set to the debug suspend state different from the normal suspend state. This makes it possible to reliably stop the system regardless of the processing of the system call issued by the task.

[0017]

Embodiments of the present invention will be described below with reference to the drawings. FIG. 1 is a schematic diagram showing an overall configuration of a debugger system including a debugger device according to an embodiment of the present invention. In FIG. 1, reference numeral 10 denotes a target system, 101 denotes a monitor program, 102 denotes a real-time OS, and 103 denotes one or more tasks in a multitask system. 20 is the target system 1
0, which is a host computer connected to the communication means 202, and a debugger 201 provides a user with a debugging function for the task 103 on the target system 10. Reference numeral 30 denotes a debug target task ID designated and stored by the user, and is stored in a specific area.

FIG. 2 is a schematic diagram showing the flow of task state transition managed by the real-time OS. Arrows indicate the direction of transition between states, and transition is triggered by an interrupt or a system call from a user task. In FIG.
Is ready, 50 is run, 60 is wait,
70 is a suspend state, and 80 is a debug suspend state. The difference from the conventional example is that the system has a debug suspend state 80 to which a transition is made by issuing a system call from the NMI handler for the task level debugger.

The system call for transition to the debug suspend state 80 and the system call for returning from the debug suspend state to the original state are, for example, distinguished from the system call for transitioning to the suspend state in terms of name and entry. Therefore, the user can easily avoid the mixing. Therefore, the task stopped by the break processing can be reliably stopped regardless of the processing of the system call issued by the subsequent execution task.

Hereinafter, the operation of the monitor program 101 and the real-time OS 102 for its control will be described. FIG. 3 is a flowchart showing processing contents of the debugged task 103, the monitor program 101, and the real-time OS 102. Here, the process of the monitor program 101 represents a process that operates as an NMI handler when activated by the NMI. In addition, the monitor program 101 may include other known processes such as an initialization routine and other interrupt handlers (not shown), and the real-time OS 102 similarly includes a task scheduler and queue operation (not shown). Processing is included.

First, when the debugged task 103 generates a break, that is, executes a break instruction which causes a break such as an illegal instruction (step S1), NM
The control is transferred to the I handler, and after preprocessing such as register saving (step S2), a first system call to the real-time OS is issued to acquire an execution task ID (step S3). At this time, the real-time OS1
In 02, the first system call is received, and the execution task ID acquisition system call process is executed. In the execution task ID acquisition system call process, the execution task ID is set in the return parameter (step S3).
1) Then, the process returns to the monitor program 101, thereby executing task ID in the monitor program 101
Is obtained. Note that the execution task ID is simply set in the return parameter when the first system call is received by the real-time OS, and is stored in a specific area every time the task is switched, as in the conventional example. Never.

Next, it is determined whether or not the execution task ID is equal to the task ID to be debugged (step S).
4) If they are equal, then the task is stopped by issuing a second system call that causes the task to transition to the debug suspend state (step S5). At this time, in response to the second system call, the real-time OS 102 executes a task stop (debug suspend) system call process. In this task stop system call processing, the TCB (Task Control blo
ck: task execution table) is removed from the run queue, connected to the debug suspend queue (step S51), and the task is rescheduled (step S52). Thereafter, the process returns to the monitor program 101, thereby stopping the task in the monitor program 101. Is performed.
By this task stop processing, the task is reliably stopped regardless of the processing of the system call issued by the subsequent execution task.

Thereafter, a task is returned from the debug suspend state to the original state by issuing a third system call. On the other hand, if the execution task ID is not equal to the debug target task ID, the execution is resumed from the interrupted task address. As described above, according to this embodiment, when the debug target task breaks in the monitor program 101, the execution task I
D is obtained by a system call to the real-time OS 102 and compared with the debugged task ID specified by the user. If they are not equal, execution is resumed.
Since the task is issued to S102 and the task is stopped, the process of storing the execution task ID in the specific area by the real-time OS 102 becomes unnecessary, and the task switching time can be reduced.
Further, it is possible to avoid a problem that a task that has been once stopped is woken up again by a subsequent user task. Therefore, in the multitasking system, the task break can be reliably functioned without increasing the task switching time. As a result, the user can perform efficient task-level debugging with a small system load, and the effect is large.

[0024]

According to the first aspect of the present invention, in the real-time OS responding to a system call, the process of storing the execution task ID at the time of task switching can be omitted, so that the task switching time of the real-time OS is reduced. And the system load can be reduced.

According to the processing method of the debugger according to the second aspect, it is possible to make the normal task stop and the task stop state by the break processing different from each other. It is possible to reliably stop the system regardless of the processing of the system call issued by the task. The real-time O according to claim 3
According to the processing method of S, the process of storing the execution task ID at the time of task switching can be omitted, so that the task switching time can be reduced and the system load can be reduced.

According to the processing method of the real-time OS, when the task is stopped by the break processing, the task can be set to the debug suspend state different from the normal suspend state. The task to be stopped can be reliably stopped regardless of the processing of the system call issued by the subsequent execution task, and efficient task-level debugging can be performed.

[Brief description of the drawings]

FIG. 1 is a schematic diagram showing an overall configuration of a debugger system including a debugger device according to an embodiment of the present invention.

FIG. 2 is a schematic diagram showing a flow of task state transition according to the embodiment of the present invention.

FIG. 3 is a flowchart showing operations of a debugged task, a monitor program, and a real-time OS according to the embodiment of the present invention.

FIG. 4 is a flowchart showing operations of a debugged task and a monitor program according to a conventional example.

[Explanation of symbols]

 Reference Signs List 10 target system 101 monitor program 102 real-time OS 103 debug target task 20 host computer 201 debugger 202 communication means 30 debug target task ID 40 ready state 50 run state 60 wait state 70 suspend state 80 debug suspend state 401 monitor program 403 debug task

Claims (4)

[Claims] 1. A processing method of a debugger for supporting task-level debugging, comprising: a first step of acquiring, by a system call, an execution task ID before a break occurs, as a process at the time of a break;
A second step of comparing one debugged task ID designated and stored by the user with the execution task ID, and if the debuggee task ID and the execution task ID are not equal, the task is re-started from the address at which the task was broken again. A third step of resuming execution and, if equal, stopping execution of the task. 2. The processing method according to claim 1, wherein the execution of the task is stopped by a system call. 3. A processing method of a real-time OS for realizing the processing method of the debugger according to claim 1, wherein a system call process for notifying an execution task ID of a task currently being executed is executed. A real-time OS processing method. 4. A real-time OS processing method for realizing the debugger processing method according to claim 1, wherein the task states managed by the real-time OS include a normal run state, a ready state, a wait state, and a suspend state. In addition to each of the above states, a debug suspend state, which is a stop state that transitions according to a debugger instruction, is added, and a system call process that transitions the task to the debug suspend state and the task returns from the debug suspend state to the original state And a system call process for causing the real-time OS to execute.