KR100205061B1 - Driving method of debugger in distributed computing environment - Google Patents

Abstract

The present invention is to develop a program using a Message Passing Interface (MPI) in a distributed environment, and to find an error using a debugger as a program development tool. It's about how to make it easy to run the debugger in a distributed environment by allowing you to go directly to the debugging state. Its feature is that the Message Transfer Programming Interface (MPI) daemon can be used in a distributed environment after the master debugger is started by a user. Driving each program module of an actual distributed program by automating, driving a debugger core of each system in each program module, and executing the attach and debugging the program to make the driven program module debuggable. The module is real It sets the break point so that the debugger has control over the program being debugged, which is set in the first code part of the main function of the program, and sends a signal for the continuous execution of the program modules being debugged. Since the step and the step of receiving the command of the master debugger after transmitting the signal to perform the actual debugging operation, the present invention as described above, when debugging the distributed program in a distributed environment, the debugger without interaction with the user By automatically gaining control of the program modules being debugged, the debugger runs automatically as the MPI program runs, so debugging the MPI program is very easy because you don't have to run the debugger on every system separately. Has an effect.

Description

Debugger Operation in Distributed Environment

1 is a block diagram of a debugger driving system in a conventional distributed environment.

2 is a debugger drive signal flow diagram for FIG.

3 is a block diagram of a debugger driving system in a distributed environment according to the present invention.

4 is a debugger drive signal flow diagram for FIG.

5 is a further diagram illustrating a method for driving a debugger in accordance with the present invention.

* Explanation of symbols for main parts of the drawings

200: master debugger 201: first debugger core

202: second debugger core

203: Message Delivery Programming Interface Daemon

The present invention relates to the operation of a debugger in a distributed environment, and more particularly, to develop a program using a message passing programming interface (MPI) in a distributed environment while using a debugger as a program development tool. It is about how to easily run the debugger in a distributed environment by allowing the user to go directly to the debugging state without the user's intervention or help in finding an error.

In general, the development of a communication network in the use of a computer is a development of a distributed environment in which several systems are used for one program at the same time, rather than the program itself is limited to one computer system.

A message transfer programming interface (MPI) was established by each computer company and a group of users that could be useful for this distributed environment and used for programming.

Thus, when a user develops an application program using the message transfer programming interface (MPI), a user can easily develop a distributed program that operates on any set of computer systems.

Distributed programs developed using the message transfer programming interface (MPI) have been separated into program modules that can be executed in each computer system.

In order to execute each module in a distributed environment, a distributed program is executed by using a shell program in UNIX to develop a program that executes a module of an appropriate program on each system and executing the developed program.

In a distributed environment, the debugger is used to detect errors in the program, which requires a different approach than using the debugger on a single system.

FIG. 1 is a block diagram of a debugger driving system in a conventional distributed environment. As shown in FIG. 1, a debugger is a first debugger core (dubug core) controlling a program module of a local system and a remote system. 101, a second debugger core 102; The first debugger core (dubug core) 101, the second debugger core (102) is divided into a master debugger (mastser debugger) 100, the overall control of the distributed program, actually between the local system and the remote system There is a message passing programming interface daemon 102 that executes each program module.

A debugging method performed in the distributed environment will now be described with reference to FIGS. 1 and 2.

First, when a user drives the master debugger 100 using a fork system call of Unix (SI), the master debugger 100 searches for a locale system by searching whether the system to be driven is a local system or a remote system. The first debugger core 101 and the second debugger core 102 which actually debug the remote system and the remote system are respectively driven (S2).

Subsequently, the first debugger core 101 and the second debugger core 102 acquire control of a program module debuggee debugged and receive a command of the master debugger 100 to perform debugging (S5). (S6).

The usual way to gain control over the program that the debugger is debugging is to use Unix's fork system call to create a process that is debugged as a debugger's own child and to gain control.

However, actually executing the distributed program in the creation of the process (S3) is not the first debugger core 101 and the second debugger core 102, but the message passing programming interface daemon 103 executes the program module in each system. In the following, the first debugger core 101 and the second debugger core 102 cannot directly obtain control over the program module debugged, and the user cannot directly control the first debugger core 101 and the second debugger core 102. ) Must be attached to the program module being debugged (S4).

If the number of program modules participating in one distributed program in a distributed environment becomes very large or the number of remote systems increases, it is impractical for the user to register each system or program module one by one (S4). The module of does not automatically wait for the first debugger core 101 and the second debugger core 102, so that virtually no debugging is possible.

That is, as shown in the signal flow diagram for driving the debugger in FIG. 2, the user needs help in registering the program module to be debugged. As described in FIG. 1, the number of remote systems increases. In this case, real debugging is not possible.

As such, when debugging a distributed program in a conventional manner in a distributed environment, when the number of modules participating in a single distributed program becomes very large or the number of remote systems increases, each user or each program module is used. There is a problem that debugging is almost impossible because the registration of each program and the module of each program does not automatically wait for the debugger core.

Accordingly, an object of the present invention for solving the above problems is that the debugger automatically runs after the MPI program executed by the daemon, which is an automated part of the message transfer programming interface (MPI), which is executed in a distributed environment, executes the debugger. This is to enable debugging of MPI programs.

Another object of the present invention for solving the above problems is to enable a user to easily use the debugger when the distributed program is executed without the user's interference and help in a distributed environment.

A feature of the present invention for achieving the above object is that the message transfer programming interface (MIP) daemon after driving the master debugger by the user to drive each program module of the actual distributed program by automating the message transfer interface (MIP) in a distributed environment Driving the debugger core of each system in each of the program modules; executing the attach to make the driven program module debuggable; and the program module being debugged is the first code of the main function of the actual program. Setting a break point to allow the debugger to have control over the program being debugged and sending the signal to continue execution of the program modules being debugged, and executing the command of the master debugger after the signal transmission. Can receive actual debugging work It lies in comprising the steps of.

Hereinafter, described in detail with reference to the accompanying drawings of the present invention.

3 is a configuration diagram of a debugger driving system in a distributed environment according to the present invention. As shown therein, a first debugger core 101 and a second debugger for controlling program modules of a local system and a remote system are illustrated. Core 102; The first debugger core 101 and the second debugger cores 102 are divided into a master debugger 200 which is controlled by a user and is driven by a user. Message delivery programming daemon daemon (203).

Thus, when described in detail with reference to Figure 3 to Figure 5 the effect of the present invention configured as follows.

First, when the user drives the master debugger 200 (S100), the master debugger 200 does not drive the first debugger core 101 and the second debugger core 102, and only transmits a command (S104). .

In other words, in the present invention, as shown in FIG. 1, the master debugger 200 drives the first debugger core 101 and the second cover core 102 (S2) and the first debugger core 101. As described above, the user merely needs to drive the master debugger 200 instead of the form S4 in which the second debugger core 102 obtains control of the module to be debugged.

The process of driving the first debugger core 101 and the second debugger core 102 (S102) and obtaining control of the program module is automatically performed when the message transfer programming interface daemon 203 executes the actual distributed program. Is done.

By doing so, the first debugger core 101 and the second debugger core 102 are driven by the message transfer programming interface daemon 203 without the user's help (S102), after receiving the command of the master debugger 200. The control of the program module (debuggee) is automatically acquired to perform a debug, which is a debugged program (105).

4 is a signal flow diagram for driving a debugger in a distributed environment when using the present invention. The user simply reaches the state where the distributed program can be debugged by simply driving the master debugger 200.

In FIG. 3, the first debugger core 101 and the second debugger core 102 are automatically controlled by the message transfer programming interface daemon 203 to obtain control of a program module debugged (S102, S103). In more detail, first, the master debugger 200 is driven by the user (S100), and then the message transfer programming interface daemon 203 drives each program module of the actual distributed program (S101). As shown in FIG. 5, the first debugger core 101 and the second debugger core 102 are connected to each local system and a remote system by using a fork system call of Unix at the beginning of each program module (S102, S10). ) Will be driven.

As shown in FIGS. 3 and 5, the first debugger core 101 and the second debugger core 102 driven by the program module make the program module driving the program module debuggable. The first debugger core 101 and the second debugger core 102 are set to the first code part of the actual program main function so that the program module to be debugged and the program module to be debugged can be maintained in the initial state. After setting a breakpoint (S12) so that the debugger can have control over the program being controlled (S12), the program module continues to signal the execution of the debugged program (S13).

After the connection with the master debugger 200 (S14) receives a command (S104) and proceeds to the actual debugging (S105, S15).

In the above, the program module to be debugged recognizes that the first debugger core 101 and the second debugger core 102 have been driven, and continues execution, but is the first of the connect debugger core (connect-debugcore ()) function S16. It stops at the break point set in the code part and follows the debugging instructions of the first debugger core 101 and the second debugger core 102.

As described above, the debugger driving method in a distributed environment according to the present invention enables the debugger to automatically obtain control over a program module to be debugged without a user interaction when debugging a distributed program in a distributed environment. Therefore, since the debugger is automatically executed as the MPI program is executed, debugging the MPI program is very easy because there is no need to run the debugger separately for every system when debugging the MPI program.

Claims (4)

After the master debugger is driven by a user, a message transfer programming interface (MPI) daemon for automating a message transfer interface (MPI) in a distributed environment to drive each program module of an actual distributed program; Driving a debugger core of each system in each program module; Attach is executed to make the driven program module debuggable and the program module to be debugged is set in the first code part of the main function of the actual program so that the debugger can have control over the program being debugged. Setting a break point and signaling a continuous execution of program modules to be debugged; And performing a real debugging operation by receiving a command of a master debugger after transmitting the signal. The method of claim 1, wherein the program module to be debugged stops at a break point set at the very beginning of the program main function and follows the debugging instructions of the debugger core. The method of claim 1, wherein the debugger core is driven using a fork system call. 4. A method as claimed in claim 1 or 3, wherein the fork system is called at the beginning of each program module to drive the debugger core.