A method and system for live debugging of a Linux application

Abstract

The application relates to the technical field of application program debugging, and discloses a Linux application program on-site debugging method and system. When the Linux application program needs to be on-site debugged, a debugging command is input in a shell command line of the Linux application program, and the following operations are executed: checking the data structure content in the application program, checking the real-time execution situation of program steps, calling a test routine, and analyzing debugging information or logs, so that on-site debugging of the Linux application program is realized. The application solves the problems of interference with application program running, influence on system functions and performance and the like in the prior art when debugging in an embedded Linux real-time application program environment.

Description

Technical Field

[0001] This invention relates to the field of application debugging technology, specifically a method and system for on-site debugging of Linux applications. Background Technology

[0002] Linux application debugging typically uses gdb as the primary tool. gdb effectively tracks, monitors, and modifies the application's runtime state. During debugging, gdb is generally used to view the values ​​of certain variables, the values ​​of specific entries in data tables, or to set breakpoints in critical functions to observe for any abnormalities in code execution and thus locate problems.

[0003] GDB possesses a complete and powerful set of debugging commands and methods. However, in embedded environments, system memory and external storage space are extremely limited. Using GDB for application debugging consumes already strained CPU and memory resources, severely impacting system efficiency. Memory resources are particularly limited in embedded environments, sometimes even failing to meet the requirements for GDB to properly function with the coredump mechanism, or resulting in extremely poor coredump performance. GDB debugging can never be truly lightweight. Furthermore, when debugging applications with GDB, the application's own execution efficiency is significantly reduced. For example, setting breakpoints in a function requires manually tracing and examining its execution step by step. This debugging method can produce unpredictable errors for applications with real-time requirements and cannot be used to debug the application's business logic, rendering GDB practically unusable in such scenarios. For instance, GDB breakpoint debugging can cause OSPF route neighbor maintenance timeouts, leading to routing protocol malfunctions.

[0004] When a program has already been delivered to the user, using gdb to debug it on-site can interfere with the program's operation, impacting the overall system's functionality and performance. This severely reduces the user's trust in the manufacturer's analysis, troubleshooting, and problem-solving abilities, potentially leading to incalculable losses. For example, in communication and network systems, routing interruptions or oscillations must be avoided during on-site debugging. Furthermore, gdb is ineffective for troubleshooting issues that require long-term observation and on-site data capture and comparative analysis to pinpoint the problem. Summary of the Invention

[0005] To overcome the shortcomings of existing technologies, this invention provides a method and system for on-site debugging of Linux applications, solving problems such as interference with application operation and impact on system functionality and performance when debugging in an embedded Linux real-time application environment.

[0006] The technical solution adopted by the present invention to solve the above problems is:

[0007] A method for on-site debugging of Linux applications is provided. When a Linux application needs on-site debugging, the debug command is entered in the shell command line of the Linux application to perform the following operations: view the real-time execution of data structure content and algorithm steps in the application, call test routines, and analyze debug information or logs, thereby realizing on-site debugging of the Linux application.

[0008] As a preferred technical solution, the cmd module is used to operate debugging commands; where the cmd module represents the debugging interface public library module, and the cmd module is used for registering debugging commands, executing debugging commands, and returning the results of debugging command execution.

[0009] As a preferred technical solution, the cmd module follows these rules:

[0010] A. Debugging command registration must be completed by calling `cmd_reg_int` and `cmd_reg` after the first line of the `main` function in the Linux application source code has been initialized. For easier on-the-spot debugging, the extended `cmd_reg_int_ex` and `cmd_reg_ex` should be called for registration, passing a pointer to a string containing the usage instructions for the command. Here, `main` represents the main function of the Linux application; `cmd_init` represents the debug interface public library initialization function; `cmd_reg_int` represents the debug variable registration interface, responsible for registering debug variables; `cmd_reg` represents the debug function registration interface, responsible for registering debug functions; and `cmd_reg_int_ex` represents the debug variable extension registration interface, and `cmd_reg_ex` represents the debug function extension registration interface.

[0011] B. The execution of debug commands is carried out by the debug command daemon thread reading the commands and parameters from the command pipe and then creating a new command thread to execute them; among them, the debug command daemon thread of each application is created by the cmd module and attached to the instance process of the application;

[0012] C. The result of command execution is returned by the command thread to the command daemon thread, then returned to the debugging command process through a pipe corresponding to the PID of the current debugging command process, and finally returned to the shell of the Linux system; where shell refers to the shell program.

[0013] As a preferred technical solution, the steps include:

[0014] S1, cmd added: When writing Linux application code, add the cmd module source code file to the Linux application project;

[0015] S2, Initialization: In the first line of execution of the main function of the Linux application, the cmd_init initialization function is called to initialize the debug interface public library of the Linux application;

[0016] S3, Command daemon thread creation: Call phtread_create to create the cmd_main_thread command daemon thread; where phtread_create represents the Linux thread creation interface;

[0017] S4, Debug command registration: Register debug variables and debug functions;

[0018] S5, Debug command execution: Query and modify debug variables, and execute debug functions;

[0019] S6, Return of debug command execution result: Returns the result of debug command execution.

[0020] As a preferred technical solution, in step S2, the cmd_init initialization function mainly completes one or more of the following: program name, current working directory, startup parameters, and program PID.

[0021] As a preferred technical solution, in step S3, the cmd_main_thread command daemon thread is implemented by using the code while(1){determine if there is data to read in the command pipe}, and the cmd_main_thread command daemon thread is blocked on the command pipe of the Linux application.

[0022] As a preferred technical solution, step S4, registering debug variables includes the following steps:

[0023] S4A1 defines and declares global variables using the C language;

[0024] S4A2, calling cmd_reg_int or cmd_reg_int_ex registers global variables as debuggable variables for the cmd module: cmd_reg_int or cmd_reg_int_ex directly converts the variable name to a function name and calls the cmd_reg_ex interface to establish a mapping relationship between the variable name and the background function. At the same time, the registered global variable name is passed as a parameter to cmd_default_func_param_init. cmd_default_func_param_init mainly implements the registration of global variable name entries. Among them, cmd_reg_int represents the debug variable registration interface, cmd_reg_int_ex represents the debug variable extension registration interface, cmd_reg_ex represents the debug function extension registration interface, and cmd_default_func_param_init represents the debug variable to debug function conversion interface.

[0025] With S4A3, typing "variable_name" in the Linux shell will return the value of the debug variable with the same name in the application; typing "variable_name_set_value" in the Linux shell will pass the set value to the debug variable with the same name in the application.

[0026] As a preferred technical solution, step S4, registering the debug function includes the following steps:

[0027] S4B1, declares and implements the function body;

[0028] S4B2 calls the cmd_reg or cmd_reg_ex interface to register debug commands in the application. Each debug command corresponds to a registered debug function, and all debug commands eventually form a callback map. Then, cmd_reg_ex scans this callback map to determine if a debug command with the same name exists. If it does, an error is displayed; otherwise, the debug command registration process is performed. During registration, the corresponding fields are filled according to the structure of the CMD_EVENT_REG event and written to the command pipeline. Here, cmd_reg represents the debug function registration interface, cmd_reg_ex represents the debug function extension registration interface, and CMD_EVENT_REG represents the CMD debug command registration event.

[0029] S4B3, the cmd_main_thread command daemon thread blocked in the command pipe is awakened, and then the cmd command registration work is performed, associating the debug command, callback function, and callback parameters to form a callback mapping table entry; at the same time, a symbolic link with the same name as the debug command is created in the / bin directory of the Linux application, and this symbolic link points to the executable file corresponding to the current Linux application; where / bin represents the default directory of the file system where executable files are stored.

[0030] S4B4 is a Linux application containing a cmd module that is cross-compiled to obtain an executable file; then the executable file is started in the background with an "&" symbol added, and on-site debugging is performed after it starts.

[0031] S4B5: When a debug command is typed in the Linux shell, a copy of the Linux application starts. The copy calls the cmd_init code to execute. The copy recognizes that it is a debug command call and fills the CMD_EVENT_CALL event according to a pre-defined structure format and writes it to the command pipe. After successful writing, the copy creates a named pipe and blocks on the named pipe, waiting for the return value of the debug command after execution by the main program. Here, cmd_init represents the debug interface initialization function.

[0032] S4B6, when the main program's cmd_main_thread command daemon reads the CMD_EVENT_CALL event on the command pipe, it creates a new command execution thread according to the pre-defined data communication format and then calls the corresponding callback function to execute; where CMD_EVENT_CALL represents the CMD debug command call event;

[0033] S4B7 After the callback function finishes execution, the command execution thread returns to the command daemon thread according to the user-defined error code rules; the command daemon thread fills the data according to the pre-defined CMD_EVENT_RET data format, writes the return value to the return pipe, and then the command thread exits; where CMD_EVENT_RET represents the CMD debug command return event;

[0034] S4B8, the debug command process blocked on the return pipe is awakened because there is data to read; the debug process reads the CMD_EVENT_RET return value from the return pipe, then returns it to the shell command of the Linux application, and finally exits.

[0035] As a preferred technical solution, step S4, registering the debug function, further includes the following steps:

[0036] For S4B9, if you forget the number of parameters and the meaning of each parameter in the specific debugging command during on-site debugging, you can use the `cmd_#modname-get` command to obtain help information for all custom debugging commands belonging to that Linux application. The `cmd_#modname-get` command will also redirect the application's standard output to the output of the current session process. If long-term stress testing is required, enable xshell logging or redirect debugging information to a custom log file to locate the problem by analyzing the log file. After debugging, turn off all debugging switches and call the `cmd_#modname-put` command to restore the main program's standard output. The help information is attached to the character pointer `infor` when the debugging command is registered and passed to the `cmd_main_thread` command daemon thread, ultimately stored in the callback mapping table. `cmd_#modname-get` represents the debugging command viewing command, `xshell` represents a secure terminal emulator, and `cmd_#modname-put` represents the debugging command restoration command. Long-term stress testing refers to on-site stress testing lasting more than 24 hours.

[0037] A Linux application field debugging system, used to implement the aforementioned Linux application field debugging method, includes the following modules connected in sequence:

[0038] Adding a module to cmd: This allows you to add the cmd module source code file to your Linux application project when writing Linux application code.

[0039] Initialization module: Used to call the cmd_init initialization function on the first line of execution of the main function of a Linux application, and initialize the debug interface public library of the Linux application;

[0040] Command daemon thread creation module: used to call phtread_create to create the cmd_main_thread command daemon thread; where phtread_create represents the Linux thread creation interface;

[0041] Debugging command registration module: Used to register debug variables and debug functions;

[0042] Debug command execution module: used to query and modify debug variables, as well as execute debug functions;

[0043] The debug command execution result return module is used to return the execution result of the debug command.

[0044] Compared with the prior art, the present invention has the following advantages:

[0045] (1) It does not interfere with the operation of the program itself during on-site debugging, does not affect the function of the program, meets the requirements of on-site debugging, and is creative;

[0046] (2) Lightweight: It only occupies very few system resources during on-site debugging, which can meet the almost demanding requirements of on-site debugging of embedded real-time applications without reducing program performance, and has novel and unique features.

[0047] (3) It is simple and easy to use, and can be seamlessly integrated with the system shell command. It is convenient to build simulation and simulation test scripts based on the application's own functions, which is helpful for stress testing and coverage testing. It has wide applicability.

[0048] (4) It can provide a general and unified on-site commissioning method with modularity, high cohesion and low coupling. It is universal and easy to use, and can improve the efficiency of project development and on-site commissioning. It is practical. Attached Figure Description

[0049] Figure 1 This is a schematic diagram illustrating the working principle of a field debugging method for Linux applications according to the present invention.

[0050] Figure 2 for Figure 1 One of the magnified views of a section;

[0051] Figure 3 for Figure 1 The second enlarged view of a section;

[0052] Figure 4 for Figure 1 The third enlarged view of a section;

[0053] Figure 5 for Figure 1 Part 4 of the enlarged view;

[0054] Figure 6 A schematic diagram of the data communication format for registering debug commands within a command pipeline;

[0055] Figure 7 A schematic diagram of the data communication format for calling debug commands within a command pipeline;

[0056] Figure 8 A schematic diagram of the data communication format for the return pipe;

[0057] Figure 9 This is a detailed schematic diagram illustrating the steps involved in on-site commissioning. Detailed Implementation

[0058] The present invention will be further described in detail below with reference to the embodiments and accompanying drawings, but the embodiments of the present invention are not limited thereto.

[0059] Example 1

[0060] like Figures 1 to 9 As shown, when debugging embedded real-time applications in the field, a lightweight method or tool is needed that does not interfere with program execution and can capture debugging information on-site. This invention discloses a debugging method for embedded Linux real-time applications that does not interfere with application execution or affect system functionality and performance.

[0061] First, this invention requires a custom-developed cmd module. For example... Figure 1 As shown, the functions within the thick dashed box are implemented by the cmd module, and the application itself runs continuously without ever exiting. The cmd module primarily handles three main functions: registering debug commands, executing debug commands, and returning the results of command execution. First, debug command registration must be completed after the initialization of the application's source code main function by calling cmd_init on the first line of execution. This is done by calling the cmd_reg_int and cmd_reg functions, where cmd_reg_int registers debug variables and cmd_reg registers debug functions. For easier on-the-spot debugging, the extended cmd_reg_int_ex and cmd_reg_ex functions are used for registration, passing a pointer to a string containing the usage instructions for the specified command. Second, debug command execution is handled by the debug command daemon thread, which reads the command and parameters from the command pipe and then creates a new command thread to execute them. Each application's debug command daemon thread is created by the cmd module and attached to the application's instance process. Finally, the result of the command execution is returned by the command thread to the command daemon thread, then returned to the debugging command process through the pipe corresponding to this debugging command, and finally returned to the system shell (shell refers to the bash shell or ash shell of the Linux system, etc.).

[0062] During application development, the cmd module source code file is added to the project. Then, in the first line of the application's main function, the provided cmd module initialization function `cmd_init` is called to register the application's module identifier. Next, the cmd module registration function is called, first registering debug variables, and then registering debug functions (essentially following the steps shown). Figure 6The communication format shown writes data to the command pipe. Then, debug variables (or other global variables) are declared using standard C language, and the specific content of the registered debug functions or other global functions is implemented. Debug variables are used to output debug information at critical nodes in the application's business logic using if(debug variable) conditional statements. Debug functions can add, delete, display, and replay entries in a critical data table or data structure; the specific implementation is left to the application developer to define.

[0063] After the application is compiled, it starts in the background in the Linux system shell script by adding the "&" symbol. The first line of the execution statement of the main function of each application calls the cmd module initialization function. The cmd module initialization function creates a debug command pipe in the " / tmp" directory according to the registered module identifier, following the rule of " / tmp / cmd_event_pipe_#modname" ("#" is the concatenation character). Then the cmd module starts registering debug variables and debug functions, and creates system shell commands corresponding to the debug variables or debug functions. It also creates a symbolic link in the / bin directory pointing to the absolute path of the current application, named "variable name or function name". Then the normal business process code of the application starts, and finally the main thread of the application waits in while(1), while the other code of the application runs normally.

[0064] During on-site debugging, it is preferable to log in to the serial or network port using xshell (xshell stands for Secure Terminal Simulator, a common serial or network port debugging tool). After successful login, in the Linux system shell environment, type a command in the form of "variable name or function name...". Since this debugging command symbolic link points to the executable file corresponding to the application, the application is restarted. However, this time, the cmd module, according to its own set mechanism, recognizes that this is not registering a debugging command but calling a debugging command, that is, starting a copy of the application. The debugging process (copy program) writes to the pipe " / tmp / cmd_event_pipe_#modname"... Figure 7The event data is presented in the communication format shown, where pid is the process ID of the application copy started by typing the command "debug variable name or debug function name". The debug command program then blocks on its newly created return pipe " / tmp / cmd_wait_pipe_#pid", waiting for the return value from the callback function of the main program. The cmd_main_thread command daemon in the application detects the debug command call event on the command pipe " / tmp / cmd_event_pipe_#modname", creates a new execution thread corresponding to its callback function, and executes the callback function. After receiving the return value from the execution thread, the cmd_main_thread command daemon proceeds as follows... Figure 8 The communication format shown is written to the return pipe. The debug command process, blocked on the return pipe, receives the return value, returns it to the Linux system shell, then destroys the temporarily created named pipe " / tmp / cmd_wait_pipe_#pid", and then exits.

[0065] like Figure 9 As shown, when an application encounters an exception and requires on-site debugging, you can use the Linux system shell command to type debugging commands (including debugging variables and functions). By viewing the real-time execution of important data structures and algorithm flows in the application, calling test routines, and analyzing debugging information or logs, you can achieve the purpose of on-site application debugging.

[0066] The main advantages of this invention compared to other Linux application debugging methods are:

[0067] 1) It facilitates on-site debugging without interfering with the normal operation of the program, especially in situations where real-time requirements are high and long-term burn-in observation is required.

[0068] 2) Lightweight on-site debugging method, which consumes very few system resources, does not affect the functionality of embedded real-time applications, and does not reduce the performance of program operation.

[0069] 3) Simple and easy to use, with seamless integration with system shell commands. They can call each other, facilitating the writing of application simulation and test scripts, and aiding in the localization and resolution of intermittent problems exposed only during stress testing.

[0070] 4) It provides a unified and universal debugging method for on-site debugging of business logic in various applications, which can improve the efficiency of project development.

[0071] Example 2

[0072] like Figures 1 to 9As shown, as a further optimization of Embodiment 1, this embodiment also includes the following technical features based on Embodiment 1:

[0073] To more clearly illustrate the working principle and technical features of the present invention, the implementation principle of the present invention will now be explained in more detail with reference to the accompanying drawings and the following embodiments.

[0074] First step, such as Figure 1 As shown, when writing the application code, the cmd module interface and implementation files cmd.h and cmd.c are added to the application project. Then, in the first line of the main function's execution statement, the cmd_init initialization function is called. The cmd_init initialization function mainly retrieves the program name, current working directory, startup parameters, and program PID (Program IDentity). If cmd finds that the pre-registered module name is already in use, it will fail; otherwise, it proceeds to the next step. Then, following the naming convention "cmd_event_pipe_#modname", a command pipe with the attributes O_CREAT|O_NONBLOCK is created in the / tmp directory of the Linux system shell, and its permissions are set to be readable and writable by the user, group, and others. Finally, the file descriptor corresponding to this pipe is opened using the open function.

[0075] The second step involves the `cmd_init` initialization function calling `phtread_create` to create the `cmd_main_thread` command daemon thread. The `cmd_main_thread` command daemon thread is implemented using a `while(1) { check if there is data to read in the command pipe}` loop and blocks on the command pipe corresponding to the application. After the main thread successfully creates the `cmd_main_thread` command daemon thread, it then registers debug variables and debug functions.

[0076] The registration of debugging variables is also done in several steps.

[0077] The first step is to define and declare global variables using the C language.

[0078] The second step involves registering the global variable as a debuggable variable for the cmd module by calling the `cmd_reg_int` or `cmd_reg_int_ex` function. `cmd_reg_int` and `cmd_reg_int_ex` directly convert the variable name to a function name and establish a mapping between the variable name and the background function by calling the `cmd_reg_ex` interface (essentially the same as registering debug functions). Simultaneously, the registered global variable name is passed as a parameter to `cmd_default_func_param_init` so that `cmd_default_func_param_init` can distinguish which debug variable is being processed when it is called. This function primarily registers entries for the global variable name. After the debug command (application copy) starts, it returns the value corresponding to the variable or passes the variable value to the application's global variable.

[0079] Next, we will register the debugging functions, which will be done in several steps.

[0080] The first step is to declare and implement the function body in the form of `int cmd_reg_func(char* cmd, int n, char* argv[])`. Here, `cmd` is a pointer to the system shell command name of the callback function. For example, if `cmd` points to "dis_route_table_show", then during debugging, you can directly type "dis_route_table_show" in the system shell and execute it. `n` represents the number of arguments passed when calling `dis_route_table_show`. Then, `argv` is a character pointer array, which is the actual string parameter passed. The implementation of the `cmd_reg_func` function body needs to call the `cmd_arg_to_num` function to perform operations such as converting the string to an integer before it is used by the debugging function.

[0081] The second step involves calling the `cmd_reg_ex` interface to register a mapping entry in the application's global debug commands / callback functions. `cmd_reg_ex` scans this table to check for existing debug commands with the same name; if found, it displays an error message. Otherwise, it proceeds with the registration. During registration, it first follows the format... Figure 6 The defined structure is populated with the corresponding fields, and the CMD_EVENT_REG event is written to the command pipeline. Figure 6 This demonstrates the data communication format between the main thread and the cmd_main_thread command daemon thread. The parameters are as follows: type: event type, here it is CMD_REG; cmd: pointer to the registered debug command character; mod: pointer to the module to which the command belongs; infor: pointer to the help information for using the command.

[0082] The third step involves the cmd_main_thread command daemon thread, which, upon being awakened by the command pipe, immediately registers the cmd commands, associating the debug command name, callback function, and callback parameters into a mapping table. Simultaneously, it creates symbolic links in the Linux system's / bin directory, such as / bin / dis_route_table_show, which point to the executable file corresponding to the current application, for example, / home / app / dis.out.

[0083] The fourth step involves cross-compiling the main program containing the cmd module to obtain an executable file, such as the executable program code file dis.out. The main program is then started in the background via a startup script or manually by adding the '&' symbol. Once started, it can be used for on-site debugging. For example, when the command "dis_route_table_show 1" is typed in the Linux shell, the system finds the executable file dis_route_table_show in the / bin directory, calls / bin / dis_route_table_show to execute it, and passes the parameters to it. Since / bin / dis_route_table_show is symbolically linked to " / home / app / dis.out", / home / app / dis.out is then started again with parameters (a copy startup).

[0084] Fifth, the copy program also calls the cmd_init code to execute, but this time cmd_init detects that it is a debug command call, which follows a different code path than the main program when it starts. The copy program recognizes the debug command call and proceeds accordingly. Figure 7 The structure format shown is used to fill the CMD_EVENT_CALL event write command pipe. After successful writing, it creates and blocks on the pipe / tmp / cmd_wait_pipe_#pid, waiting for the return value of the debug command after execution in the main program. Figure 7 This demonstrates the data communication format between the debug command and the cmd_main_thread command daemon thread. The parameters are defined as follows: type: event type, here it is CMD_CALL; cmd: pointer to the command character; pid: process PID corresponding to the debug command; argv: array of debug command parameter pointers; argc: number of debug command parameters.

[0085] In the sixth step, the main program's cmd_main_thread command daemon thread is woken up again on the command pipe and reads the CMD_EVENT_CALL event. According to... Figure 7Knowing the data communication format, the name of the debugging command, the corresponding callback function, and the passed callback parameters, a new command execution thread is created, and then the corresponding callback function is called to execute it.

[0086] Step 7: After the callback function finishes executing, the command thread returns to the command daemon thread according to the user-defined error code rules. The command daemon thread then follows... Figure 8 The CMD_EVENT_RET data format shown is filled with data, the return value is then written to the return pipe, and the command thread exits. Figure 8 The data communication format between the command thread and the debug command is demonstrated. The parameters are as follows: type: event type, which is CMD_RET in this case; cmd: pointer to the command character; pid: process PID corresponding to the debug command; ret: return value or error code of the debug command.

[0087] Step 8: The debug command process, blocked on the return pipe, is awakened because data is available to read. The debug process reads the CMD_EVENT_RET return value from the return pipe, then returns it to the Linux system shell, and finally exits. This achieves complete consistency between the implementation of debug commands and system commands, enabling seamless interaction.

[0088] Step 9, as Figure 9 As shown, if you forget the number of parameters for a specific debugging command and the meaning of each parameter during on-site debugging, you can use the command "cmd_#modname-get" to obtain help information for all custom debugging commands belonging to that module and pull the background output to the current session. The help information is attached to the character pointer `infor` passed to the `cmd_main_thread` command daemon thread when the debugging command is registered and is stored in the debugging command and callback function mapping table. This command also redirects the main program's standard output to the output of the current session process for easy observation of debugging information. If long-term stress testing is required, enable xshell logging or redirect debugging information to a custom log file to locate problems by analyzing the log file. After debugging is complete, you need to turn off all debugging switches and call the command "cmd_#modname-put" to restore the main program's standard output.

[0089] By following the steps above, you can read, write, and modify the values ​​of variables with the same name in the application in real time by typing commands in the system shell environment. If the variable is used as a print switch, a wealth of useful debugging information can be controlled by typing debugging commands. You can also generate live debugging information or log files through xshell or by redirection. This is extremely helpful for resolving system or network problems that require long-term and continuous system and performance testing to discover.

[0090] Typing callback commands in the system shell environment executes the corresponding callback functions in the application in real time. These callback functions can perform common operations such as adding, deleting, modifying, displaying, and rereading entries. For example, it can display the routing table status on the board in real time. When a hardware routing error occurs, it can determine whether the problem lies in the routing error or a problem with the hardware forwarding logic by rereading the hardware and software entries to see if they match. Furthermore, because the cmd module seamlessly integrates with the system shell, it facilitates the simulation of complex system and network problems by building simulation test scripts based on the application's business logic, allowing for the analysis and localization of occasional problems in complex environments. For instance, during the debugging of the routing table entry management algorithm program dis.out, the simulation test script dis_test.sh, written in conjunction with the cmd implementation mechanism, located and resolved the vulnerability of the TCAM routing table entry management algorithm under high-frequency, large-scale addition and deletion of routes.

[0091] Since the execution of debugging commands does not require pausing the original business process of the application or interfering with the execution of normal functions, but only extracts the corresponding debugging information to analyze the problem, debugging does not affect the original functions and performance of the system.

[0092] As described above, the present invention can be implemented well.

[0093] All features disclosed in all embodiments of this specification, or steps in all methods or processes implied in the disclosure, may be combined and / or extended or replaced in any way, except for mutually exclusive features and / or steps.

[0094] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Based on the technical essence of the present invention, any simple modifications, equivalent substitutions, and improvements made to the above embodiments within the spirit and principles of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A method of live debugging of a Linux application, characterized in that, When a Linux application needs to be debugged on-site, type the debug command in the Linux application's shell command line to perform the following operations: view the data structure content and real-time execution of program steps in the application, call test routines, and analyze debug information or logs, thereby achieving on-site debugging of the Linux application. The cmd module is used to operate debugging commands; where cmd module represents the public library module for debugging interfaces. The cmd module is used for registering debugging commands, executing debugging commands, and returning the results of debugging command execution; the cmd module follows these rules: A. Debugging command registration must be completed by calling `cmd_reg_int` and `cmd_reg` after the first line of the `main` function in the Linux application source code has been initialized. For easier on-the-spot debugging, the extended `cmd_reg_int_ex` and `cmd_reg_ex` should be called for registration, passing a pointer to a string containing the usage instructions for the command. Here, `main` represents the main function of the Linux application; `cmd_init` represents the debug interface public library initialization function; `cmd_reg_int` represents the debug variable registration interface, responsible for registering debug variables; `cmd_reg` represents the debug function registration interface, responsible for registering debug functions; and `cmd_reg_int_ex` represents the debug variable extension registration interface, and `cmd_reg_ex` represents the debug function extension registration interface. B. The execution of debug commands is carried out by the debug command daemon thread reading the commands and parameters from the command pipe and then creating a new command thread to execute them; among them, the debug command daemon thread of each application is created by the cmd module and attached to the instance process of the application; C. The result of command execution is returned by the command thread to the command daemon thread, then returned to the debugging command process through a pipe corresponding to the PID of the current debugging command process, and finally returned to the shell of the Linux system; where shell refers to the shell program.

2. The method for on-site debugging of Linux application according to claim 1, wherein, Includes the following steps: S1, cmd added: When writing Linux application code, add the cmd module source code file to the Linux application project; S2, Initialization: In the first line of execution of the main function of the Linux application, the cmd_init initialization function is called to initialize the debug interface public library of the Linux application; S3, Command daemon thread creation: Call phtread_create to create the cmd_main_thread command daemon thread; where phtread_create represents the Linux thread creation interface; S4, Debug command registration: Register debug variables and debug functions; S5, Debug command execution: Query and modify debug variables, and execute debug functions; S6, Return of debug command execution result: Returns the result of debug command execution.

3. The method for on-site debugging of a Linux application according to claim 2, characterized in that, In step S2, the cmd_init initialization function mainly completes one or more of the following: program name, current working directory, startup parameters, and program PID.

4. The method for on-site debugging of a Linux application according to claim 3, characterized in that, In step S3, the cmd_main_thread command daemon is implemented by using the code while (1) {check if there is data to read in the command pipe}. The cmd_main_thread command daemon is blocked on the command pipe of the Linux application.

5. The method for on-site debugging of a Linux application according to claim 4, characterized in that, In step S4, registering debug variables includes the following steps: S4A1 defines and declares global variables using the C language; S4A2, calling cmd_reg_int or cmd_reg_int_ex registers global variables as debuggable variables for the cmd module: cmd_reg_int or cmd_reg_int_ex directly converts the variable name to a function name and calls the cmd_reg_ex interface to establish a mapping relationship between the variable name and the background function. At the same time, the registered global variable name is passed as a parameter to cmd_default_func_param_init. cmd_default_func_param_init mainly implements the registration of global variable name entries. Among them, cmd_reg_int represents the debug variable registration interface, cmd_reg_int_ex represents the debug variable extension registration interface, cmd_reg_ex represents the debug function extension registration interface, and cmd_default_func_param_init represents the debug variable to debug function conversion interface. With S4A3, typing "variable_name" in the Linux shell will return the value of the debug variable with the same name in the application; typing "variable_name_set_value" in the Linux shell will pass the set value to the debug variable with the same name in the application.

6. The method for on-site debugging of a Linux application according to claim 4, characterized in that, In step S4, registering the debug function includes the following steps: S4B1, declares and implements the function body; S4B2 calls the cmd_reg or cmd_reg_ex interface to register debug commands in the application. Each debug command corresponds to a registered debug function, and all debug commands eventually form a callback map. Then, cmd_reg_ex scans this callback map to determine if a debug command with the same name exists. If it does, an error is displayed; otherwise, the debug command registration process is performed. During registration, the corresponding fields are filled according to the structure of the CMD_EVENT_REG event and written to the command pipeline. Here, cmd_reg represents the debug function registration interface, cmd_reg_ex represents the debug function extension registration interface, and CMD_EVENT_REG represents the CMD debug command registration event. S4B3, the cmd_main_thread command daemon thread blocked in the command pipe is awakened, and then the cmd command registration work is performed, associating the debug command, callback function, and callback parameters to form a callback mapping table entry; at the same time, a symbolic link with the same name as the debug command is created in the / bin directory of the Linux application, and this symbolic link points to the executable file corresponding to the current Linux application; where / bin represents the default directory of the file system where executable files are stored. S4B4 is a Linux application containing a cmd module that is cross-compiled to obtain an executable file; then the executable file is started in the background with an "&" symbol added, and on-site debugging is performed after it starts. S4B5: When a debug command is typed in the Linux shell, a copy of the Linux application starts. The copy calls the cmd_init code to execute. The copy recognizes that it is a debug command call and fills the CMD_EVENT_CALL event according to a pre-defined structure format and writes it to the command pipe. After successful writing, the copy creates a named pipe and blocks on the named pipe, waiting for the return value of the debug command after execution by the main program. Here, cmd_init represents the debug interface initialization function. S4B6, when the main program's cmd_main_thread command daemon reads the CMD_EVENT_CALL event on the command pipe, it creates a new command execution thread according to the pre-defined data communication format and then calls the corresponding callback function to execute; where CMD_EVENT_CALL represents the CMD debug command call event; S4B7 After the callback function finishes execution, the command execution thread returns to the command daemon thread according to the user-defined error code rules; the command daemon thread fills the data according to the pre-defined CMD_EVENT_RET data format, writes the return value to the return pipe, and then the command thread exits; where CMD_EVENT_RET represents the CMD debug command return event; S4B8, the debug command process blocked on the return pipe is awakened because there is data to read; the debug process reads the CMD_EVENT_RET return value from the return pipe, then returns it to the shell command of the Linux application, and finally exits.

7. The method for on-site debugging of a Linux application according to claim 6, characterized in that, In step S4, registering the debug function also includes the following steps: For S4B9, if you forget the number of parameters and the meaning of each parameter in the specific debugging command during on-site debugging, you can use the command `cmd_#modname -get` to obtain help information for all custom debugging commands belonging to that Linux application. The `cmd_#modname -get` command will also redirect the application's standard output to the output of the current session process. If long-term stress testing is required, enable xshell logging or redirect debugging information to a custom log file to locate the problem by analyzing the log file. After debugging, turn off all debugging switches and call the command `cmd_#modname -put` to restore the main program's standard output. The help information is attached to the character pointer `infor` when the debugging command is registered and passed to the `cmd_main_thread` command daemon thread, ultimately stored in the callback mapping table. `cmd_#modname -get` represents the debug command viewing command, `xshell` represents the secure terminal emulator, and `cmd_#modname -put` represents the debug command restoration command. Long-term stress testing refers to on-site stress testing lasting more than 24 hours.

8. A field debugging system for Linux applications, characterized in that, A method for on-site debugging of a Linux application as described in any one of claims 1 to 7, comprising the following modules connected in sequence: Adding a module to cmd: This allows you to add the cmd module source code file to your Linux application project when writing Linux application code. Initialization module: Used to call the cmd_init initialization function on the first line of execution of the main function of a Linux application, and initialize the debug interface public library of the Linux application; Command daemon thread creation module: used to call phtread_create to create the cmd_main_thread command daemon thread; where phtread_create represents the Linux thread creation interface; Debugging command registration module: Used to register debug variables and debug functions; Debug command execution module: used to query and modify debug variables, as well as execute debug functions; The debug command execution result return module is used to return the execution result of the debug command.

Images