CN120892315A

CN120892315A - A program debugging method and system

Info

Publication number: CN120892315A
Application number: CN202410534220.6A
Authority: CN
Inventors: 请求不公布姓名
Original assignee: Guangzhou Kaile Software Technology Co ltd
Current assignee: Guangzhou Kaile Software Technology Co ltd
Priority date: 2024-04-30
Filing date: 2024-04-30
Publication date: 2025-11-04

Abstract

The invention discloses a program debugging method and a system, wherein the program debugging method comprises an analysis step, a variable information storage step, an output step, a breakpoint step, an interruption step, a recovery step, an insertion step and an execution step. The invention breaks through the convention and thinking inertia of the prior debugging technology, and can be used for realizing a universal debugging tool. According to the other technical scheme provided by the invention, the debugging data of the public or superior function is automatically stored and processed into the debugging cases and the testing cases, so that the automatic generation of the high-quality debugging cases and the testing cases is realized.

Description

Program debugging method and system

Technical Field

The present invention relates to the field of computer program debugging technology, and in particular, to a general debugging method and apparatus.

Background

Program debugging (debug), which is an indispensable work in the software development process, is often used in a breakpoint debugging mode, i.e., a breakpoint is set, and when a program is executed to a breakpoint position, the program is interrupted and the value of a related variable is displayed. By observing the values of the variables, the behavior of the program can be known, whether an error exists or not can be judged, and the cause of the error can be found.

The user of the debugger may pre-specify the location of breakpoints, such as a break in a line of a file, the number of breakpoints typically being unlimited. The user can also send instructions such as "walk in (execute to next line, enter and interrupt when meeting function call)", "walk over (execute to next line, skip when meeting function call)", "execute to line where cursor is located", and the like in the debugging process, and the debugging tool temporarily sets a breakpoint according to the instructions.

The implementation of breakpoints is divided into software breakpoints and hardware breakpoints. The software breakpoint is interrupted by inserting a special breakpoint instruction into a designated code position, and the hardware breakpoint is realized by utilizing a debugging register of the CPU, so that the debugging of a general application program is mainly realized by the software breakpoint.

The breakpoint instructions may be different in different software and hardware architectures, for example, the X86 series, and the software breakpoint operating principle is that the debugger stores the first byte of the original instruction at the corresponding position of the code, and then writes an INT3 instruction. The binary code of the INT3 instruction is 11001100b (0 xCC), which has only one byte, so only one byte needs to be saved and restored when the breakpoint is set and canceled. When the CPU executes the INT3 instruction, the soft interrupt of the operating system is triggered, the current process is stopped, and the interrupt processing function defined by the kernel is executed. The hardware breakpoint of X86 uses DR0-DR7 debug address registers, but only 4 breakpoints can be set due to the limited number of registers storing breakpoint addresses (DR 0-DR 3). The breakpoint implementation based on ARM series is similar to the X86 platform, the working principle of software breakpoint is that the instruction is replaced by the operation code of HLT or BRK instruction, the hardware breakpoint uses a comparator built in the core, and when the execution reaches the designated address, the execution is stopped and the corresponding interrupt is triggered, and as in X86, the breakpoint setting quantity limit exists because only a limited quantity of hardware breakpoint units are provided.

The operation after the breakpoint is triggered, taking an X86 platform as an example, a corresponding function triggered by the soft interrupt of the operating system of the Windows platform is KiTrap (), and the Linux platform is a do_int3 () function, which are all interrupt processing routines predefined by the kernel of the operating system. KiTrap03 () distributes the breakpoint exception to the debugger in user mode in the form of debug event through the debug subsystem, and waits for the reply of the debugger, and only after the debugger confirms that the exception is the breakpoint set by "oneself", the debugger is allowed to suspend the debugged process for interactive debugging. The do_int3 () routine sends a SIGTRAP signal to the debugged process, and when the process receives SIGTRAP signal, the current process gives up the CPU to halt operation.

The general working procedure of the debugger of the Windows platform is that after the debugger is started, a process to be debugged is firstly created through a CreateProcess function, or the debugger is bound to the running process through calling DebugActiveProcess functions, a debugging circulation stage is started after a series of preparation operations, the debugger can block and call WaitForDebugEvent functions to wait for debugging EVENT notification, when an abnormal EVENT or dll file loading and unloading EVENT notification arrives, the function returns immediately, the returned EVENT information is packaged in a DEBUG_EVENT structure, and the structure comprises the type of the EVENT, related process description information, file handles and the like. At this time, the debugger enters a command interaction stage, the debugger matches events in a custom event processing function ProcessEvent and executes callback codes of the corresponding events, if the events are breakpoint trigger type operations, all threads of the debugged target process are suspended by the operating system, and at this time, the debugger can call related functions such as GetThreadContext to acquire context information of the appointed threads.

In the general working process of a debugger of a Linux platform, taking GDB as an example, when GDB command debugging is carried out on a compiled C/C++ program file from a shell terminal, a GDB process (debugger process) is firstly created by a system, a subprocess (debugging target process) is formed by the process, a key system function ptrace is firstly called after the subprocess is initialized to enable the subprocess to enter a tracked mode, a execv function is called to execute the C program file to be debugged, at the moment, the running of the current process is suspended, and a SIGCHLD signal is sent to a father process, and the debugged process can be debugged after the father process receives the SIGCHLD signal. The ptrace system function is a core dependent function of the GDB interactive debugging, and a first parameter request of the function determines operation modes to be executed, and the operation modes define the behaviors of a debugger for controlling read-write debugged processes. With the powerful functions of ptrace functions, the GDB debugger process can read and write the values of instruction space, data space, stack and registers of the debugging target process, such as stack printing, variable exhibition modification and the like. The GDB can intercept almost all signals notified to the debugged process by the kernel, and the debugger process can perform operations such as breakpoint matching, single step debugging and the like on the program through interception and judgment of the signals.

The above is just the basic debugger operating principle. To enable the debugger to work properly, two types of data, position mapping data and sign data, are relied on. The system comprises a plurality of executable files, position mapping data used for inquiring which byte of an executable file of a debugged program is provided with a debugging instruction when a certain line is interrupted, symbol data used for acquiring information (type, name, address and the like) of variables to be output when the line is interrupted, wherein the two data are usually generated by a compiler in a compiling process and are generally in private formats, the two file formats generated by different compilers are different, the two files generated by different versions of the same compiler are also different in format, and an external program hardly uses the two files.

It can be seen that the current common debugger is closely related to a hardware platform, an operating system and a compiler, if the common debugger is to be developed, for example, a unit test tool supporting windows, linux and various development environments under an embedded system is to realize that all testable projects support debugging, if the current debugging technology is based, two modes can be used, namely, the debugger integrating various development environments, and the debugger can be automatically developed for each development environment by acquiring debugging resources (at least needing position mapping data and symbol data) generated by various development environments. Either way, a huge amount of work is required and even no feasibility is achieved.

In view of the foregoing, a new program debugging technical solution that is not based on the existing debugging technology is needed to implement a universal debugging tool.

On the other hand, the traditional debugging mode has three defects that the direct driving is lacked, the data management is lacked, and the debugging integration is difficult to realize.

In a conventional debugging process, a debugger usually starts a debugged process, the debugged process starts to execute according to the function of the debugged process from an entry function (such as a main function of c/c++), or starts a user interface, a user runs a function, and the process is executed to a breakpoint and is interrupted according to a normal execution flow. For example, a function F may have its call path such that main function- > function A- > function B- > function C- > function D- > function E- > function F. This way of working has two major advantages, namely, no extra driver is needed (driver refers to code which calls the debugged function and enables the debugged function to be executed), other existing code in the project acts as a driver (called indirect driver), and common debug data can be used. In the above example, the debug data required by the functions a to F are usually not prepared separately, but transferred by the caller, that is, the common debug data is used, and transferred to the lower-level function after being processed by the upper-level function. But following the advantages, the disadvantages generally correspond:

One is the lack of direct drive. To debug the function F, data cannot be set directly, for example, the function F has a parameter P, which is an object pointer linked list, and when debugging, the value of the function F needs to include some specific object pointers, because the driving is indirect driving, the function F cannot set directly the data of the parameter P (some debuggers can directly modify the value of a simple variable, but cannot deal with complex situations, for example, adding a new object pointer to the linked list), only by means of interception, a breakpoint is added to the function entry, and whether the transferred data meets the requirement is repeatedly checked until the proper data is intercepted, so that debugging can be started. Of course, conditional break points can be used to automatically intercept data conforming to conditions, but the conditional break points are troublesome to set, complex scenes can not be supported, and the method is generally used only under the condition of difficult interception.

And secondly, lack of data management. Since each debugged function does not possess private debug data, but rather multiple functions (potentially thousands of functions for large projects) use public debug data, for a function, its debug data lacks an efficient management approach, e.g., taking several minutes to intercept the appropriate debug data, and the data is lost as soon as the debugger is turned off, and the next debug is intercepted again.

Thirdly, the adjustment and measurement integration is difficult to realize. For the function F, the input data required for debugging is universal with the input data required for unit testing, and before the debugging is finished, if the program is confirmed to be normal in function, the result data is stored, namely the expected output required for unit testing. If the debugging integration is realized, the debugging input and the result are saved, namely the unit test case, the repeated labor is greatly reduced, and the efficiency of the unit test is remarkably improved.

To solve the above three drawbacks, a program debugging technical scheme is needed that provides direct driving, can save and manage debugging data, and shares the debugging data with unit testing data.

On the other hand, the automatic generation of the software unit test cases is a main way for reducing the unit test cost, and the generation technology commonly used at present generally analyzes and generates the generated data from the structural aspect of the tested code, so that the generated data is often low in quality. If the debug data can be converted into the unit test data, high-quality unit test cases can be generated, so that a technical scheme for automatically generating the high-quality unit test cases by using the debug data is needed.

Disclosure of Invention

Aiming at the defects of the prior art, the invention provides a program debugging method and device.

In order to solve the technical problems, the technical scheme provided by the invention is that the program debugging method is characterized by comprising the following steps:

analyzing the debugged code to obtain debugged function information, definition information of data type, variable information storage point and observation point, wherein the observation point is the position of the code capable of being inserted into the calling interrupt step;

a variable information storage step of storing variable information of the debugged function;

outputting the value of the variable of the debugged function;

A breakpoint step of automatically or manually designating the observation point and/or the observation point range to be interrupted;

An interruption step, namely detecting whether the observation point is interrupted or not, if so, calling the output step, and suspending executing the debugged code;

a restoring step of restoring execution of the debugged code;

Inserting codes for calling the interrupting step into the observing point, and inserting codes for calling the variable information saving step into the variable information saving point;

and executing the step of compiling and executing the debugged code after the plug-in.

The improved technical scheme is also provided, and the method comprises the following steps:

a drive generation step of generating a drive code capable of directly calling the debugged function;

An entry specifying step of specifying one or more debug entry functions;

a code replacement step of masking or replacing a special code of the embedded item with a code supported by a host compiler and/or replacing a number representing a memory address with a pointer;

and a remote communication step, namely, communicating when the debugged program is executed on other computers.

And storing output data, wherein the output data refers to the value of a variable of the debugged function.

Another technical solution is also provided for generating a test case and a test case, including:

The breakpoint step, the interruption step and the recovery step are replaced by automatic output steps, namely, the output steps are automatically called at the inlet and the outlet of each debugged function.

May further include:

And the use case generating step is to store the output data generated at the function inlet as the input of the use case and the output data generated at the function outlet as the output of the use case.

A duplicate removal step of comparing the input of the use cases and deleting the duplicate use cases;

And a screening step, namely executing the use cases, counting the coverage state, and deleting the use cases which cannot increase the coverage rate.

And a confirmation step of finding out an approximate use case for the to-be-confirmed use case and listing the data difference of the approximate use case and the to-be-confirmed use case, wherein the approximate use case refers to the use case with the smallest input difference or the smallest coverage difference with the to-be-confirmed use case.

In addition, the other technical scheme provided by the invention is that the program debugging system is characterized by comprising the following components:

The analysis device is used for analyzing the debugged code to obtain debugged function information, definition information of data types, a variable information storage point and an observation point, wherein the observation point refers to a position of the code which can be inserted into the calling interrupt device;

Variable information storage means for storing variable information of the debugged function;

output means for outputting the value of the variable of the debugged function;

The breakpoint device is used for automatically or manually designating the observation point and/or the observation point range to be interrupted;

an interrupt device for detecting whether the observation point should be interrupted, if yes, calling the output device, and suspending executing the debugged code;

restoring means for restoring execution of the debugged code;

Inserting codes for calling the interrupt device into the observation point, and inserting codes for calling the variable information storage device into the variable information storage point;

And the execution device compiles and executes the debugged code after the plug-in.

May further include:

the breakpoint device, the interrupt device and the recovery device are replaced by automatic output devices, namely the output devices are automatically called at the inlet and the outlet of each debugged function.

And a use case generating device for storing the output data generated at the function entry as the input of the use case and storing the output data generated at the function exit as the output of the use case.

The duplicate removal device compares the input of the use cases and removes the duplicate use cases;

And the screening device is used for executing the use cases, counting the coverage state and deleting the use cases which cannot increase the coverage rate.

And the confirming device is used for finding out an approximate use case for the to-be-confirmed use case and listing the data difference of the approximate use case and the to-be-confirmed use case, wherein the approximate use case refers to the use case with the smallest input difference or the smallest coverage difference with the to-be-confirmed use case.

The program debugging method and system provided by the invention break through the convention and thinking inertia of the existing debugging technology, and can be used for realizing a universal debugging tool. The improved technical scheme of the invention realizes the requirements of providing direct drive, saving and managing the debugging data and sharing the debugging data and the unit testing data, can greatly reduce repeated labor and remarkably improve the efficiency and quality of soft development. According to the other technical scheme provided by the invention, the debugging data of the public or superior function is automatically stored and processed into the debugging cases and the testing cases, so that the automatic generation of the high-quality debugging cases and the testing cases is realized.

Drawings

The following describes the embodiments of the present invention in further detail with reference to the accompanying drawings:

FIG. 1 is a schematic diagram of the general construction of a basic embodiment of a program debugging method of the present invention;

FIG. 2 is a schematic diagram showing the general configuration of another embodiment of a program debugging method according to the present invention.

Detailed Description

The terms used in the embodiments of the present invention are terms of C language or c++ language, and the schematic code is written in C language or c++ language, which does not represent that the present invention is applicable to only C language and c++ language, and does not represent a limitation of the present invention. The schematic code is only for explaining the idea of the embodiment, and is not necessarily an implementation way, but rather represents a limitation of the embodiment of the present invention.

FIG. 1 is a schematic diagram showing the general constitution of a basic embodiment of the present invention, and as shown in FIG. 1, the present embodiment includes a parsing step 101, a variable information saving step 102, an outputting step 103, a breakpoint step 104, an interrupting step 105, a restoring step 106, an inserting step 107, and an executing step 108, wherein

And a step 101 of analyzing the debugged code to obtain debugged function information, definition information of data types, variable information storage points and observation points, wherein the observation points refer to positions capable of calling interrupt steps.

The first type of information to be obtained in the parsing step is debugged function information. A function, also called a procedure, is the smallest unit of code that can be executed. The debugged function refers to a function which may need to be debugged, and the function information is a general term in the field and refers to various attributes, identifications and contents of the function, including function names, belonging classes or namespaces, implementation codes, types and names of variables and the like. Variables, which may need to be observed when debugging the debugged function, include return values, parameters, member variables, global variables, local variables, and the like. Some of these items, and possibly some functions, do not. In addition, each function that may need to be debugged may be assigned a unique identifier in a variety of forms, such as a complete function declaration (naturally occurring, without assignment), a CRC value, a string of characters, a numeric number, and the like. A simpler way is a numerical numbering. The present embodiment uses a numeric number as a function identifier, increases from 1, and is represented by fid, i.e., each debugged function is identified by fid=n (when N >0, a certain function is represented, and when n=0, all functions are represented).

The second type of information that needs to be acquired in the parsing step is definition information of the data type. Type definition information, or type information, is a common term in the art, different programming languages, and type information may be somewhat different, and generally, the type information includes a type name, a memory size, a member name of each member, a type name, and an offset. The following is one example of a data structure for describing type information:

For describing one member, wherein type is the type of the member, name is the name of the member, and offset is the offset of the member.

For describing a type, where type is the type name, size is the memory size of the instance of the type, childCount is the number of members, pChilds is the member pointer array. When used for the base type childCount is 0 and pchilds is NULL. Of course, childCount and pChilds may be used instead of one linked list or similar sets.

The type definition information is mainly used for outputting variable values in the present embodiment. The value of the variable is to be output, and besides the address of the variable is to be obtained, the type of the variable and definition information of the type (at least the length of the data is to be known) are also known, so that the value of the variable can be resolved and output.

The third type of information to be obtained in the analyzing step is a variable information preservation point. Variables are variables that may need to be observed when debugging a debuggee function. Variable information refers to information to be used when outputting variable values, such as types, names and addresses of variables, wherein address information is generally obtained by an address fetching operator. The scope of the variable can be used as a preservation point of the variable information, but the most reasonable choice is to preserve the variable information when the address of the variable is determinable, so that the output step can output the value of the variable in time. The following is an example:

The above s1 to s5 are all possible save points, in which the member variable can save the this pointer (in the above example, the type is CType x), and in the output step, the member variable pointed to by the this pointer is output separately. As for global variables, one or more function save member variable information may be written or generated to reduce unnecessary repetition code. The save point is a position where the instrumentation step inserts the code that invokes the variable information save step, and therefore cannot be located inside the code line, and it is ensured that no compiling error occurs when the code is inserted, and the function of the code is not changed.

The fourth type of information to be obtained in the parsing step is an observation point. The viewpoint refers to the location where the interrupt step can be invoked. When the viewpoint calls the interrupt step, the interrupt step judges whether the debuggee program is allowed to suspend execution. For example, the following debuggee programs:

The v1 to v6 positions are all possible observation points. The vnot position cannot be used as a viewpoint. A viable observation point requires that no compilation errors can occur after code insertion and that the functionality of the codebook cannot be affected. Reasonable observation points include:

1) The beginning of the valid code line is divided into natural line and grammar line, the natural line is divided by line changing symbol, the grammar line is divided by grammar symbol, such as C/C++ dividing grammar line by division number (;). Either the natural line or the grammar line may be used, and if the natural line is used, it is necessary to deal with the situation that one grammar line occupies a plurality of natural lines, and the observation point cannot be set inside one grammar line (the breakpoint of the conventional compiler cannot be set inside one grammar line). The valid code lines do not include comment lines, blank lines.

2) Inlet and Outlet of a function, there may be multiple outlets for a function, in the previous example, v5 and v6 were both function outlets.

To record and use the points of view it is common practice to assign a unique identification to each point of view, for example, a numerical number may be used, or a character string may be used to name each point of view, generally the numerical number is simpler, in this embodiment a numerical number is used and denoted by vid, increasing from 1 and 0 denoting the unlimited point of view. The identifier may be global or class-based, and the convenient choice is based on functions, for example, each function has a function number fid, and the observation point of each function is a number vid increasing from 1, that is, vid=m (when M >0, a certain observation point is represented, and when m=0, an unlimited observation point is represented), so that the unique identification of the observation point may be expressed by adding the function number to the observation point number. In this way, it is also convenient to express the range of the observation point, for example:

fid=1, vid=2, and may represent the 2 nd viewpoint in the function numbered 1;

fid=1, vid=0, and can represent all points of view in the function numbered 1;

fid=0, vid=0, and may represent all points of view of all functions.

The above is information to be acquired in the parsing step. Specific parsing process, different programming languages, taking C/C++ language as an example, the parsing process generally has the following steps:

1. Pretreatment:

1) All #definitions are deleted and all macro definitions are expanded.

2) All conditional precompiled instructions are processed, such as #if, # ifdef, # elif, # else, # endif, etc.

3) And processing the #include pre-compiling instruction, and directly inserting the contained file into the position of the pre-compiling instruction.

4) All annotations are deleted.

5) The line number and the file identification are added so as to generate the line number for the debugging and the line number for the error warning of the compiling at the compiling time.

2. Analyzing:

1) Lexical analysis the scanner breaks the character sequence of the source into a series of tokens (Token).

2) Syntax analysis the parser parses the token series to produce a Syntax Tree (syncax Tree).

3) Semantic analysis, namely performing static semantic analysis and dynamic semantic analysis. Static semantics are semantics that can be determined at compile time, and dynamic semantics are semantics that can be determined at run time.

After the grammar analysis and the semantic analysis are completed, the required information can be extracted. The specific parsing process is prior art in the art and is not described in detail.

And a variable information saving step 102 for saving the variable information of the debugged function. The variable information generally includes type, name, address information of the variable. This step is relatively simple, and a structure can be used to store information of a variable, a linked list or other collection type is used to store information of all variables in a function, and a linked list or other collection type is used to store information of all variables in a function. The external interface of the variable information holding step 102 may be declared as a function similar to the following:

void debug_variable_info(const char*type,const char*name,void*addr);

Parameter type, type of transfer variable, parameter name, name of transfer variable, parameter addr, address of transfer variable. Of course, some parameters may be added, such as the class of the transfer variable (parameters/member variables/local variables, etc.), the number of the transfer variable, etc.

The specific implementation is prior art in the art and is not described in detail.

An output step 103 of outputting the value of the variable of the debugged function. The outputting step 103 may be implemented as a function, the declaration of which is illustrated as follows:

void debug_output(int fid,BOOL input);

The first parameter is a function number, the second parameter is used for prompting whether the output is the output, and when the output is the FALSE, the output is indicated, and only the output is set to the FALSE when the call is made at the function outlet.

The function to be implemented is to output the value of each variable by traversing the variable information of the function stored in the fid found variable information storing step 102. The output mode may be various, for example, save to a file, transfer through a pipeline, transfer through a shared memory, transfer through a message queue, etc., as long as the debugging tool can obtain the value of the variable. There are also a variety of output forms, for example, the memory content is output directly according to the address of the variable, which is a relatively simple way but has poor readability. A better output mode is to output data in a format similar to that of a more friendly traditional debugger (such as Visual Studio), and the data comprises information such as variable names, types, values and the like. For complex types, it is necessary to traverse its members one level by one level, outputting the value of each member. The specific implementation is prior art in the art and is not described in detail.

And a breakpoint step 104, automatically or manually designating the observation point and/or the observation point range to be interrupted. A breakpoint, in an embodiment of the present invention, refers to a viewpoint and/or a viewpoint range that needs to be interrupted. The breakpoint step 104 is responsible for automatically setting or manually designating a breakpoint. The specific setting method of the breakpoint is related to the recording and expression method of the viewpoint, and here, the breakpoint is expressed by using the method of jointly representing the viewpoint and the viewpoint range by fid and vid described in the description of the viewpoint in the analyzing step 101.

If no breakpoint is manually specified, nor is it automatically specified, then the debugged code will execute in the normal path without interruption anywhere, which would not enable the debug function.

Some scenarios require automatic breakpoint setting, for example, for c++ code, a global variable may be initialized before an entry function (e.g., main function) is called, the initialization process may call a constructor, and the constructor may call other functions, if there is an error (e.g., crash) in the process, before the crash location is unknown, it is difficult to set the breakpoint, where the breakpoint range may be set to all the observation points, i.e., each observation point should be interrupted, which is equivalent to automatically setting each observation point as a breakpoint, and when the first called constructor is executed, the debugged code may be interrupted. Automatically designating an interrupt at any viewpoint, both fid and vid may be set to 0.

Another scenario of automatically setting a breakpoint is to automatically set the breakpoint to be interrupted at the entry of the debugged function when the debugged function is started, so that the user does not need to preset the breakpoint. Fid may be set to the number of the function to be debugged and vid may be set to 1. A better way of setting is that fid is set to the number of the function to be debugged, and vid is set to 0, indicating that the interrupt is at any observation point of the current function.

The observation point to be interrupted is preset, and the observation point to be interrupted can be preset in advance similarly to the traditional debugger. The method is to directly record one or more observation points preset by a user, and the expression modes are usually specific function numbers and observation point numbers of fid and vid, namely numbers larger than 0.

The following scenes are that in the debugging process, in an interrupt state, a user sends out an instruction to designate the next breakpoint:

and step in, namely executing to the next line, and entering and interrupting when encountering a function call. Both fid and vid may be set to 0, i.e. any viewpoint interrupt is encountered, such that when no function call is encountered, the next viewpoint interrupt to the function is executed, and if a function call is encountered, the viewpoint interrupt to which the first one of the functions of the first call is executed.

And executing to the next line, and encountering a function call, wherein the function call is just a normal call and is not interrupted by the called function. Fid may be set to the number of the current function and vid to 0, i.e. the next viewpoint interrupt to the current function is performed.

Jumping out, namely jumping out of the current function, returning to the upper function, and setting fid as the number of the upper function and vid as 0. I.e. the execution is interrupted to any viewpoint of the last function.

Executing to a designated row, wherein the user directly designates the observation point to be interrupted. The observation point mark can be displayed on the user interface, the user can click the mark to specify the observation point to be interrupted, or the observation point mark can not be displayed, the user clicks the code line, and the observation point of the line or the nearest line is found out to serve as the observation point to be interrupted according to the observation point record obtained in the analysis step. In this case, as with the preset viewpoint, both fid and vid are numbers greater than 0.

Executing until interrupted, namely executing the tested code until the observation point which is supposed to be interrupted is encountered.

In the above cases, after setting the breakpoint, the resume step 106 is typically called to resume execution from the last breakpoint, execute to the new breakpoint, and interrupt.

And an interruption step 105, wherein whether the observation point is interrupted is detected, if so, the output step is called, and the execution of the debugged code is paused. The interrupt step is typically invoked when a viewpoint is executed, the function being to detect if the viewpoint should be interrupted, and if so, invoke the output step to output the value of the variable and halt execution of the code under test until execution resumes by resume step 106.

The interrupting step 105 may be implemented as a set of functions, the following being a simple implementation example of a core function:

The parameters of the function are three:

int fid, function numbering;

int vid, viewpoint number;

BOOL input, whether it is an input, is set to FALSE only when the function is called at the function exit, and should be set to TRUE. This parameter is used to indicate whether output data is to be saved as input or output of a debug or test case, and is used in a modified embodiment, which is not used.

Line 1 calls an interrupt query function debug_query_break to query whether the current breakpoint should be interrupted, if so, calls the value of the debug_output () function output variable of the output step, and calls debug_pause () to cause the program to pause execution.

The debug_query_break function implementation is shown below:

the debug_find_break () function searches for the presence or absence of a viewpoint or viewpoint range from the viewpoint or viewpoint range set by the breakpoint step, which is a general programming technique and will not be described in detail.

Three queries are used by debug_query_break () to determine if the function number fid and the viewpoint number vid should be broken. Firstly, accurately inquiring, if yes, inquiring whether any observation point is set to be interrupted by the function, if still yes, inquiring whether any observation point encountering any function is set to be interrupted by the function, and if three times of inquiring are all false, returning false.

The debug_output () function has been described at output step 103.

The function of the debug_pause function is to have the debuggee program pause execution. There are many ways to have the program pause execution, such as the following pseudo code:

The program is suspended by keeping the interrupt state with global variable gBreaking and executing the loop all the time when gBreaking is TRUE. Other steps are to allow the program to continue execution, so long as gBreaking is set to FALSE, the debug_pause () will exit, thereby enabling the continued execution of the subsequent code.

There are also many methods for suspending the program from executing, such as suspending the thread, waking up the thread when the program is to continue to execute, waiting for a semaphore or message, and issuing the semaphore or message when the program is to continue to execute. Even popping up a dialog box, or calling a system ("pause"), may cause the program to pause execution, not listed.

And a restoration step 106, restoring the execution of the debuggee code. The function of this step is simple to implement, but typically requires triggering to perform this operation, and is therefore also described in terms of one step. The implementation of the resume step 106, which is related to the suspension mode of the interrupt step 105, can be performed by setting gBreaking to FALSE if the interrupt state is saved by the global variable gBreaking (the programming details such as data synchronization are omitted here), by waking up the thread if the interrupt is implemented by a suspended thread, and by sending the corresponding semaphore or message if the interrupt is implemented by a wait semaphore or message. A common trigger scenario of the resume step 106 is to execute from the current breakpoint to the next breakpoint, for example, when the user presets a sequence of breakpoints, issues an instruction to execute the program, and issues an instruction to execute the program again after the interruption, at which time the resume step 106 needs to be invoked or triggered to resume executing the debugged code until the next breakpoint is interrupted. In the interrupt state, when the user issues instructions such as step in, step out, jump out, etc., the resume step 106 needs to be invoked or triggered to resume executing the debugged code until the interrupt is made at the new breakpoint.

And inserting 107, namely inserting codes for calling the interrupt step into the observation point, and inserting codes for calling the variable information storage step into the variable information storage point. The cartridge is prior art and is commonly used in test tools.

The following pseudocode is an example of inserting code at the viewpoint that invokes the interrupt step:

where FID is the number of the current function.

The following pseudo code is an example of inserting code calling the variable information saving step at the variable information saving point:

The plug-in installation should not change the structure of the original code, and if necessary, some symbols should be added additionally, for example { } is added before and after the original code, so that the original first line code is int a=0, and still is the first line code of the scope, thus ensuring that even a C89 compiler will not generate compiling errors. For example, if (x > 0) a++, inserting a line of code before a++, adding { }, for example, if (x > 0) { debug_query_break (FID, 5); a++, so that the structure and function of the original code will not change.

Step 108 is executed to compile and execute the instrumented code. Similar to the traditional debugging mode, before or during execution, the observation point to be interrupted is set automatically or manually, so that the debugged program can be interrupted at a proper position. In a simpler manner, any viewpoint interrupt of the debuggee function is designated before execution, so that execution is automatically interrupted when it enters the debuggee function.

The above is the general constitution of the basic embodiment of the present invention. The analyzing step 101, the inserting step 107 and the executing step 108 are preparation steps before starting debugging and are completed by a debugging tool or a compiler linker, the variable information storing step 102, the outputting step 103, the interrupting step 105 and the recovering step 106 are steps for realizing debugging functions after a debugged program is started, the steps are usually positioned in a debugged process, the breakpoint step 104 is usually provided by the debugging tool for providing an operation interface for a user, the user sends an instruction, the debugging tool transmits breakpoint information and a recovery instruction to the debugged process according to the user instruction, and the transmission mode can use a common inter-process communication technology, and can be specifically realized in various choices such as files, pipelines, shared memories, message queues and the like.

The debugging process is typically interactive in that the variable information holding step 102 holds variable information such as parameters, member variables, etc. when the debugged code is executed to the function entry, and when a local variable is defined, the variable information holding step 102 holds information of the local variable. The breakpoint step 104 specifies a breakpoint before or during execution, and the interruption step 105 is invoked when executing to each observation point, detects whether the observation point should be interrupted, if so, invokes the output step 103 to output the value of the variable, and then pauses the debugged program, at which time the user can observe the value of the variable, analyze whether the code has a problem and the cause of the problem. When the user wishes to continue execution to a certain point, the next breakpoint is set using the breakpoint step 104, and the resume step 106 is invoked, resuming execution from the last breakpoint, and so on, until the debug is complete.

The invention does not use the resources of the traditional debugging mode, such as position mapping data (used for searching the position which can be modified into an interrupt instruction in the tested code), symbol data (used for inquiring variable information) and other files with private formats generated by compilers (different compilers, different versions of the same compiler can have different formats), and does not use debugging APIs (different operating systems and different versions of the same operating system can be different), thereby realizing universality. Although the invention requires additional steps such as parsing step and inserting step, the steps are usually realized in a ready manner, for example, the unit testing tool may have parsing function and inserting function for the tested code, and the parsing and inserting functions required by implementing the invention can be realized by modifying the unit testing tool, and the unit testing tool does not need to be developed from the beginning, so that the unit testing tool is realized by adding a debugging function at least equivalent to the function of the traditional debugging mode. Even if a generic debugger is specifically developed, parsing and instrumentation functions can often find near-ready implementations much easier than with conventional approaches (adaptation of debug data generated by each compiler).

According to the improved embodiment of the invention, any combination (any one step, any two or more than three steps) of the following steps is added, so that more convenient debugging functions are realized, or the universality is further expanded:

An entry specifying step of specifying one or more debug entry functions;

A code replacement step of masking or replacing a special code of the embedded item with a code that can be supported by a host compiler and/or replacing a number representing a memory address with a pointer;

And a drive generation step of generating a drive code capable of directly calling the debugged function. This step is used to solve the problem of lack of direct drive in the conventional debug mode. The driver code, i.e. the code that can call the function to be debugged, is commonly used in the unit test process, in this embodiment for debugging. In the test process of unit test, drivers are usually generated for each tested function so as to directly set test data for the tested function, and the drivers can be directly used for debugging, so that when the debugging function is added to the unit test tool by using the method, no additional driving code is actually required to be generated. If the driver code is to be generated, the generation of the driver code on the basis of the acquired function information is prior art (as is the case with the driver code tested by the generation unit), and the generation process will not be described in detail. For a debugged function, the drive code is provided, so that the debugging data can be directly set, and the repeated interception of the proper debugging data is avoided, namely, the direct drive is realized. The set debug data can be saved and permanently valid. On the other hand, the debugging data can also be used for unit testing, so that the debugging and testing integration is preliminarily realized.

An entry assignment step of assigning one or more debug entry functions. An entry function refers to a function that can set debug data and execute debugging. If the drive code (automatically generated by a drive generation step or manually written) is prepared for the debugged function, the debug data is directly set, and the debug is performed, then the debug entry function is the debugged function itself. This mode of operation has the advantage that the debug data can be set and managed directly, but common data of the conventional debug mode cannot be used, sometimes increasing the workload. If direct driving is not used, for example, in the basic embodiment, natural driving can be used, a general program has a natural entry (such as a main function), a debugged function may be the natural entry function itself, or the natural entry function is directly or indirectly called, and no entry is required to be specified, in this way, debug data is generally public data, which is disadvantageous to data management. To both, an entry assignment step is added to assign one or more debug entry functions. For example, the function F may have a call path that is main function- > function A- > function B- > function C- > function D- > function E- > function F, and in order to debug the function F, the function on the whole call chain may be used as an entry function, for example, with the function C as an entry, if a driving code (automatically generated by a driving generating step or manually written) is prepared for the function C, the function C may be set as debug entry data, debugging is performed from the function C, and the function F may acquire appropriate debug data for debugging by an interception manner. The debugging data of the function C can be regarded as common debugging data for functions directly or indirectly called by the function C, but the scope of the debugging data is smaller than that of a natural driving mode, so that the debugging data and the management data are convenient to set. Any function with direct drive codes can be directly called and executed, so that after an entry function is designated, the entry function is executed, and a breakpoint is added at the entry of the debugged function, and the debugged function can be debugged.

A code replacement step of masking or replacing the special code of the embedded item with code supported by the host compiler and/or replacing the number representing the memory address with a pointer. This step replaces the non-standard key with a standard key or mask, or masks special code segments like @0x 1234. In addition, the number representing the memory address is replaced by a pointer, such as (int) 0x00FF 0000=n, and 0x00FF0000 is a number that is syntactically compliant by forced type conversion to logically represent a memory address. If such code is debugged on a host, it may cause a run-down due to illegal memory addresses. One solution is to define a global variable and replace the number with the address of the global variable, so that the embedded debugging running on the host can be realized without changing the code logic. The step solves the problem of running and debugging the embedded project on the host, so that the embodiment of the invention can run and debug the project on the host. The specific replacement process belongs to the prior art in the field of unit testing, and the embodiment is used for debugging, and the implementation process is unchanged and is not described in detail.

And a remote communication step, namely, communicating when the debugged program is executed on other computers. The remote debugging problem is solved, the prior art in the field of unit testing is specifically realized, and the embodiment is used for debugging, the realization process is unchanged, and the details are not described.

In the improved embodiment of the invention, a storage step can be added to store output data, wherein the output data refers to the value of the variable of the debugged function. The outputting step 103, which has been described as to how the values of the variables of the debugged function are outputted, is performed by saving these values to a file or other storage means. After these values are saved, reusable debug data is formed. If the save step is performed at the entry of the debugged function (when the debug_output function is called, the second parameter is set to TRUE), the result is the input of debug data, and if the save step is performed at the exit of the debugged function (the second parameter is set to FALSE), the result is the output of debug data. These debug data may also be referred to as debug cases, where after the input and output are saved, the input may be used directly for debugging again, while the output may be used to manually or automatically check whether the execution differs between the two. On the other hand, the debugging case can also be used as a unit test case, so that the debugging case and the unit test case are completely universal, the same data and the same drive are used for segmentation execution by adding break points, the value of a manually observed variable is common debugging, the debugging case is directly executed without adding the break points, and whether the actual output accords with the preset value or not is automatically judged to be the unit test.

The improved embodiment of the invention can realize that embedded project codes are debugged on a PC, projects on a remote machine are debugged on a local machine, and drive codes can be automatically generated, so that each debugged function can directly set and manage debug data, and debug entry functions can be designated, so that common debug data or debug data of other functions can be used as required. The improved embodiment can save the debug data to form reusable debug data, solves the management problem of the debug data, and can be used as a unit test case and solves the problem of debug and test integration.

Fig. 2 is a general schematic diagram of another embodiment of a program debugging method according to the present invention, as shown in fig. 2, in which the breakpoint step 104, the interrupt step 105, and the resume step 106 are replaced with an automatic output step 109 based on the basic embodiment shown in fig. 1. The function of the automatic export step 109 is to automatically invoke the export step 103 at the entry and exit of each debugged function. The breakpoint step 104, the interruption step 105 and the resumption step 106 enable human interaction with the debugger, execution, suspension (observation of data), re-execution, re-suspension (observation of data). Interaction is a relatively common way of debugging, but not the only way. The method is also a debugging mode, and required data are captured and transmitted out and then analyzed. In this embodiment, the step of interactive debugging is omitted, and the step 109 is automatically output instead, so that another debugging mode other than the interactive mode is realized. The implementation of the automatic output step 109 is a conventional programming technique, as long as the output step 103 is called at the entry and exit of each debugged function (the output position can be prompted by a second parameter), the implementation can call the output step 103 at the observation point at the entry position and call the output step 103 at the observation point at the exit position, or directly insert the code for calling the output step 103 at the entry of each debugged function and insert the code for calling the output step 103 at the exit of each debugged function. This embodiment is typically used in cases where direct driving is not used, i.e. execution starts from a natural entry or a designated debug entry function, with lower functions outputting intercepted data at the entry and exit of the function. The embodiment can automatically and batchly generate and output the debugging data of the lower-level functions by utilizing the common debugging data or the debugging data of the upper-level functions.

In this embodiment, the use case saving step may be further added, in which output data generated at the function entry is saved as an input of a use case, and output data generated at the function exit is saved as an output of a use case. The use case preservation step has been described above, and the preservation process is not repeated. After the storage step is added, the implementation can be used for automatically generating batch cases, and the cases are not only debugging cases but also unit test cases.

This embodiment may also add any combination of the following steps (either or both steps):

The duplicate removal step carries out preliminary arrangement on the use cases and removes the duplicate use cases with the same input.

And a screening step, wherein the validity of the case is judged by counting whether the coverage rate is increased, which is the prior art in the field of unit test. Based on the thinking of debug integration, debug cases and test cases are shareable. From the unit test perspective, the basic design basis of the use case is an 'equivalence class', namely, input is classified, any value in the same class is valued, and the test effect is the same. Each equivalence class should correspond to a function point. From the standpoint of code implementation, the function points should correspond to different code combinations, so different function points correspond to different code combinations, and these code combinations can be reflected on coverage statistics indexes such as code rows, conditions, paths, etc., so whether the use cases belong to new equivalence classes can be judged by counting whether the coverage rate is increased, and the use cases not belonging to the new equivalence classes can be regarded as useless cases, which is the principle and the purpose of the screening step. The specific process of counting the coverage state and deleting the use cases which cannot increase the coverage rate belongs to the prior art in the field of unit test, and the embodiment is used for debugging, the implementation process is unchanged and is not described in detail.

In this embodiment, a confirmation step may be further added to find an approximate case for the case to be confirmed, and list the data differences between the approximate case and the case, where the approximate case is the case with the smallest input difference or the smallest coverage difference from the case to be confirmed. In the above embodiment, from the input point of view, valid cases are screened out. In this embodiment, from the output point of view, the quality of the use case is further improved. The output of the use case, or called the expected output, is preset according to the design function and input of the code, the user considers the correct result of the application, and when the actual output does not accord with the expected output, the error is automatically reported. The use case generated in the previous embodiment has an output that is a record of the actual output and is not "expected correct output", that is, it is not possible to determine whether there is an error by comparing whether the actual output coincides with the expected output, which is a problem to be solved by the confirmation step. If the correct expected output is set manually, the accuracy of the expected output can be ensured, but the workload is increased. The actual output is saved, checked manually, and whether the actual output is correct or not is judged according to the design function of the code, and if the actual output is incorrect, the actual output is modified, so that the method is a way for ensuring the quality of the use cases and reducing the workload. The actual output is usually mostly correct and the small part is incorrect, and it is not easy to distinguish the incorrect small part completely, and the confirmation step of this embodiment provides a scheme that an approximate use case is calculated, the data difference of the two is listed, and the user can pay attention to the difference part, so that whether the output is correct or not can be judged quickly and accurately, and the confirmation can be completed quickly.

One selection basis for approximating the use case is the smallest difference from the input of the use case to be confirmed. And comparing the to-be-confirmed use cases with other use cases one by one, inputting, and selecting the use case with the smallest difference as an approximate use case. The comparison rule may be set as needed, for example, the first round finds the use case with the least variable number of different values, and the second round compares the difference amounts of different values to find the use case with the least total difference amount. The calculation rule of the difference amount may be set as necessary, for example, the character string has different numbers of characters as the difference amount, and the number has an absolute value of a difference of values as the difference amount.

Another basis for selecting the approximate use case is to minimize the coverage difference from the use case to be confirmed. The rule for calculating the coverage difference may be set as needed, for example, by the condition of coverage or by the statement of coverage, the total number of differences may be calculated, or the same coverage may be calculated in reverse. The same coverage is selected and calculated to select the use case with the smallest coverage difference, namely, the condition (or sentence, other coverage units are also possible) of the use case coverage to be confirmed is compared with other use cases one by one, and the use case with the largest coverage is found out to be the approximate use case. If there are multiple choices, other coverage may be further compared, but a direct choice of one is also possible.

After the approximate use cases are selected, the input and the output of the two use cases are displayed, the input difference part and the output difference part of the two use cases are marked, and a user can pay attention to the difference, so that whether the actual output accords with the expectation or not is judged rapidly.

The embodiment realizes that the debugging data of the public or superior function is utilized to automatically generate the debugging cases and the testing cases, and the quality of the cases is improved through the screening and confirming steps, so that the problem of automatically generating the high-quality unit testing cases is solved.

In another embodiment of the present invention, a program debugging system is implemented in the foregoing description of a program debugging method, which is not described herein.

The above examples are merely preferred embodiments of the present invention, which are intended to illustrate the present invention and not to limit the present invention, and modifications, variations or equivalents are intended to be included within the scope of the present invention without departing from the spirit and scope of the present invention.

Claims

1. A program debugging method, characterized in that it includes:

Analysis steps: Analyze the code being debugged to obtain: information about the function being debugged; definition information of data types; variable information storage points; and observation points, where the observation points refer to the locations in the code where interruption steps can be inserted.

Steps for saving variable information: Save the variable information of the function being debugged;

Output steps: Output the values of the variables of the function being debugged;

Breakpoint procedure: Automatically or manually specify the observation point and/or range of observation points to be interrupted;

Interruption step: Check whether the observation point should be interrupted. If so, call the output step and pause the execution of the debugged code.

Recovery steps: Resume execution of the debugged code;

Instrumentation steps: Insert code that calls the interrupt step at the observation point; insert code that calls the variable information saving step at the variable information saving point;

Execution steps: Compile and execute the instrumented code being debugged.

2. The program debugging method according to claim 1, characterized in that it includes any one or more of the following steps:

Driver generation steps: Generate driver code that can directly call the debugged function;

Entry point specification steps: Specify one or more debug entry point functions;

Code replacement steps: Mask or replace the special code of the embedded project with code supported by the host compiler, and/or replace the numbers representing memory addresses with pointers;

Remote communication steps: Used for communication when the program being debugged is executed on another computer.

3. The program debugging method according to claim 1 or 2, characterized in that it includes:

Saving steps: Save the output data, which refers to the values of the variables in the function being debugged.

4. The program debugging method according to claim 1 or 2, characterized in that it includes:

Replace breakpoint steps, interrupt steps, and resume steps with automatic output steps: automatically call the output steps at the entry and exit points of each debugged function.

5. The program debugging method according to claim 4, characterized in that it includes:

Test case generation steps: Save the output data generated at the function entry point as the input of the test case, and save the output data generated at the function exit point as the output of the test case.

6. The program debugging method according to claim 5, characterized in that it includes any one or two of the following steps:

Deduplication step: Compare the input of the test cases and delete duplicate test cases;

Filtering steps: Execute the test cases, count the coverage status, and delete test cases that cannot increase coverage.

7. The program debugging method according to claim 6, characterized in that it includes:

Confirmation steps: Find approximate use cases for the use case to be confirmed, and list the data differences between the two. The approximate use case refers to the use case with the smallest input difference or the smallest coverage difference with the use case to be confirmed.

8. The program debugging method according to claim 1, characterized in that:

The function information includes: function name, class or namespace, implementation code, and variable type and name; the variables refer to the variables that need to be observed during debugging, including: return value, parameters, member variables, global variables, and local variables; the data type definition information includes: type name, memory size, member name, type name, and offset of each member; the variable information includes: variable type, name, and address.

9. A program debugging system, characterized in that it comprises:

The parsing device parses the code being debugged and obtains: information about the function being debugged; definition information of data types; variable information storage points; and observation points, where the observation points refer to the locations where code that can be inserted to call the interrupt device.

Variable information storage device: stores the variable information of the function being debugged;

Output device: Outputs the values of the variables of the function being debugged;

Breakpoint device: Automatically or manually specify the observation point and/or range of observation points that need to be interrupted;

Interruption device: Detects whether the observation point should be interrupted; if so, calls the output device and suspends the execution of the debugged code.

Recovery device: Resumes execution of the debugged code;

Insertion device: Insert code that calls the interrupt device at the observation point; insert code that calls the variable information storage device at the variable information storage point;

Execution device: compiles and executes the instrumented debugged code.

10. The program debugging system according to claim 9, characterized in that it comprises:

Replace breakpoints, interrupts, and recovery mechanisms with automatic output mechanisms: automatically call the output mechanism at the entry and exit points of each debugged function.

11. The program debugging system according to claim 10, characterized in that it comprises:

Test case generation device: Saves the output data generated at the function entry point as the input of the test case, and saves the output data generated at the function exit point as the output of the test case.

12. The program debugging system according to claim 11, characterized in that it comprises any combination of the following devices:

Deduplication device: compares the input of the test cases and deletes duplicate test cases;

Filtering device: Executes the test cases, counts the coverage status, and deletes test cases that cannot increase coverage.

Verification device: Finds approximate use cases for the use case to be verified and lists the data differences between the two. The approximate use case refers to the use case with the smallest input difference or the smallest coverage difference with the use case to be verified.