JPH1145193A - Method and device for supporting software development, and recording medium - Google Patents

Abstract

PROBLEM TO BE SOLVED: To reduce the burden of debugging operation by indicating the interruption of the execution of software when detecting the task forbidden operation of the software based on the state of a task shifted according to an event and a generated pattern. SOLUTION: The software development support device 3 is unable to execute tasks B and C at the same time. A task C, on the other hand, a two break patterns set so that a semaphore P is not accessed. Then the support device 3 interrupts the execution of user application 1 by controlling multitask OS 2 when restriction conditions that the user sets in the device 3 in advance are not met during single execution of the user application, namely, when a break state (operation inhibition of the user application) is detected. Consequently, an execution interruption (break) point of software executed on the system can easily be set and a malfunction point can easily be detected.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] 1. Field of the Invention [0002] The present invention relates to a software development support apparatus used for debugging a user application executed under an OS.

[0002]

2. Description of the Related Art In a debugging operation of a user application executed under an OS (operating system), it is necessary to perform a debugging operation in consideration of an occurrence pattern of a plurality of events managed by the OS. Further, in the case of a multitask OS, it is necessary to perform a debugging operation in consideration of each task state transition. The debugging work here is not about correcting an error at the time of compiling a program, but about a work of correcting a defect when a compile error does not occur but the operation at the time of execution is abnormal. Usually, the user sets a breakpoint,
The operation of interrupting the execution of the user application, referring to the internal state of the OS at that time, and modifying the program is repeated.

That is, conventionally, in a debug operation of a user application executed under the OS, a user sets a breakpoint in advance at an execution instruction determined to be effective for solving a defect, and the debugger executes the execution instruction. After setting a break instruction at the execution address where the instruction is stored, the user application is executed. Then, when the execution of the user application is interrupted by the break instruction, the internal state of the OS such as the memory and the used variables at that time is referred to verify the specific cause of the malfunction of the user application. In other words, the user himself / herself analyzes what kind of event occurred in what order and what caused the failure.

[0004]

However, in the conventional debugger described above, the user presumes a specific execution instruction which is considered to be a cause of a malfunction, sets a breakpoint, and interrupts the execution of the user application. There is a disadvantage that the user sometimes has to verify the specific cause of the malfunction. In other words, since a trial and error operation of estimating and verifying the cause of the malfunction by the user himself is required, the debugging work is not performed smoothly,
There is a possibility that the productivity of the entire user application may be reduced.

In view of the above, the present invention has been made in view of the above-described problems, and has been made in view of the setting of a break point of execution of a user application, detection of a malfunction point, and the like.
It is still another object of the present invention to provide a software development support method and a software development support device using the method, which can easily refer to the internal state of the OS at the time of detecting a malfunction and reduce the burden of debugging work.

[0006]

A software development supporting method according to the present invention generates a pattern of a task inhibition operation based on a state transition of a software task executed in a system, and executes the execution of the software. Interrupting the execution of the software when detecting a task prohibition operation of the software task based on the state of the task transited according to the event generated based on the software execution and the generated pattern. By giving the instruction, it is possible to easily set the execution interruption (break) point of the software executed on the system and detect the malfunctioning point, and reduce the load of the debugging work.

Further, the software development support apparatus of the present invention has an input means for inputting a condition of a prohibited operation of the task based on a state transition of a software task executed in the system, and an input means for inputting the condition. Generating means for generating a pattern of a prohibited operation of the task based on a state transition of the task of the software based on a condition; and Detecting means for detecting a prohibited operation of the task of the software based on a state and the generated pattern; and instructing interruption of the execution of the software when the detecting means detects the prohibited operation. Means for setting a break point for execution of software executed on the system. And easy to malfunction point of detection, the burden of debugging work can be reduced.

[0008]

Embodiments of the present invention will be described below with reference to the drawings. FIG. 1 shows an example of the configuration of a software development support apparatus according to the present embodiment, and the entirety of debugging a user application executed on an OS (multitask OS) using the software development support apparatus. 1 schematically shows the configuration. Less than,
Each of the multitask OS 2, the user application 1, and the software development support device 3 in FIG. 1 will be described. (A) Multitask OS As shown in FIG. 1, the main components related to the operation of the software development support device 3 of the multitask OS 2 are a task execution scheduling unit 4, an OS internal event generation unit 5, a task execution control. The processing unit 6 includes three processing units and an OS internal state storage unit 7 as internal storage. FIG.
The configuration of the multitask OS is simplified by removing portions other than those necessary for describing the present embodiment.

(A-1) Task Execution Scheduling Unit The task execution scheduling unit 4 receives an event such as a system call from the user application 1 or an interrupt from an external device or the like, and performs task execution scheduling in consideration of task execution priority. I do. As a result of the scheduling, the task to be executed next is transmitted to the task execution control unit 6. Changes in the OS internal state, such as task state transitions and semaphore state changes, that occur during the scheduling process are sequentially stored in the OS internal state storage unit 7.
FIG. 2 shows a storage example of the OS internal state. The OS internal state is
The multitask OS 2 is information used for providing services such as system calls and task execution scheduling, and information on all objects defined by the user application 1 is stored for each object. FIG. 2 shows an example in which the states of four objects, task A, task B, task C, and semaphore P, are stored. Details of these pieces of information will be described later.

The task execution scheduling section 4
In the OS internal event generation unit 5, all events that affect task execution scheduling, such as system call issuance events, task state transition events, semaphore state change events, and interrupts from external devices, are regarded as OS internal events. Issue. The system call issuance event is an event that occurs when a user application 1 issues a system call. A task state transition event is an event that occurs when the state of a task changes as a result of task execution scheduling. The semaphore state change event is an event that occurs when the state of the semaphore is changed.

(A-2) Task Execution Control Unit The task execution control unit 6 is a multi-task OS such as the task execution scheduling unit 4 and the software development support device 3.
(2) In response to a request from the outside, execution control such as execution start, execution interruption, and execution stop is performed on the designated task.

(A-3) OS Internal Event Generating Unit The OS internal event generating unit 5 sends the OS internal event issued from the task execution scheduling unit 4 from an application outside the multitask OS 2 such as the software development support device 3. Provides an interface for reading.

The objects provided by the multitask OS 2 to the user application 1 include tasks, interrupt handlers, semaphores, and mailboxes.
Of these, two types of objects, a task and a semaphore, used in the present embodiment will be described in detail with respect to the mechanism and OS internal state.

A task is a unit of execution of a program.
The multitask OS 2 executes the user application 1 while switching tasks according to task execution scheduling.

The semaphore provides an exclusive control function for a task to acquire an access right to a shared resource such that access from a plurality of tasks is restricted at the same time. The OS internal state is updated as needed by the multitask OS 2 during execution of the user application 1, and holds the state of all objects defined by the user application, such as the task control block and the semaphore control table.

As shown in FIG. 3, the task control block has attributes such as a task ID, a task status, and a task priority. The task ID is an identifier for identifying a task. The task state indicates the current state of the task. The task states include types such as an execution state (RUN), an executable state (READY), and a waiting state (WAIT). The task priority indicates the task execution priority. For example, in a task execution scheduling function provided by the multitask OS 2, when two or more tasks are simultaneously executable, the multitask OS 2
Refers to the task priorities of tasks that can be executed at the same time, and sets the task with the highest priority to the execution state.

As shown in FIG. 4, the semaphore control table has attributes such as a semaphore ID and a semaphore counter value. The semaphore ID is an identifier for identifying the semaphore. The semaphore counter value indicates the current value of the semaphore counter. In the present embodiment, the semaphore mechanism is simplified, and the semaphore counter value takes only two values, “0” and “1”. In this case, when the semaphore counter value is “1”, any task can access the shared resource by acquiring the semaphore, and when any task acquires the semaphore, the semaphore counter value becomes “0”. Becomes When the semaphore counter value is "0", no task can acquire the semaphore,
Until the task that is currently acquiring the semaphore releases the semaphore, the task that requested the semaphore waits for the semaphore. Then, when the task acquiring the semaphore releases the semaphore, the task waiting for the semaphore acquires the semaphore and can access the shared resource. (B) User Application The user application 1 is a multitask application created by the user. FIG. 5 conceptually shows the configuration of a user application to be debugged in the present embodiment. FIG. 6 is a timing chart showing a state change of each object for each unit time during execution of the user application of FIG. 5, and an OS internal event that has occurred.

As shown in FIG. 5, the user application 1 has four tasks A, B, C, and D.
One task and the semaphore P are composed of five objects. The shared resource cannot be accessed from two tasks at the same time, and the semaphore P is used for exclusive control for this purpose.

Here, a task is a unit of program or module for realizing a certain function. The initial values of the task ID, task priority, and task state of each task are as shown in FIG. The task priority is an integer value equal to or greater than "1", and "1" indicates the highest execution priority. For example, the task ID of task A is “# 1”, the task priority is “1”, which is the highest execution priority, and the task state indicates that it is in the RUN state. Other tasks are similarly shown.

The initial values of the semaphore ID of the semaphore P and the semaphore counter value are as shown in FIG. The semaphore ID is “# 99”, and the initial value of the semaphore counter value is “0”.

In the timing chart shown in FIG. 6, the vertical axis represents the object defined by the user application,
The horizontal axis indicates the time from 000 ms to 900 ms in 100 ms increments, and indicates the task status of each task, the type of system call issued from each task, and the semaphore status at each time in units of 100 ms. As for the task status, the solid line is the RUN status, the wavy line is the WAIT status, and the broken line is the R status.
Each is shown in the EADY state. Issuance of the system call is indicated by an arrow to the issue time of the issue source task together with the type of the issue system call. For example,
The task state of each task at the time of 000 msec is as follows: task A is in the RUN state, task B is in the WAIT state, task C
Is in the WAIT state, the task D is in the READY state, and the semaphore counter value of the semaphore P is “0”.
By issuing sem (# 99), it can be read that the state of task B has transitioned from the WAIT state to the READY state. In this manner, the four tasks of task A, task B, task C, and task D use the system call provided by the multitask OS 2 to switch the execution task and access a shared resource using a semaphore. .

Next, the behavior of the user application 1 based on the timing chart of FIG. 6 will be described. Time 000 ms: Initial state, task A is in the RUN state while semaphore P is being acquired, task B is in the WAIT state waiting for semaphore P acquisition, task C is in the WAIT state, and task D is in the READY state. Since the semaphore counter value of semaphore P is that task A is acquiring semaphore P,
It is "0".

Time 100 ms: Task A issues a system call sig_sem (# 99), semaphore P is released, and task B waiting for semaphore P is REA
The state becomes the DY state. However, since task A has a higher execution priority, task switching does not occur.

Time 200 ms: Task A executes system call wup Tsk (# 3) is issued to wake up task C, and task C enters the READY state. Time 300 ms: Task A executes system call slp t
sk () is issued, task A enters the WAIT state, and among tasks other than task A that are in the READY state, the task having the highest execution priority, that is, task B enters the RUN state.

Time 400 ms: Task B receives system call sig sem (# 99) is issued, the semaphore P is released, and the semaphore counter value of the semaphore P becomes “1”. Time 500 ms: Task B makes system call slp t
sk () is issued, task B enters the WAIT state, and among tasks other than task B that are in the READY state, the task having the highest execution priority, that is, task C enters the RUN state.

Time 600 ms: Task C receives system call wai sem (# 99) is issued, and an attempt is made to acquire the semaphore P. However, since the semaphore counter value of the semaphore P is “1”, the task C does not wait for the semaphore, and the task C acquires the semaphore P. . As a result, the semaphore counter value of the semaphore P becomes “0”.

Time 700 ms: Task C executes system call slp Issuing tsk (), task C enters the WAIT state, and among tasks other than task A that are in the READY state, the task with the highest execution priority, that is, task D, enters the RUN state.

Time 800 ms: Task D makes system call wup By issuing tsk (# 1), task A becomes executable. However, since task A has a higher execution priority than task D, task D is in the READY state and task A is in the RUN state.

Time 900 ms: End of execution of the user application. As a result, the state of each object is as follows: task A is in the RUN state, task B is in the WAIT state,
Task C is acquiring semaphore P and is in the WAIT state, and task D is in the READY state. The semaphore counter value of the semaphore P is “0”, and the task C is acquiring the semaphore P.

Next, an operation procedure for specifically debugging the above-described user application 1 using the software development support device 3 having the configuration shown in FIG. 1 will be described. In this embodiment, the following two break patterns are set in the software development support device 3.

First break pattern (first constraint condition): Task B and task C cannot be executed simultaneously. Second break pattern (second constraint): Task C does not access semaphore P.

The software development support device 3 behaves so as to interrupt the execution of the user application 1 when any one of these break patterns is not satisfied during the execution of the user application 1. (C) Software Development Support Device As shown in FIG. 1, the software development support device 3 includes a break pattern input unit 8, a break pattern generation unit 1
2, OS control unit 17, break information output unit 20, OS internal state read unit 13, event read unit 14, trace information output unit 18, seven processing units, break pattern library storage unit 10, break pattern information storage unit 11 , An application information storage unit 9, and an event history information storage unit 19, and an OS state table storage unit 19 as an internal storage.

The software development support device 3 is configured such that the constraint conditions (conditions of the prohibited operation of the user application) set in advance by the user in the software development support device 3 are as follows.
When the condition is not satisfied during execution of the user application 1, that is, when a break state is detected (when a prohibited operation of the user application is detected), the multitask OS 2 is controlled to temporarily suspend the execution of the user application 1. Is configured.

Next, the processing operation of each unit of the software development support apparatus 3 will be described with reference to the overall processing flow shown in FIG. (C-1) Break Pattern Input Unit The break pattern input unit 8 refers to the application information stored in the storage unit 9 and provides the user with the storage unit 1
0 of the break pattern library stored in the storage unit 11 and the break pattern information stored in the storage unit 11.
Provides editing functions such as addition, modification, and deletion, and a user interface therefor.

The break pattern library stored in the storage unit 10 is a state transition in which an OS internal event such as a system call issuance, a task state transition, a semaphore state change, and the like, and an OS internal state at the occurrence time are input events. It is a set of break pattern templates represented in the figure. For example, a template of a break pattern is defined in the format of FIG. 8 or FIG.

For example, a template of a break pattern when the constraint condition is “two specific tasks cannot be executed simultaneously” can be represented as shown in FIG. FIG.
In FIG. 7, "not executable at the same time (task, task)" is the notation method of the constraint condition, and the corresponding break pattern definition is the state transition diagram shown below. In the state transition diagram, S ₀ is the initial state, the S _E end state, the other S _n is the state in the middle course of the transition to S _E from S _0. The notation “task state transition: (% 1) → executable”, which is one of the notations shown as the event in FIG. 8, indicates that a task state transition event has occurred, and the content of the event is that the task% 1 of the first argument is Indicates that the event has been made executable.

Similarly, a template of a break pattern when the constraint condition is “a specific task does not access a specific semaphore” can be represented as shown in FIG. FIG.
In the event notation "issue system call: sig
"sem (% 1,% 2)" indicates that a system call issuance event has occurred and its content is sig sem (% 1,%
2) represents an event. Here,% 1 represents a task ID, and% 2 represents a semaphore ID.

As shown in FIG. 10, the break pattern information stored in the storage unit 11 includes object IDs such as specific task IDs and semaphore IDs in the arguments of the constraint conditions shown in FIGS. It is for setting.

For example, the notation “not simultaneously executable (# 2, # 3)” in FIG. 10 represents the first constraint condition that task B and task C cannot be simultaneously executed. The notation "do not access (# 3, # 99)" represents the second constraint condition that task C does not access semaphore P.

The user interface of the break pattern input unit 8 has a break pattern library including the state transition diagrams of FIGS. 8 and 9 and an editing function such as creation, addition, modification, and deletion of the break pattern information of FIG. doing.

The break pattern input unit 8 uses the application information stored in the storage unit 9 to check for an entry error in the break pattern set by the user.

The application information is information that depends on the entire user application 1 to be debugged, and includes information that depends on the multitask OS 2 and information that depends on the user application 1. Multitask O
The information dependent on S2 is information such as the type of the system call provided by the multitask OS2, the type of the object, the attribute of the task control block, the attribute of the semaphore control block, and the like, as shown in FIG. The information depending on the user application 1 includes, as shown in FIGS. 12 and 13, the object I of all objects (tasks, semaphores) defined by the user in the user application.
D and object name information.

Although not described in the present embodiment, the application information includes debug information generated at the time of compiling the user application 1 and a multitask O having an interface capable of providing such information.
It may be collected and created from S2.

(C-2) Break Pattern Generation Unit The break pattern generation unit 12 includes the storage unit 10 and the storage unit 1.
The break state detection unit 1 uses the break pattern library and the break pattern information stored in the
5 to generate a break pattern to pass. As a specific image, the break state detecting unit 15 can refer directly to the break state detection unit 15 for debugging by using the break pattern information of FIG. 10 from the general break pattern templates shown in FIGS. The purpose is to obtain a specific break pattern as shown in FIG.

Before actually executing the user application 1, first, as described above, the user inputs the template of the break pattern and the break pattern information based on the desired constraint conditions through the break pattern input section 8 ( (Including editing such as creation / addition / modification / deletion) (step S1). Then, in the break pattern generation unit 12, from the input general break pattern model,
Using the break pattern information, the break state detection unit 1
Then, a break pattern that allows the user 5 to directly refer to it for debugging is generated (step S2).

When the user puts the user application 1 in the execution state from the software development support device 3, the user first sets a break immediately after the execution of the user application 1 or at a debugging start point set in advance by the user. After setting a breakpoint according to the related art, the user application 1 is set to the execution state. As a result, the user application 1 suspends the execution immediately after the start of the execution or at a debugging start point set in advance.

(C-3) OS Internal State Reading Unit The OS internal state reading unit 13
Is detected (before the user application is executed), the OS internal state is read from the multitask OS 2 and written as the initial value of the OS state table 16 which is an internal storage in the software development support device 3. (Step S11). The OS state table 16 has the same structure as the OS internal state of FIG. When the writing to the OS state table 16 is completed, the execution of the user application 1 is restarted via the OS control unit 17 (step S12).

In the user application 1 shown in FIG. 5, the initial states of the objects, that is, the initial states of the tasks A, B, C, D and semaphore P are read.

When the writing of the OS internal state to the OS state table 16 inside the software development support device 3 is completed, the OS internal state reading unit 13 starts executing the user application 1 via the OS control unit 17. .

(C-4) OS Control Unit The OS control unit 17 responds to requests from the OS internal state reading unit 13 and the break state detecting unit 15 by using the multitask OS 2
Of all or some of the tasks of the user application 1 via the task execution control unit 6
Performs execution control such as suspension.

(C-5) Event Reading Unit When the execution of the user application 1 is resumed by the OS control unit 17, the event reading unit 14 sends an OS internal event from the OS internal event generation unit 5 in the multitask OS 2. Is started, the acquired OS internal event is transferred to the break state detection unit 15, and is stored in the storage unit 19 as event history information (step S1).
3).

FIG. 16 shows an example of event history information generated from an OS internal event generated when the user application 1 of FIG. 5 is executed. FIG.
6, the history of one OS internal event includes time,
It consists of three fields: event type and event argument. The time field indicates the time at which the event occurred, and is a field added by the event reading unit 14. The event type field is represented by an event ID, and the meaning of each event ID and the content of the event argument of the event can be interpreted by referring to a table as shown in FIG. For example,
The OS internal event whose event ID is “1” means a system call issuance event, and has event source task ID, system call name, and system call arguments as event arguments. In FIG. 17, internal OS events not related to the execution of the user application according to the present embodiment are omitted. The event argument field in FIG. 16 is described with contents corresponding to the event argument shown in FIG. For example, in FIG. 16, the event content of the system call issuance event at time “100” is that the issuer task ID is “# 1” and the system call name is sig. sem, and the system call argument is “# 99”. The meaning of the argument in the case of the system call issuance event is further described in FIG.
Can be interpreted by referring to a table as shown in FIG. For example, the system call sig In sem, the number of arguments is “1”, which means that the meaning is a semaphore ID. That is, “# 99” is a semaphore I
D.

In addition, the event reading unit 14 can switch the transfer source of the OS internal event to the break state detection unit 15 to the stored event history information storage unit 19 and transfer it. The OS internal event acquired from the OS internal event generator 5 in the multitask OS 2 can be sequentially provided to the user as trace information via the information output unit 18.

(C-6) Trace Information Output Unit The trace information output unit 18 is currently
For example, the OS internal event transmitted to the break state detecting unit 15 is sequentially shown to the user in a graphic notation as shown in FIG. 6 or a character notation as shown in FIG.

(C-7) Break Status Detecting Unit The break status detecting unit 15 updates the contents of the OS status table 16 based on the information on the OS internal event transmitted from the event reading unit 14 (step S14). As a result, the same information as the OS internal state in the multitask OS 2 is held in the OS state table 16, and its storage format is the same as that in FIG.

For example, in the timing chart shown in FIG.
The task state of task A inside S2 is a RUN state.
In this state, when an internal event at time 303 ms in FIG. 16 occurs, the task state of task A in the multitask OS 2 transits to the WAIT state. Similarly, in the software development support apparatus 3, when the break state detection unit 15 receives the event history information of the time 303 ms from the event reading unit 14, the task state of the task A stored in the OS state table 16 is RUN. Transition from the state to the WAIT state. That is, the break state detection unit 15
The contents of the OS state table 16 always hold the same state as the latest internal state of the multitask OS.

When updating the contents of the OS state table 16 described above, the break state detector 15 checks the break pattern set by the user before executing the user application (steps S14 to S14).
15). At this time, the break state detecting unit 15 changes the states of all the currently set break patterns based on the event transmitted from the event reading unit 14.

Here, the break state detection processing of the break state detection unit 15 will be described. The first break pattern is stored in the break state detection unit 15, for example, as two state transition diagrams as shown in FIG. Break state detector 1
5 initializes the state of all break patterns before starting the execution of the user application. When the state of the break pattern is initialized, the state of the break pattern becomes the initial state S ₀ in FIG. 14 and FIG.

First, look at the break pattern shown in FIG. This break pattern consists of “task B and task C
Will not be executable at the same time. " In the timing chart of FIG. 6, 100 ms has passed since the user application was executed, and the task A executed the system call sig. Issuing sem (# 99)
A task state transition event “task B → READY” indicated at 103 ms in FIG. 16 is transmitted from the event reading unit 14 to the break state detecting unit 15. In response to this, the break state detector 15 changes the state of the break pattern in FIG. 14 from the initial state S ₀ to S ₁ . Thereafter, as shown in FIG. 6, at time 200 ms, the task A executes the system call wup. Issuing tsk (# 3)
When the task state transition event “task C → READY” shown at time 203 ms in FIG. 16 occurs, the break state detecting unit 15 changes the state of the break pattern in FIG. 14 from the initial state S ₁ to the break state to transition to S _E. At this time, the task B (# 2) and the task C (# 3) can be executed at the same time, and the break pattern is in the break state. Issue a user application execution suspension request (step S1)
6 to Step S17).

Next, look at the break pattern shown in FIG. This break pattern indicates that “task C has semaphore P
Do not access. " In the timing chart of FIG. 6, 600 msec elapses after the user application is executed, and the task C executes the system call sig. When sem (# 99) is issued, the system call issuance event “task C → sig” shown at time 600 ms in FIG. sem (# 99) "is transmitted in the break state detector 15, the state of the break pattern of Figure 15 In response to this, the break from the initial state S ₀ state S _E
Transition to. At this time, the task C (# 3) accesses the semaphore P, and the state of the break pattern is changed to the break state, so that the OS control unit 17 is requested to control the user application (temporary execution of the user application). A stop request is issued (step S15 to step S17).

A plurality of break patterns can be set at the same time. In this case, the states of all the break patterns are changed according to the event and the contents of the OS state table 16, and any one of the break patterns is changed. when the state is shifted to the break state S _E, the break state detector 15 issues a request for user application control to the OS control unit 17. (C-8) Break Information Output Unit The break information output unit 20, when the break state is detected by the break state detection unit 15, as shown in FIG.
The OS status table 16 at the time of the break indicates the break pattern that triggered the break and the location where the break occurred in the program.
Then, information such as the contents of is output (step S18).

FIG. 19 shows an example of a break information output screen which is one of the user interfaces constituting the break information output section 20 when a break state based on the first break pattern is detected. In FIG. 19, the break pattern that has become a trigger and the event occurrence location in the user application are displayed at the top of the screen. The notation “task A and task C cannot be executed at the same time (task B, task C) in task A” indicates that an OS internal event has occurred in task A, such that task B and task C can be executed at that time. I have. Below that is shown which process of the program of the user application 1 has triggered the occurrence of an OS internal event. The shaded portion is the process that triggered the break. In this case, as described above, the system call wup of the task A at the time 200 ms in FIG. tsk (#
It can be seen that this is issue 3).

When the output of the break information is completed in this manner, the OS internal state reading unit 13 reads the OS internal state from the multitask OS 2 and then stores the OS internal state in the software development support device 3 as the internal storage. State table 1
6 is written as an initial value (step S11). When the writing is completed, the OS control unit 17 requests restart of the execution of the user application 1 in response to a request from the break state detection unit 15 (step S12). Less than,
The same processing operation as described above is continued.

By designating the section to be debugged in the program of the user application 1, the efficiency of the debugging operation can be improved. (D) Another Embodiment FIG. 20 shows a configuration of a computer system for realizing a software development support method used for debugging a user application executed under the OS shown in FIG. 7 according to the present invention. This computer system is, for example, a personal computer and has a CPU 1 for performing arithmetic processing.
001, an input unit 1002 such as a keyboard, a pointing device and a microphone, an output unit 1003 such as a display and a speaker, a ROM 1004 and a RAM 1005 as main storage, a hard disk device 1006 as an external storage device, a floppy disk device 1007 and an optical disk The apparatus 1008 is configured by connecting the apparatus 1008 via a bus 1009.

Here, the hard disk device 1006, floppy disk device 1007 and optical disk device 1
A program for executing the debugging process of the user application 1 shown in FIG. 7 described in the above embodiment is stored in any one of the recording media 008. The processing described in this program is the same as the processing executed in each unit of the software development support device 3 in FIG. 1, and is a program for realizing the software development support method of the present invention. As described above. The user application 1 to be debugged is also stored in any one of the hard disk device 1006, floppy disk device 1007, and optical disk device 1008. The multitask OS 2 is stored in the RAM 1005. Then, under the control of the CPU 10011,
While reading the program for executing the debugging process from the recording medium, the user application 1 is debugged under the management of the multitask OS 2 according to the program. In this manner, the software development support method of the present invention can be implemented using a normal personal computer. (E) Effects As described above, according to the embodiment, when the condition of the prohibited operation of the task of the user application 1 executed on the multitask OS 2 is input from the break pattern input unit 8, based on the condition, The break pattern generation unit 12 generates a break pattern based on the task state transition. The OS internal state reading unit 13 reads the internal state of the multitask OS (for example, the contents of the task control block of the user application 1, the contents of the semaphore control table) at the start of the execution of the user application 1, and
The event reading unit 14 records the event in the OS state table 16 as an initial value, reads an event that changes the state of the task generated during the execution of the user application 1 from the multitask OS 2, notifies the break state detection unit 15, and notifies the break state detection unit 15 of the event. The detection unit 15 updates the contents of the OS state table 16 based on the notified event, and updates the task of the user application 1 based on the notified event and the break pattern generated by the break pattern generation unit 12. Detect break status. When the break state is detected, the execution of the user application 1 is instructed to the multitask OS 2 via the OS control unit 17 and the OS internal state table 16 at that time is interrupted.
Output the contents of When the execution of the user application 1 is resumed, the OS internal state reading unit 13 is restarted.
Reads the internal state of the multitask OS and records it as the initial value of the OS internal state table 16. Therefore, it is possible to easily set a break point of execution of the user application, detect a malfunction point, and refer to an internal state of the OS when a malfunction is detected, thereby reducing a load of debugging work.

Further, a break pattern for detecting the break state of the user application to be debugged is generated based on the break pattern template stored in the break pattern library and the break condition desired by the user, thereby enabling the user application to be debugged. Bug occurrence locations can be easily detected, and the burden of debugging work can be reduced.

The OS state table 16 stores the OS internal state in the multitask OS 2 read by the OS internal state reading unit 13 and stores the stored contents in the OS state table 16.
Since the S-break state detecting unit 15 updates based on the event read from the event reading unit, the latest OS internal state is always copied to the OS state table 16, and the multitask OS 2 When information on the OS internal state in the OS becomes necessary, the information in the OS state table 16 may be referred to, and the multitask OS 2
The need for reading the memory in the multitask OS 2 is eliminated, and the debugging process is sped up.

The event reading unit 14 is a multitask OS
2 is stored in a file as event history information, and the internal events of the OS can be reproduced from the event history information, so that the internal events of the OS when the user application is actually executed are stored. The occurrence situation can be reproduced during debugging.

Furthermore, since the break pattern is configured to be represented by a state transition diagram, the internal structure of the break state detecting unit 15 is simpler than other expressions, for example, an expression using a tree structure. Can be
The overhead of the condition determination process can be reduced.

[0070]

As described above, according to the present invention,
It is possible to easily set an execution interruption (break) point of software executed on the OS, detect a malfunction point, and refer to the internal state of the OS when a malfunction is detected, thereby reducing the burden of debugging work.

[Brief description of the drawings]

FIG. 1 illustrates a configuration example of a software development support device according to an embodiment of the present invention, and a case in which a user application executed on an OS (multitask OS) is debugged using the software development support device. The figure which showed roughly the whole structure of FIG.

FIG. 2 is a diagram showing a storage example of an OS internal state.

FIG. 3 is a diagram showing a structure of a task control block of the multitask OS.

FIG. 4 is a diagram showing a structure of a semaphore control table of the multitask OS.

FIG. 5 is a diagram showing a configuration example of a user application.

FIG. 6 is a timing chart showing an example of the operation of the user application.

FIG. 7 is a flowchart for explaining the operation of the software development support device.

FIG. 8 is a diagram showing a specific example of a template of a first break pattern.

FIG. 9 is a diagram showing a specific example of a template of a second break pattern.

FIG. 10 is a diagram showing a specific example of break pattern information.

FIG. 11 is a diagram showing a specific example of application information on the entire user application.

FIG. 12 is a diagram showing a specific example of application information relating to a task.

FIG. 13 is a diagram showing a specific example of application information regarding a semaphore.

FIG. 14 is a view showing a specific example of a break pattern generated based on a first constraint condition (break pattern information) and a template of the break pattern in FIG. 8;

FIG. 15 is a view showing a specific example of a break pattern generated based on the second constraint condition (break pattern information) and the template of the break pattern in FIG. 9;

FIG. 16 is a diagram showing an example of a history of an OS internal state generated when a user application is executed.

FIG. 17 is a diagram showing an example of a table storing the meaning of an event ID and an event argument.

FIG. 18 is a diagram showing an example of a table for storing the number and contents of arguments of a system call issuance event.

FIG. 19 is a view showing a display example of a user interface of a trace information output unit.

20 is a diagram showing a configuration of a computer system for realizing a software development support method used for debugging a user application executed under the OS according to the present invention shown in FIG. 7;

[Explanation of symbols]

 DESCRIPTION OF SYMBOLS 1 ... User application 2 ... Multitask OS 3 ... Software development support apparatus 8 ... Break pattern input part 9 ... Application information storage part 10 ... Break library storage part 11 ... Break pattern storage part 12 ... Break pattern generation part 13 ... OS inside State reading unit 14 Event reading unit 15 Break state detecting unit 16 OS state table storage unit 17 OS control unit 18 Trace information output unit 19 Event history information storage unit 20 Break information output unit

Claims (3)

[Claims] 1. A task prohibition operation pattern based on a state transition of a software task executed in a system is generated, and a transition is performed according to an event generated based on the software execution when the software is executed. A software execution support method for instructing to suspend execution of the software when detecting a prohibited operation of the software task based on the state of the task and the generated pattern. 2. An input means for inputting a condition of a prohibited operation of the task based on a state transition of a software task executed in the system; and a state of the software task based on the condition input by the input means. Generating means for generating a pattern of a prohibited operation of the task based on a transition, based on a state of the task shifted according to an event generated based on the software execution when the software is executed, and the generated pattern Detecting means for detecting a prohibited operation of the software task; andinstructing means for instructing the execution of the software to be interrupted when the prohibited operation is detected by the detecting means. Software development support equipment. 3. A machine-readable recording medium on which a program for detecting a malfunction of software executed in a system is recorded, wherein the recording medium is a computer-readable recording medium. Generating means for generating a pattern of a prohibited operation; and executing the software based on a state of a task shifted according to an event generated based on the execution of the software during execution of the software and the generated break pattern. A recording medium for recording a program for executing: a detecting means for detecting a prohibited operation of the task; and an instructing means for instructing interruption of the execution of the software when the detecting means detects the prohibited operation.