JPH05181700A - How to create a multi-process debugger - Google Patents

Abstract

(57) [Summary] (Modified) [Purpose] To provide a method for easily creating a multi-process debugger capable of comprehensively debugging a multi-process program. According to a duplication instruction generated in a first inspected program A, a first debugger D _A for the first inspected program is duplicated, and then the duplicated debugger D _A ′ is replaced with a second debugger. D _B , while executing the duplication of the first inspected program A and changing the duplicated inspected program A ′ to the second inspected program B under the control of the second debugger D _B , Further, a communication path C is created between the first and second debuggers.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a method for creating a multi-process debugger that comprehensively debugs a plurality of processing sequences processed in parallel.

[0002]

2. Description of the Related Art A conventional debugger can debug only when there is a single processing sequence realized by a program to be inspected as a debug target, and a plurality of processing sequences to be processed in parallel can be comprehensively processed. Couldn't debug to. That is, each debugger only individually and independently inspects each processing sequence, and when a plurality of processing sequences move in parallel, it is impossible to comprehensively trace them. For example, it has not been possible to satisfy the requirement that the program A should see the state when the program B has progressed to b when the program A has progressed to a.

For this reason, the following inspection method has been adopted when conducting a failure investigation or program development when a large number of people use the RDB (relational database).
That is, each program is first rewritten by inserting a test message into a required part on the program side, and the operator guesses the movement from the test message displayed by executing the rewritten program in this way. Was being done.

[0004]

However, the above-mentioned conventional techniques require a great deal of labor and time, and it is very disadvantageous to perform this for each multi-process program. Therefore, the present invention provides a method for easily creating a multi-process debugger capable of comprehensively debugging a multi-process program.

[0005]

According to the present invention, the duplication of the first debugger for the first inspected program is executed after the duplication of the first debugger for the first inspected program in response to the duplication instruction generated in the first inspected program. The debugger is changed to the second debugger, while the copy of the first inspected program is executed, the copied inspected program is changed to the second inspected program under the control of the second debugger, and A method of creating a multi-process debugger is provided which creates a communication path between the first and second debuggers.

[0006]

When the program A to be inspected is duplicated in the middle to become the program B, and the programs A and B perform processing in parallel from a certain point in time, as shown in FIG. Accordingly, a copy of the debugger DA for this program A is executed first and the debugger D
Create A ′. After that, the replica debugger DA 'is changed to the debugger DB. On the other hand, the program A'obtained by executing the duplication of the program A is changed to the program B under the control of the debugger DB, and the communication path C is created between the debuggers DA and DB.

[0007]

FIG. 2 is a block diagram schematically showing the structure of a system for producing a multi-process debugger as an embodiment of the present invention.

In FIG. 1, reference numeral 10 denotes a control device mainly composed of a CPU. The control device 10 includes an input device 11 such as a keyboard, a display device 12, and an internal storage device 13 in which a shared memory described later exists. , And the external storage device 14 are connected.

FIG. 3 is a flow chart of a multi-process debugger creation program in the system of FIG.
The present invention will be described in detail below with reference to this drawing.

The UNIX OS (operation system) has two processes, "fork" and "exec", and usually, these two processes are used to realize multi-process. Here, the fork instruction is an instruction that the program A duplicates exactly the same including the state of the memory, and is separately managed as two processes in the system. The exec instruction is an instruction for changing the program A to another program B, and is managed as the same process as the system. These two
The two processes are linked to a program in the form of a library to form a multi-process program.

In the present invention, a multi-process debugger is created by linking a debugger-dedicated library, which operates as described below, with the program to be inspected, instead of such an ordinary library.

Debugger dp1 of the program to be inspected p1
First, the shared memory is secured and the self process number (dp1) and the process number (p1) of the program to be inspected p1 are written at the head of the shared memory (see FIG. 4). This shared memory is configured to be visible to all debuggers.

When a fork instruction is issued in the program to be inspected p1, the debugger-dedicated library linked to the program to be inspected first sends a signal (in UNIX, sig in UNIX) to the debugger dp1 in step S1.
nal) to notify the debugger dp1 that the pseudo-fork state has been entered. This signal causes the debugger d
It becomes possible for p1 to know the state transition of multi-process.

Next, in step S2, the fork instruction is actually executed. As a result, a child process is formed by duplicating the debugger dp1 and the program p1 which are parent processes, and this child process executes fork to generate a grandchild process.

In the next step S3, the child process attaches (makes accessible) the shared memory, the process number dp2 of the child process is the debugger process number, and the process number p2 of the grandchild process is its inspected program process number. Write to memory.

Then, in step S4, the exec instruction is executed to change the child process to the debugger dp2.

The debugger dp2 attaches to the shared memory again and exchanges necessary information such as a breakpoint with the debugger dp1 (step S5). Note that the debugger dp1 is s
From the point of receiving the signal, it becomes an interrupt process,
It is ready for information exchange and is waiting for communication with the debugger dp2. When the communication with the debugger dp2 is completed, the debugger dp1 waits for the preparation of the debugger dp2 and its inspected program p2 (the copy p1 'of the program p1 at this point) and returns to the normal processing.

In the next step S6, the program p
1'executes ptrace (0) to enable tracing by the debugger dp2.

Finally, the debugger dp2 and the program p
When 1'is ready, the debugger dp1 and the program p1 are notified of the completion by using the communication communication route table of the shared memory (see FIG. 4) (step S
7). As a result, the debugger dp1 returns the process number p2 of the program p1 'as a return value, and the program p1' side returns 0 as a return value. This communication path can be easily realized by using IPC (Inter Process Communication) of the OS.

As described above, the debugger dp1 recognizes that the program p1 'is its own child process, but in reality the program p1' is under the control of the debugger dp2, and parallel processing is performed. In this case, both programs p1 and p2 can be debugged together.

Then, in step S8, the debugger d
By sending a signal to p2, this debugger dp2
The xec instruction is executed to change the program p1 'into the program to be inspected p2.

As a result, the debugger dp1 inspects the program p1, the debugger dp2 inspects the program p2, and both debuggers perform debugging while communicating with each other. It can be carried out.

The shared memory described above can also be used for notification of input / output switching in multi-process debugging. For example, it is assumed that the input and output are all managed by the first debugger, and when switching to another process, the first debugger is notified by a special key operation. This debugger writes the key input of the operator together with the process number of the corresponding debugger in the communication communication route table of the shared memory when the response to other than itself is requested. Other debuggers are always looking at this shared memory while waiting for input, execute any instruction to themselves, and write the result to this shared memory again. For synchronization (waiting), a function such as a semaphore may be used.

[0024]

As described above in detail, according to the present invention, after the copy of the first debugger for the first inspected program is executed according to the copy instruction generated in the first inspected program. , Change the duplicated debugger to a second debugger, while executing the duplicate of the first inspected program,
The duplicated program to be inspected is changed to the second program to be inspected under the control of the second debugger, and a communication path is created between the first and second debuggers. It is possible to easily create a multi-process debugger that can be comprehensively debugged easily in a short period of time.

[Brief description of drawings]

FIG. 1 is an explanatory diagram schematically showing a multi-process debugger creation function of the present invention.

FIG. 2 is a block diagram schematically showing a configuration of a system for creating a multi-process debugger as an embodiment of the present invention.

3 is a flowchart of a multi-process debugger creation program in the system of FIG.

FIG. 4 is a diagram showing a communication contact route table in a shared memory.

[Explanation of symbols]

 10 Control Device 11 Input Device 12 Display Device 13 Internal Storage Device 14 External Storage Device

Claims (1)

[Claims] 1. A copy of a first debugger for the first inspected program is executed in response to a copy instruction generated in the first inspected program, and then the copied debugger is changed to a second debugger. On the other hand, the first inspected program is duplicated, the duplicated inspected program is changed to the second inspected program under the control of the second debugger, and the first and second A method for creating a multi-process debugger characterized by creating a communication path between debuggers.