CN106201896A - Adjustment method based on checkpoint, system and device under a kind of embedded environment - Google Patents

Abstract

The invention discloses a debugging method, system and device based on a checkpoint in an embedded environment. The debugging method comprises that the host machine sends a first instruction to the target machine, so that the application program on the target machine starts to run; the host machine receives a command from the outside, and judges the type of the command; if the command is a save command, then Enter the next step; if the command is a debug command, then enter step (5); if the order is a recovery command, then enter step (6); if the order is an exit command, then enter step (8); otherwise Go to step (7); judge whether the application program is finished running, if yes, go to step (8), otherwise go to the next step; until the debugging is finished. The invention sets a check point on the target machine through the interaction between the host machine and the target machine, so that when debugging is restarted, the application program can be directly restored to run at the check point, effectively shortening the debugging cycle of the application program in the embedded environment.

Description

Checkpoint-based debugging method, system and device in an embedded environment

technical field

The invention belongs to a computer application program debugging method, and more specifically relates to a checkpoint-based debugging method, system and device in an embedded environment.

Background technique

With the development of informatization, intelligence, and networking, embedded system technology has gained a wide range of development space. For example, in important fields such as finance, transportation, electric power and military affairs, embedded software has been widely used and has become an important infrastructure that affects national development and security. The completion of many key tasks depends on embedded applications. If these applications fail, it will have many impacts on life and production. It is particularly important to improve the stability and reliability of embedded applications.

There are many large embedded applications that run for a long time. Once these programs encounter failures, debugging from scratch will waste a lot of waiting time. In order to reduce latency and enable accurate reproduction of errors, the determinism of program execution needs to be guaranteed. Since embedded systems are more streamlined than ordinary systems and have higher requirements for real-time performance, the checkpoint function in embedded systems needs to be executed faster to meet the real-time performance of embedded systems. Therefore, compared with ordinary systems , it is more difficult to realize.

The existing checkpoint technology in the embedded environment usually sets a checkpoint for a single process, but the concurrent child process cannot guarantee global consistency when it is set at the checkpoint, and each process saves multiple checkpoints at different times Point files, repeated rollbacks may occur during checkpoint recovery, and eventually the application is restored to the initial state of the application instead of the state saved by the checkpoint, which makes the checkpoint recovery operation fail.

Contents of the invention

In view of the above defects or improvement needs of the prior art, the present invention provides a debugging method, device and system based on a checkpoint, the purpose of which is to set a checkpoint on the target machine through the interaction between the host machine and the target machine, and use the checkpoint The file saves the context information of the process corresponding to the application program, so that when debugging is restarted, the application program can directly resume running at the checkpoint without having to start the program execution from the beginning, thereby reducing the waiting time during debugging and effectively shortening the application process. Program debugging cycle.

In order to achieve the above object, according to one aspect of the present invention, a debugging method based on checkpoints is provided, comprising the following steps:

(1) The host machine sends the first instruction to the target machine, so that the application program on the target machine starts to run, and the sequence number i=1 of the checkpoint is made;

(2) The host machine receives an external command and judges the type of the command; if the command is a save command, then enter step (3); if the command is a debugging command, then enter step (4); if the Said command is a recovery command, then enters step (5); if said order is an exit command, then enters step (7); otherwise enters step (6);

(3) The host machine sends a second instruction to the target machine, so that the target machine creates the i-th checkpoint at the current location of the application program, and saves the context information of the process corresponding to the application program in the i-th checkpoint corresponding to the i-th checkpoint In the checkpoint file; i=i+1, return to step (2); the process includes the parent process and the child process of the parent process;

(4) host machine sends the 3rd instruction to target machine, makes described target machine debug at the current position of application program, and returns debugging result to host machine, and host machine outputs described debugging result, returns to step (2);

(5) The host machine sends a fourth instruction to the target machine, so that the target machine restores the context information of the process corresponding to the application program from the jth checkpoint file, and restores the current position of the application program to the jth checkpoint, j is an integer from 1 to i, return to step (2);

(6) The host machine sends an error report command to the outside, and returns to step (2);

(7) The host machine sends a fifth instruction to the target machine to end the running of the application program on the target machine.

Preferably, before the step (1), it also includes connecting the host machine to the target machine.

Preferably, the applications include target applications and concurrent applications.

Preferably, the context information in the step (3) includes the state of the process, the user variable of the process, the address of the process in the register, the address of the process in the user stack of the process entry and the kernel stack.

As further preferably, the state of the process includes a process header, a thread of the process, a parent-child relationship of the thread of the process, shared data and private data of the thread of the process.

Preferably, the step (4) specifically includes the following sub-steps:

(4.1) According to the type of the debugging command, the host machine sends a third instruction to the target machine to make the target machine perform corresponding type of debugging at the current position where the application program is running;

(4.2) Within the set time period Δt, the host machine judges whether it has received the debugging result returned by the target machine, if yes, enter step (4.3), otherwise return to step (4.1);

(4.3) The host computer feeds back the debugging result to the outside, and returns to step (2).

As further preferably, the types of debugging commands include conditional breakpoints, entering functions, exiting functions, setting watchpoints, thread core binding, inserting breakpoints, querying breakpoints, single-step execution, continuous execution, execution to the end, Delete breakpoints, view variables, view thread running cores, get core running threads or count thread running time.

According to another aspect of the present invention, a checkpoint-based debugging system is also provided, including a host machine and a target machine, and the target machine includes an analysis module, an operation module, a checkpoint module, and a debugging module;

The host computer is used to send the first instruction, the second instruction, the third instruction, the fourth instruction and the fifth instruction to the analysis module, and simultaneously receive the operation result and the debugging result returned by the analysis module;

The parsing module is used to send the first instruction and the fifth instruction to the running module, the second instruction and the fourth instruction to the checkpoint module, and the third instruction to the debugging module; and feed back the running result and the debugging result to the host host;

The running module is used to run the application program according to the first instruction, and end the application program according to the fifth instruction; and when the application program finishes running, output the running result to the parsing module; Revert to the checkpoint;

The checkpoint module is used to create a checkpoint at the current location of the application program according to the second instruction, and save the context information of the process corresponding to the application program in the checkpoint file, and at the same time, according to the fourth instruction, from the checkpoint Restore the context information of the process corresponding to the application program in the file, and issue a restore instruction to the running module;

The debugging module is used for debugging at the current position of the application program, and outputs the debugging result to the parsing module.

According to another aspect of the present invention, there is also provided a debugging device for the above debugging device, including an analysis module, a running module, a checkpoint module and a debugging module;

The parsing module is used to send the first instruction and the fifth instruction to the running module, the second instruction and the fourth instruction to the checkpoint module, and the third instruction to the debugging module; and feed back the running result and the debugging result to the host host;

The running module is used to run the application program according to the first instruction, and end the application program according to the fifth instruction; and when the application program finishes running, output the running result to the parsing module; Revert to the checkpoint;

The checkpoint module is used to create a checkpoint at the current location of the application program according to the second instruction, and save the context information of the process corresponding to the application program in the checkpoint file, and at the same time, according to the fourth instruction, from the checkpoint Restore the context information of the process corresponding to the application program in the file, and issue a restore instruction to the running module;

The debugging module is used for debugging at the current position of the application program, and outputs the debugging result to the parsing module.

Generally speaking, compared with the prior art, the above technical solution conceived by the present invention can achieve the following beneficial effects due to the setting of checkpoints in the debugging process:

1. Through the interaction between the host machine and the target machine, and directly set the checkpoint and create the checkpoint file on the target machine, so that when debugging in the embedded environment, the application program can be directly restored to the location of the application program corresponding to the checkpoint Run without having to execute the application program from scratch, thereby reducing the waiting time during debugging, and can effectively shorten the debugging cycle of the application program;

2. The present invention saves the state of the process, the user variable of the process, the address of the process in the register, the address of the process in the user stack of the process table item and the kernel stack as context information in the checkpoint file, so that the present invention does not Depending on the operation of the operating system, the target machine can run on both Intel chip architectures such as X86 and mips architectures such as domestic Loongson, which has wide applicability;

3. The present invention can issue various debugging commands to the target machine according to external instructions, and is applicable to various debugging types;

4. The present invention can set multiple checkpoints, and select and restore from different checkpoint files, so as to debug the application level in a targeted manner, and further shorten the debugging time;

5. The context information saved in the checkpoint file in the present invention not only includes the context information of the process corresponding to the target application, but also includes the process context information of the concurrent application running concurrently with the target application, and the recovery of the checkpoint During operation, all applications are restored to maintain a globally consistent state, thereby enabling multi-process coordinated checkpoint operations.

Description of drawings

Fig. 1 is the structural representation of debugging device of the present invention;

Fig. 2 is a schematic flow chart of the debugging method of Embodiment 1 of the present invention;

Fig. 3 is a schematic flow chart of running an application program in Embodiment 1 of the present invention;

Fig. 4 is a schematic flow chart of setting checkpoints in Embodiment 1 of the present invention;

FIG. 5 is a schematic diagram of the process of debugging an application program according to Embodiment 1 of the present invention;

FIG. 6 is a schematic diagram of a process of restoring a checkpoint according to Embodiment 1 of the present invention.

detailed description

In order to make the object, technical solution and advantages of the present invention clearer, the present invention will be further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described here are only used to explain the present invention, not to limit the present invention. In addition, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not constitute a conflict with each other.

The invention discloses a debugging method and a debugging system based on a checkpoint. The debugging system includes a host machine and a target machine, and the target machine includes an analysis module, an operation module, a checkpoint module and a debugging module; the host machine connects the analysis module , the parsing module is connected with the running module, the checkpoint module and the debugging module respectively, and the running module is connected with the checkpoint module and the debugging module;

The debugging method specifically includes the following steps:

(0) Remotely connect the host machine and the target machine, specifically including the following sub-steps:

(0.1) The host machine receives the command of the remote login from the outside, and sends a connection instruction to the target machine, and the parameters of the command of the remote login are the user name and the IP address of the target machine;

(0.2) The host machine receives the decrypted command from the outside, and sends a decryption command to the target machine, and establishes a remote connection with the target machine;

(1) The host computer sends the first instruction to the analysis module, and the analysis module sends the first instruction to the running module after analyzing the first instruction, so that the application program on the target computer starts running; the application program includes the target application program and concurrent applications When the target application is running, the process number of the target application will be recorded in the process number file of the target machine, and the concurrent application does not necessarily run at the same time as the target application, but as long as it starts running, the concurrent application will be A signal will be sent to the target application, thereby leaving the process number of the process corresponding to the concurrent application in the process number file of the target machine;

(2) The host machine receives an external command and judges the type of the command; if the command is a save command, then enter step (3); if the command is a debugging command, then enter step (4); if the Said command is a recovery command, then enters step (5); if said order is an exit command, then enters step (7); otherwise the type host computer of this order cannot be recognized, enters step (6);

(3) The host computer sends a second instruction to the analysis module, and the analysis module analyzes the first instruction and sends it to the checkpoint module, so that the checkpoint module creates the i-th checkpoint at the current position of the application program, and according to the process number file The process number recorded in, the context information of the process corresponding to the application is stored in the i-th checkpoint file; the process includes the parent process and the child process of the parent process; i=i+1, return to the step (2); The context information includes the state of the process (as the thread of the process head, the process, the parent-child relationship of the thread of the process, shared data and private data), the user variable of the process, the address of the process in the register, the address of the process in the process The user stack and the address in the kernel stack of the entry; because in the step (2)

(4) The host machine sends a third instruction to the target machine, so that the target machine is debugged at the current position of the application program, and returns the debugging result to the host machine, and the host machine outputs the debugging result to the outside, and returns to step (2) ; Concretely include the following sub-steps:

(4.1) According to the type of debugging command, the host computer sends a third instruction to the analysis module, and the analysis module sends the third instruction to the debugging module after analyzing the third instruction, so that the debugging module performs corresponding types of commands at the current position where the application program is running. Debugging, after obtaining the debugging results, output them to the analysis module, and the analysis module will analyze the debugging results and send them to the host computer; the types of debugging commands include conditional breakpoints, entering functions, exiting functions, setting observation points, thread core binding, inserting Breakpoints, query breakpoints, single-step execution, continuous execution, execution to the end, delete breakpoints, view variables, view thread running cores, get core running threads or count thread running time;

(4.2) Within 0.3s～1.0s, the host machine judges whether it has received the debugging result returned by the analysis module, if yes, enter step (4.3), otherwise return to step (4.1);

(4.3) The host computer feeds back the debugging result to the outside, and returns to step (2);

(5) The host sends a fourth instruction to the parsing module, and the parsing module parses the fourth instruction and sends it to the checkpoint module, so that the checkpoint module restores the context of the process corresponding to the application program from the jth checkpoint file information, and send a recovery instruction to the running module, and the running module restores the current position of the application program to the jth checkpoint, where j is an integer from 1 to i, and returns to step (2);

(6) The host machine sends an error report command to the outside, and returns to step (2);

(7) The host sends a fifth instruction to the parsing module, and the parsing module parses the fifth instruction and sends it to the running module, and the running module ends the running of the application program.

During the entire debugging process, except for the moment of debugging and restoring the checkpoint, the application program continues to run until the end of the operation; in step (5), the checkpoint can be selected according to the position of the application program to be restored; if the application program has been After running to a certain location, but when a checkpoint needs to be created at that location but has not been created, you can go back to step (1) and run the application from scratch. Example 1

The test environment of this embodiment is as follows:

Host machine: CPU is Intel i5-4590@3.30GHz, memory 8G, operating system is Ubuntu 14.04; target machine: CPU is Loongson 3A, with multi-core chip, memory type DDR2 800Mhz (1G), operating system Debian.

The mainstream debuggers under Linux, such as GDB, can only run on x86 systems. In this embodiment, the embedded system of the mips architecture adopts a simplified instruction set. Compared with the ordinary system of the x86 architecture, the difficulties in implementing the checkpoint system are: 1. It is necessary to ensure the checkpoint while streamlining the checkpoint system process. All functions can be realized; 2. Faster running speed is needed to meet the higher real-time requirements of embedded systems. 3. The instruction sets of the mips architecture and the x86 architecture are different, and the addresses of registers are different, which makes it more difficult to implement the checkpoint function on the mips architecture.

As shown in Figure 2, this embodiment is a debugging process to the debugged application program test.c, which mainly includes steps such as establishing a remote connection, running the application program, setting a checkpoint, debugging the application program, and restoring the checkpoint, as follows:

(1) establish a remote connection, including the following sub-steps:

(1.1) Enter the ssh command to establish a remote connection with the target machine through the command line of the host machine. The parameters of the command are the user name and IP address of the target machine, and then go to step (1.2);

(1.2) The debugger enters the login password of the target machine on the host machine, so that the host machine and the target machine complete the establishment of a remote connection, and then go to step (2);

(2) Run the application program, as shown in Figure 3, including the following sub-steps:

(2.1) Determine whether the checkpoint kernel modules epcr_imports.ko and epcr.ko have been loaded on the target machine. If they have been loaded, go to step (2.2). If not, use the command line of the target machine to execute the load checkpoint kernel module script./sh epcr_module.sh, load the checkpoint kernel module into the kernel, and then go to step (2.2);

(2.2) Determine whether the auxiliary server server_for_checkpoint of the checkpoint on the target machine is running, if it has been running, it will directly go to step (2.3), otherwise it will use the command line terminal of the target machine to execute the command ./server_for_checkpoint to start the auxiliary server, and then go to step (2.3);

(2.3) Execute the application program executable file ./test by using the command line of the target machine, start the application program, and then turn to step (2.4);

(2.4) Start the checkpoint client ./client_for_checkpoint on the host machine, connect to the checkpoint server server_for_checkpoint on the target machine, send the file name test of the application program executed in step (2.3) to the checkpoint server end, and the checkpoint server end Find the process number of the corresponding application on the target machine, then send the process number to the checkpoint client client_for_checkpoint, and then go to step (3);

(3) The target machine judges whether a checkpoint needs to be set according to the command input by the debugger; when the debugger needs to set a checkpoint, then enter the next step, otherwise enter step (5);

(4) Checkpoint is set, as shown in Figure 4, including the following sub-steps:

(4.1) The host machine inputs the checkpoint command ./checkpoint pid–backup to the target machine to create a checkpoint preservation process. The parameters of the checkpoint preservation process are the process number pid obtained in step (2.4), and the process corresponding to the process number Be the first target process, then go to step (4.2);

(4.2) The checkpoint saving process on the target machine reads the parameters passed in from the command line in step (4.1), which will include the process number pid of the first target process, the range of record checkpoints, the context.pid descriptor of the checkpoint file and other parameters Initialize, and assign the value of the parameter to the structure variable cr_args, format it into a parameter recognizable by the checkpoint dynamic link library libcr, and then turn to step (4.3);

(4.3) The checkpoint dynamic link library initializes the parameters in step (4.2) to the form of the cri_info_t structure recognized by the kernel, and then communicates with the kernel; at the same time, open the ctrl file in the /proc file system to obtain the description of the corresponding checkpoint file character, and execute the ioctl operation to register the checkpoint saving process as a Phase2 process, then register a thread-based callback function Phase1, and then go to step (4.4);

(4.4) The checkpoint dynamic link library sends a checkpoint save request to the kernel, and the kernel constructs a process relationship tree structure according to the cr_scope in the checkpoint save request, obtains the first target process corresponding to the application program that needs to save the checkpoint, and then wakes up Phase1 A callback function, which sends the parameter CR_OP_HAND_CHKPT to the kernel, starts to save the checkpoint of the first target process, and then turns to step (4.5);

(4.5) The kernel starts to write the context information of the first target process into the checkpoint file context.pid; first, the kernel saves the file header of the checkpoint file, and then records the context of all processes in the scope of the first target process checkpoint Information is saved into the checkpoint file, including the current state of the process, the values of all user variables and data structures of the process, the value of the current register, the value stored in the process table entry, and the contents of its user stack and kernel stack; Then go to step (4.6);

(4.6) The checkpoint saving process polls through the event loop mechanism to check whether the checkpoint saving work in step (4.5) is completed. If it is completed, close the /proc node, let the application continue to run, and then go to step (5), otherwise block until The checkpoint saving job is completed;

(5) debugging application program step, as shown in Figure 5, comprises following sub-step:

(5.1) Start the debugging server on the target machine, the parameter is the file name of the application program in the step (2.4); run the debugging client on the host machine, the parameter is the IP address of the target machine and the debugged obtained in the step (2.4) The process number pid of the application, then go to step (5.2);

(5.2) The debugging server first creates a thread, calls the ptrace function in the thread, and the debugging server tracks the child process corresponding to the pid: call the ptrace function, its function parameter is PTRACE_ATTACH, the thread number is pid, address parameter and data Parameters are all 0, then carry out substep (5.3);

(5.3) The debugging server side loads the application program inside the thread created in step (5.2), and establishes a symbol table for the application program in addition, the thread that loads the application program is in a suspended state, stops at the current position of the code, and performs sub-step (5.4) ;

(5.4) The debugging client initiates a remote connection request to the debugging server. After being confirmed by the debugging server, it takes over the debugged process and establishes a remote connection. During the entire debugging process after the remote connection is established, the debugging server is always in the monitoring state , always ready to accept the RSP packets sent by the debugging client. Then go to step (5.5);

(5.5) The debugging client can send various RSP data packets to debug the application program. After receiving the debugging command input by the debugging personnel, it is judged whether the command type of the debugging command is a quit command (quit), and if so, it ends Debug, otherwise carry out sub-step (5.6);

(5.6) Traverse the debug command set defined by the debugger, find out whether the command type of the debug command exists in the debug command set, if yes, perform substep (5.7), otherwise output prompt information to the outside, prompting debug command input error, rotor Step (5.5): In addition to the debugging operations owned by mainstream debuggers, the debugging command set also includes the following command types of debugging commands: thread core binding, inserting breakpoints, querying breakpoints, single-step execution, continuous execution, execution To the end, delete breakpoints, view variables, view thread running cores, get core running threads, and count thread running time;

(5.7) The debugging command is used as data, encapsulated into an RSP packet, and sent to the target machine debugging server end, if the execution result of the target machine debugging server end is received within 0.5 seconds, then carry out substep (5.9), otherwise the rotor step (5.5);

(5.9) The debugging client parses the execution results, obtains the debugging results, and feeds back the debugging results to the debugging personnel; the debugging personnel judges whether the error in the application program has been located according to the feedback debugging results, and sends an instruction to the host to terminate the debugging, Return to step (5.5), otherwise go to step (6);

(6) Restoring the checkpoint step, as shown in Figure 6, includes the following sub-steps:

(6.1) According to the process number pid of the debugged application obtained in step (2.4) or the checkpoint file context.pid specified by the user, use the target machine to execute the checkpoint recovery process ./cr_restart context.pid, and the parameter is the checkpoint to be restored Click the file context.pid, then go to step (6.2);

(6.2) The checkpoint recovery process on the target machine reads the parameters of the checkpoint file imported in step (6.1) from the command line; this parameter includes the path of the checkpoint file and the recovery process to send to the checkpoint recovery process after running Signal etc., then go to step (6.3);

(6.3) The checkpoint dynamic link library initializes the parameters of the checkpoint file in step (6.2) into the cri_info_t structure form that the kernel can recognize, and then communicates with the kernel; at the same time, open the ctrl file in the /proc file system to obtain Corresponding to the file descriptor, perform ioctl operation on it to register the checkpoint recovery process as a Phase2 process, then register a thread-based callback function Phase1 for the checkpoint recovery process of the first target process, and then turn to step (6.4);

(6.4) The checkpoint dynamic link library sends a checkpoint recovery request to the kernel, and the kernel reads the structure cr_rstrt_args data in the checkpoint recovery request, and calls the function to allocate and initialize the variable req of the checkpoint recovery request, and then obtains the checkpoint file Path, and read the context information from the checkpoint file, and judge the version of the checkpoint server, whether the architecture and kernel version of the first target process are consistent with the corresponding context information in the checkpoint system, if not, then End directly, otherwise go to step (6.5);

(6.5) The kernel reads the context information from the checkpoint file context.pid, then writes the process header from the kernel to the user layer, and then calls the checkpoint recovery process as the parent process for the process that is determined to exist in the checkpoint file and waits for recovery fork() creates a child process, the child process starts the checkpoint recovery operation, calls the clone() system call, creates a second target process, the child process calls the ioctl() function to communicate with the kernel, and sends the parameter CR_OP_RSTRT_CHILD to the kernel layer, and the kernel layer is Restore the content of all process information in the checkpoint file corresponding to the first target process in the second target process, then go to step (5.6);

(6.6) The checkpoint recovery process waits for the child process of the checkpoint recovery process to complete the checkpoint recovery operation through the event loop mechanism. When the second target process completes the checkpoint recovery work, the checkpoint recovery process performs related Cleanup work, release some relevant data structures in the process of checkpoint recovery, then make the first target process the second target process, go to step (5.1), without having to execute the application program from scratch, thereby shortening the waiting time during debugging .

Example 2

The test environment of embodiment 2 is the same as embodiment 1

As shown in Figure 2, this embodiment is a debugging process to the debugged application program sigtest1.c, which mainly includes steps such as establishing a remote connection, running the application program, setting a checkpoint, debugging the application program, and restoring the checkpoint, as follows:

(1) establish a remote connection, including the following sub-steps:

(1.1) Enter the ssh command to establish a remote connection with the target machine through the command line of the host machine. The parameters of the command are the user name and IP address of the target machine, and then go to step (1.2);

(1.2) The debugger enters the login password of the target machine on the host machine, so that the host machine and the target machine complete the establishment of a remote connection, and then go to step (2);

(2) Run the target application program and the concurrent application program, including the following sub-steps:

(2.1) Determine whether the checkpoint kernel modules epcr_imports.ko and epcr.ko have been loaded on the target machine. If they have been loaded, go to step (2.2). If not, use the command line of the target machine to execute the load checkpoint kernel module script./sh epcr_module.sh, load the checkpoint kernel module into the kernel, and then go to step (2.2);

(2.2) Determine whether the auxiliary server server_for_checkpoint of the checkpoint on the target machine is running, if it has been running, it will directly go to step (2.3), otherwise it will use the command line terminal of the target machine to execute the command ./server_for_checkpoint to start the auxiliary server, and then go to step (2.3);

(2.3) Use the command line of the target machine to run the mapcreate program to create a file to save the process number that needs to be checked;

(2.4) Use the target machine command line to execute the target application executable file ./sigtest1, start the target application program, obtain the first target process corresponding to the target application program, and then use the target machine command to execute the concurrent application program executable file./ sigtest2 80, start the concurrent application program, and obtain the concurrent process corresponding to the concurrent application program, at this time, the first target process and the concurrent process run concurrently; 80 in the concurrent application executable file is the concurrent process sending to the first target process signal, the first target process running at this time receives this signal; since both the target application program and the concurrent application program are linked with the libsigqueue.so dynamic link library; at this time, the dynamic link library rewrites the sigqueue function, and the concurrent process Call the sigqueue function to send a signal. When running a concurrent application, this function saves the concurrent process and the process number corresponding to the first target process in the form of a structure in the file created in step (2.3), and then turns to step (2.5 );

(2.5) Start the checkpoint client ./client_for_checkpoint on the host machine, connect to the checkpoint server server_for_checkpoint on the target machine, send the file name sigtest1 of the target application program executed in step (2.4) to the checkpoint server, and the checkpoint server The terminal searches for the corresponding first process number of the first target process on the target machine, then sends the process number to the checkpoint client client_for_checkpoint, and then turns to step (3);

(3) The target machine judges whether a checkpoint needs to be set according to the command input by the debugger; when the debugger needs to set a checkpoint, then enter the next step, otherwise enter step (5);

(4) Checkpoint is set, including the following sub-steps:

(4.1) The host machine inputs the checkpoint command ./checkpoint pid–backup to the target machine to create a checkpoint preservation process whose parameter is the first process number obtained in step (2.5); meanwhile, by traversing the steps (2.3) In the file created, the structure saved in step (2.4) obtains the second process number corresponding to the concurrent process, and then turns to step (4.2);

(4.2) The checkpoint saving process on the target machine reads the parameters imported from the command line into step (4.1), initializes the parameters including the first target process and concurrent processes, and assigns the value of the parameters to the structure variable, Format it into parameters recognizable by the checkpoint dynamic link library libcr, and then turn to step (4.3);

(4.3) The checkpoint dynamic link library initializes the parameters in step (4.2) into the form of the cri_info_t structure recognized by the kernel, and then communicates with the kernel; at the same time, open the ctrl file in the /proc file system to obtain the corresponding checkpoint file descriptor, and execute the ioctl operation to register the checkpoint saving process as a Phase2 process, then register two thread-based callback functions Phase1, and then go to step (4.4);

(4.4) The checkpoint dynamic link library sends a checkpoint storage request to the kernel, and the kernel constructs a process relationship tree structure according to the cr_scope in the checkpoint storage request, and obtains the corresponding first target process and concurrent process of the application program that needs to save the checkpoint, Then wake up the Phase1 callback function, which sends the parameter CR_OP_HAND_CHKPT to the kernel, starts to save the checkpoint of the first target process and the concurrent process, and then turns to step (4.5);

(4.5) The kernel starts to write the context information of the first target process and the concurrent process into the checkpoint file context.pid respectively; first, the kernel saves the file header of the checkpoint file, and then writes the context information of the first target process and the concurrent process Save into the checkpoint file, including the current state of the process, the value of all user variables and data structures of the process, the value of the current register, the value saved in the process table entry, and the contents of its user stack and kernel stack; and then Go to step (4.6);

(4.6) The checkpoint saving process polls through the event loop mechanism to check whether the checkpoint saving work in step (4.5) is completed. If it is completed, close the /proc node, let the target application and concurrent programs continue to run, and then go to step (5) , otherwise block until the checkpoint saving work is completed;

(5) debugging application program step, as shown in Figure 5, comprises following sub-step:

(5.1) Start the debugging server on the target machine, the parameter is the file name of the target application program in the step (2.5); run the debugging client on the host machine, the parameter is the IP address of the target machine and the target obtained in the step (2.5) The process number pid of the application, then go to step (5.2);

(5.2) The debugging server first creates a thread, calls the ptrace function in the thread, and the debugging server tracks the child process corresponding to the pid: call the ptrace function, its function parameter is PTRACE_ATTACH, the thread number is pid, address parameter and data Parameters are all 0, then carry out substep (5.3);

(5.3) The debugging server loads the target application program inside the thread created in step (5.2), and additionally establishes a symbol table for the target application program, the thread loading the target application program is in a suspended state, stops at the current position of the code, and performs sub-steps (5.4);

(5.4) The debugging client initiates a remote connection request to the debugging server. After being confirmed by the debugging server, it takes over the debugged process and establishes a remote connection. During the entire debugging process after the remote connection is established, the debugging server is always in the monitoring state , always ready to accept the RSP packets sent by the debugging client. Then go to step (5.5);

(5.5) The debug client can send various RSP data packets to debug the target application program. After receiving the debug command input by the debugger, judge whether the command type of the debug command is an exit command (quit), if so End debugging, otherwise carry out sub-step (5.6);

(5.6) Traverse the debug command set defined by the debugger, find out whether the command type of the debug command exists in the debug command set, if yes, perform substep (5.7), otherwise output prompt information to the outside, prompting debug command input error, rotor Step (5.5): In addition to the debugging operations owned by mainstream debuggers, the debugging command set also includes the following command types of debugging commands: thread core binding, inserting breakpoints, querying breakpoints, single-step execution, continuous execution, execution To the end, delete breakpoints, view variables, view thread running cores, get core running threads, and count thread running time;

(5.7) The debugging command is used as data, encapsulated into an RSP packet, and sent to the target machine debugging server end, if the execution result of the target machine debugging server end is received within 0.5 seconds, then carry out substep (5.9), otherwise the rotor step (5.5);

(5.9) The debugging client parses the execution results, obtains the debugging results, and feeds back the debugging results to the debugging personnel; the debugging personnel judges whether the error in the application program has been located according to the feedback debugging results, and sends an instruction to the host to terminate the debugging, Return to step (5.5), otherwise go to step (6);

(6) Restoring the checkpoint step, as shown in Figure 6, includes the following sub-steps:

(6.1) According to the first process number obtained in step (2.4) or the checkpoint file context.pid in step (4.3), use the target machine to execute the checkpoint recovery process./restart context.pid, the parameter is the checkpoint to be restored File context.pid, then go to step (6.2);

(6.2) The checkpoint recovery process on the target machine reads the parameters of the checkpoint file imported in step (6.1) from the command line; this parameter includes the path of the checkpoint file and the recovery process to send to the checkpoint recovery process after running Signal etc., then go to step (6.3);

(6.3) The checkpoint dynamic link library initializes the parameters of the checkpoint file in step (6.2) into the cri_info_t structure form that the kernel can recognize, and then communicates with the kernel; at the same time, open the ctrl file in the /proc file system to obtain Corresponding to the file descriptor, perform an ioctl operation on it to register the checkpoint recovery process as a Phase2 process, then register a thread-based callback function for the first target process and the checkpoint recovery process of the concurrent process, and then turn to step (6.4);

(6.4) The checkpoint dynamic link library sends a checkpoint recovery request to the kernel, and the kernel reads the structure cr_rstrt_args data in the checkpoint recovery request, and calls the function to allocate and initialize the variable req of the checkpoint recovery request, and then obtains the checkpoint file Path, and read the context information from the checkpoint file, and determine whether the version of the checkpoint server, the architecture and kernel version of the first target process and concurrent processes are consistent with the corresponding context information in the checkpoint system, If inconsistent, end directly, otherwise go to step (6.5);

(6.5) The kernel reads the context information from the checkpoint file context.pid, then writes the first target process and the concurrent process process header from the kernel to the user layer, and then checks for the process that is determined to exist in the checkpoint file and waits for recovery Point recovery process as the parent process calls fork() to create a child process, the child process starts the checkpoint recovery operation, calls the clone() system call, creates the second target process and the third target process, the child process calls the ioctl() function and the kernel obtains Communication, sending parameter CR_OP_RSTRT_CHILD to the kernel layer, the kernel layer recovers the content of all process information in the checkpoint file corresponding to the first target process and the concurrent process in the second target process and the third target process respectively, and then turns to step (5.6);

(6.6) The checkpoint recovery process waits for the child process of the checkpoint recovery process to complete the checkpoint recovery operation through the event loop mechanism. When the second target process completes the checkpoint recovery work, the checkpoint recovery process performs related Cleanup work, release some relevant data structures in the checkpoint restoration process, then make the first target process the second target process, and the concurrent process as the third target process, turn to step (5.1), without having to execute the application program from scratch, This shortens the waiting time during commissioning.

When the concurrent process starts and sends a signal to the first target process, the checkpoint file will record the status of the signal sent by the concurrent process; so that when this embodiment performs a checkpoint save operation on the process, the first target process and all participating concurrent operations Concurrent processes maintain a globally consistent state, so that the concurrency-related state recorded in the checkpoint file is synchronized; and when the checkpoint recovery operation is performed, all concurrent processes are restored to maintain a globally consistent state, thereby achieving Multi-process cooperative checkpoint operation.

It is easy for those skilled in the art to understand that the above descriptions are only preferred embodiments of the present invention, and are not intended to limit the present invention. Any modifications, equivalent replacements and improvements made within the spirit and principles of the present invention, All should be included within the protection scope of the present invention.

Claims (9)

1. an adjustment method based on checkpoint, it is characterised in that comprise the following steps:

(1) host sends the first instruction to target machine, makes the application program on target machine bring into operation, makes the sequence number of checkpoint I=1；

(2) order outside host reception, and judge the type of described order；If described order is for preserving order, then enter Enter step (3)；If described order is debug command, then enter step (4)；If described order is for recovering order, then enter Step (5)；If described order is for exiting command, then enter step (7)；Otherwise enter step (6)；

(3) host sends the second instruction to target machine, makes target machine create the i-th checkpoint in the current location of application program, And the contextual information of process corresponding for described application program is stored in the i-th check point file；I=i+1, returns step (2)；

(4) host sends the 3rd instruction to target machine, makes described target machine debug in the current location of application program, and to place Main frame returns debugging result, and described debugging result is exported by host, returns step (2)；

(5) host sends the 4th instruction to target machine, makes described target machine recover application program pair from jth check point file The contextual information of the process answered, and the current location recovery run by application program is to jth checkpoint, j is the integer of 1～i, Return step (2)；

(6) host sends the instruction that reports an error to outside, returns step (2)；

(7) host sends the 5th instruction, the operation of the application program on target end machine to target machine.

2. adjustment method as claimed in claim 1, it is characterised in that also included before described step (1), by host even It is connected to target machine.

3. adjustment method as claimed in claim 1, it is characterised in that the contextual information in described step (3) includes process State, the user-variable of process, process address in a register, process is in the user stack and kernel stack of process list item Address.

4. adjustment method as claimed in claim 3, it is characterised in that described state of a process includes the line of process head, process Journey, the filiation of thread of process, shared data and private data.

5. adjustment method as claimed in claim 1, it is characterised in that described step (4) specifically includes following sub-step:

(4.1) according to the kind of debug command, host sends the 3rd instruction to target machine, makes described target machine at application program The current location run carries out the debugging of corresponding kind；

(4.2) in the time period Δ t set, host judges whether to receive the debugging result that target machine returns, and is to enter Step (4.3), otherwise returns step (4.1)；

(4.3) described debugging result is fed back to outside by host, returns step (2).

6. adjustment method as claimed in claim 5, it is characterised in that the kind of described debug command includes conditional breakpoint, enters Enter function, jump out function, arrange point of observation, the binding of thread core, insert breakpoint, inquiry breakpoint, single step perform, continuously carry out, hold Walk to terminate, delete breakpoint, check variable, check thread run core, obtain core active thread or statistics thread run the time.

7. adjustment method as claimed in claim 5, it is characterised in that the described time period Δ t set is as 0.3s～1.0s.

8. a debugging system based on checkpoint, it is characterised in that include that host and target machine, described target machine include Parsing module, operation module, checkpoint module and debugging module；

Described host is for sending the first instruction, the second instruction, the 3rd instruction, the 4th instruction and the five fingers to parsing module Order, receives operation result and debugging result that parsing module returns simultaneously；

Described parsing module is for being sent to run module, the second instruction and the 4th instruction by the first instruction and the 5th instruction Being sent to checkpoint module, the 3rd instruction is sent to debugging module；And operation result and debugging result are fed back to host；

Described operation module is used for according to the first instruction operation application program, and according to the 5th order fulfillment application program；And When application program end of run, export operation result to parsing module；Simultaneously according to recovering instruction, application program is run Current location is recovered to checkpoint；

Described checkpoint module is for according to the second instruction, in the establishment checkpoint, current location of application program, and answers described It is stored in check point file with the contextual information of process corresponding to program, simultaneously according to the 4th instruction, from check point file The contextual information of the process that middle recovery application program is corresponding, and send recovery instruction to running module；

Described debugging module is for debugging in the current location of application program, and debugs result to parsing module output.

9. the debugging apparatus for debugging apparatus described in claim 8, it is characterised in that include parsing module, run mould Block, checkpoint module and debugging module；

Described parsing module is for being sent to run module, the second instruction and the 4th instruction by the first instruction and the 5th instruction Being sent to checkpoint module, the 3rd instruction is sent to debugging module；And operation result and debugging result are fed back to host；

Described operation module is for according to the first instruction operation application program, according to the 5th order fulfillment application program, and is answering During with program end of run, export operation result to parsing module；Simultaneously according to recovering instruction, that is run by application program is current Position is recovered to checkpoint；

Described checkpoint module is for according to the second instruction, in the establishment checkpoint, current location of application program, and answers described It is stored in check point file with the contextual information of process corresponding to program, simultaneously according to the 4th instruction, from check point file The contextual information of the process that middle recovery application program is corresponding, and send recovery instruction to running module；

Described debugging module is for debugging in the current location of application program, and debugs result to parsing module output.