Firmware code coverage rate statistical method and electronic equipment

Abstract

The invention discloses a firmware code coverage rate statistical method and electronic equipment, and relates to the technical field of program detection.The firmware code coverage rate statistical method comprises the steps that in response to a first script construction command, an automatic script is called to insert a stake point code in a firmware code file, and the stake point code comprises a file index, a statistical function and a macro definition, a first array created by the macro definition records a code line number and execution times, and a second array created by the macro definition records a file index, a line number limit value and a first array address; when the firmware code file is operated, a statistical function is called when the stake point position is executed, the statistical function counts executed codes in the firmware code file according to the first array and the second array, and the firmware coverage rate is calculated by combining the executed codes and the total code of the firmware code file; the problem that the operation performance is affected due to the fact that a large amount of storage and memory are occupied in the prior art is solved, and the technical effects that firmware resource occupation is reduced, and the firmware operation performance is not affected are achieved.

Description

Technical Field

[0001] The present application relates to the field of program detection technology, and in particular to a firmware code coverage statistics method and electronic device. Background Art

[0002] In software development, code coverage statistics are an important measure of test completeness and quality. As system complexity continues to increase, code coverage becomes increasingly critical to ensuring software reliability and security.

[0003] At present, relevant technologies have obvious deficiencies in the field of firmware code coverage statistics: on the one hand, some tools can only provide basic block coverage, which is complex to operate and inefficient; on the other hand, although some tools support more refined indicators such as branch coverage and condition coverage, they are prone to code bloat during the instrumentation process, increasing storage and memory overhead, and are difficult to use in resource-constrained firmware environments. Summary of the Invention

[0004] The present application provides a firmware code coverage statistics method and electronic device to at least solve the problem in the related art that firmware code coverage statistics occupy a large amount of storage and memory and affect operating performance.

[0005] The present application provides a firmware code coverage statistics method, including: responding to a first script construction command, calling an automated script to insert stub code into a firmware code file, wherein the stub code includes a file index, a statistical function and a macro definition, and a first array and a second array are created in the macro definition, the first array is used to record the code line number and the number of executions, and the second array is used to record the file index, the line number limit and the address of the first array; running the firmware code file, and when recognizing that the firmware code file runs to the insertion position of the stub code, calling the statistical function in the stub code, and the statistical function counts the executed code in the firmware code file according to the first array and the second array; obtaining the total code of the firmware code file, and calculating the firmware code coverage of the firmware code file according to the executed code and the total code in the firmware code file.

[0006] The present application provides a firmware code coverage statistics device, including: a calling module, which is used to respond to a first script construction command and call an automated script to insert a stub code into a firmware code file, wherein the stub code includes a file index, a statistical function and a macro definition, and a first array and a second array are created in the macro definition, the first array is used to record the code line number and the number of executions, and the second array is used to record the file index, the line number limit and the address of the first array; a statistical module, which is used to run the firmware code file and call the statistical function in the stub code when identifying that the firmware code file runs to the insertion position of the stub code, and the statistical function counts the executed code in the firmware code file according to the first array and the second array; a calculation module, which is used to obtain the total code of the firmware code file and calculate the firmware code coverage of the firmware code file according to the executed code and the total code in the firmware code file.

[0007] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of the above-mentioned firmware code coverage statistics method when executing the computer program.

[0008] The present application also provides a non-volatile computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of the above-mentioned firmware code coverage statistics method are implemented.

[0009] The present application also provides a computer program product, including a computer program, which implements the steps of the above-mentioned firmware code coverage statistics method when executed by a processor.

[0010] Through this application, in response to the build command, an automated script is called to insert stub code into the firmware code. The stub contains file index, statistical function and macro definition. The first array created by the macro definition records the code line number and execution count, and the second array records the file index, line number upper limit and the first array address; when the firmware code is running, the statistical function is called at the stub, and the executed code is counted according to the array, and the coverage is calculated based on the total code. Therefore, the problem that the related technology occupies a large amount of storage and memory and affects the running performance can be solved, and the technical effect of reducing firmware resource usage and not affecting the firmware running performance is achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0012] Figure 1A schematic diagram of the structure of a firmware code coverage statistics method provided in an embodiment of the present application; Figure 2 Flowchart for automated analysis of firmware code coverage statistics provided by an embodiment of the present application; Figure 3 Flowchart of the execution of the firmware code coverage statistics function provided in the embodiment of the present application; Figure 4 A schematic diagram of the structure of a firmware code coverage statistics device provided in an embodiment of the present application; Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0013] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0014] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0015] In order to make those skilled in the art better understand the present application scheme, the following Figure 1 The present application is further described in detail with specific implementation methods.

[0016] Figure 1 A schematic diagram of a firmware code coverage statistics method provided in an embodiment of the present application is shown in FIG. Figure 1 As shown, the firmware code coverage statistics method includes the following steps: In step S101, in response to the first script construction command, the automation script is called to insert the stub code into the firmware code file, wherein the stub code includes a file index, a statistical function and a macro definition, and a first array and a second array are created in the macro definition. The first array is used to record the code line number and the number of executions, and the second array is used to record the file index, the line number limit and the address of the first array.

[0017] Among them, the first script is an automated script for stubbing firmware code. Stub code is additional code inserted into the firmware code file, which is used to collect coverage statistics when the firmware is running. The file index is the unique number of each firmware code file in the firmware project, which is used to distinguish the data sources of different files during the coverage statistics process. The statistical function is a function called by the stub code. When the firmware is running, the count value corresponding to the current execution position is accumulated and stored in the specified data structure. The macro definition is a macro declared by the C language preprocessing instruction #define, which is used to automatically expand into the data structure, array declaration and statistical function call required for the stub during the compilation phase, thereby quickly generating coverage collection code in the firmware code and avoiding manual writing one by one. The first array is an array of type file_coverage_cnt_t, which is used to store coverage statistics at the firmware code line level. The array elements contain the code line number and its corresponding execution count. The code line number is the position number of each statement or code line in the firmware code, which is used to count the execution count. The second array, of type file_coverage_cfg_t, stores file-level code coverage configuration information. The array elements include the file index, the line limit, and the address of the first array corresponding to that file. The file index uniquely identifies each file and its corresponding statistical data in coverage statistics, ensuring that line-level execution counts are correctly recorded in the corresponding file's array. The line limit limits the maximum line of code that can be recorded in the first array to prevent out-of-bounds access.

[0018] It can be understood that by inserting stub code into the firmware code file, the embodiment of the present application can automatically collect code coverage data during the operation of the firmware, and accurately track the execution of the firmware code. Specifically, the first array is used to record the line number of each line of code and its corresponding number of executions, so as to obtain line-level coverage information; the second array saves the file index, line number limit, and the address of the first array corresponding to the file. The line number limit is defined to limit the statistical range, prevent invalid access and array out of bounds, and improve the query security of the statistical function. The grouping management and accurate positioning of different firmware code coverage data are achieved to ensure that the statistical process does not confuse the execution status of different files. At the same time, the statistical function is dynamically called when the firmware is running, and the integrity and accuracy of the coverage data are guaranteed by continuously accumulating the number of executions in the first array.

[0019] In one embodiment of the present application, calling an automated script to insert stub code into a firmware code file includes: calling an automated script to copy a folder containing stub code as a backup folder; inserting the stub code into the firmware code file, and compiling the firmware code file after the insertion is completed. If the firmware code file compilation fails, terminating the compilation process of the firmware code file; and compressing the folder containing the stub code after the firmware code file is compiled.

[0020] Among them, the automated script is a script program used to implement firmware code insertion, backup, compilation and compression operations. The above operations can be automatically completed by calling the script. The stub code file is the original uninstrumented firmware code file. The backup folder is generated by the automated script copying the stub code folder before insertion, and is used to restore the original firmware code when the stub insertion or compilation fails. Compilation is the process of processing the firmware code file after insertion, including syntax checking, generating target files and other operations to generate an executable firmware file. Compression is to package the firmware code folder after insertion into a compressed file for storage for archiving and subsequent analysis.

[0021] It is understandable that the automated script can copy the folder of the stub code before instrumentation to generate a backup folder to ensure that the original code can be restored when instrumentation or compilation fails; insert the stub code into the firmware code file and compile it to ensure that the instrumented code can successfully generate executable firmware. If the compilation fails, the process is automatically terminated to avoid the generation of erroneous firmware; after the compilation is completed, the folder of the instrumented stub code is compressed and saved for archiving, management and subsequent coverage analysis.

[0022] The first script build command in this embodiment of the application is implemented by synergizing an automated script with a Makefile configuration, and is used to insert stub code into the firmware code to collect coverage data. When executing the "make" command and adding the parameter "COV=1," the Makefile calls the automated script to initiate the stub insertion process. The Makefile is a configuration file used to manage the firmware code compilation and build process. By defining commands and parameters, it enables the calling of automated scripts and the compilation, stub insertion, and cleanup of the firmware code.

[0023] Specifically, the first script will copy the folder of the stub code to generate a backup folder, which is used to restore the original code when an exception occurs during the stub or compilation process. Then, the first script processes the target C file and inserts the stub code into each file, including: Define FILE_NUM as a file index to distinguish different firmware code files; insert the COV_ENTRY macro definition to create the first and second arrays; define MAX_ENTRY to represent the total number of functions in the current firmware code file that have the COV_ENTRY macro definition inserted; reference the necessary header files to ensure the availability of statistical functions and data structures. The macro definition generates a unique variable name by concatenating parameters and places the variable in a specified memory segment for quick access by the statistical function, thus automatically generating line-level coverage statistics code.

[0024] After insertion, the script compiles the firmware code file to verify that the instrumented code can correctly generate executable firmware. If C file format errors or other anomalies occur during compilation, the script outputs an error message and terminates the compilation process, prompting the user to perform repairs to ensure normal execution of subsequent processes. Finally, the script compresses the folder containing the instrumented points into a ZIP file for easy archiving and management.

[0025] In one embodiment of the present application, after calling the automated script to copy the folder of the stub code as a backup folder, it also includes: responding to the second script construction command, calling the automated script to delete the folder of the stub code; and restoring the backup file to the folder of the stub code.

[0026] The second script is an automated script for deleting the inserted stub code and restoring the backup folder. Restoring copies the backup file back to its original location to restore the stub code folder to its previous state, completing the instrumentation cleanup and recovery operations.

[0027] It is understandable that the embodiment of the present application, by responding to the second script construction command, calls the automated script to delete the folder where the stub code has been inserted, and restores the backup file to the original stub code folder, thereby achieving safe cleaning and rapid recovery of the inserted stub code. When an exception occurs during the firmware code insertion or compilation process, the original state can be restored through the backup file, ensuring the integrity and stability of the stub code. At the same time, the automated script uniformly performs the deletion and restoration operations, allowing the backup files to be reused, thereby improving testing efficiency and simplifying the operation process.

[0028] The second script construction command of the embodiment of the present application is completed by the automation script and Makefile configuration, which is used for the cleanup process of the firmware code. When the "make DCOV=1" command is executed, the Makefile will call the corresponding automation script to start the cleanup operation.

[0029] First, the script deletes the folder containing the stub code that was inserted to clean up the instrumented data. The script then restores the backup folder generated before instrumentation to its original location to restore the original firmware code. Furthermore, the cleanup process does not process compressed ZIP files. ZIP files are a compressed file format used to package and compress one or more files or folders to reduce storage space or facilitate transfer.

[0030] In one embodiment of the present application, before restoring the backup file to a folder of stub code, it also includes: identifying whether the backup file is damaged or does not exist; if the backup file is damaged or does not exist, generating at least one of an error message and a manual processing prompt; if the backup file exists and is not damaged, restoring the backup file to a folder of stub code.

[0031] It is understandable that when the backup file is abnormal, the automated script promptly prompts the user to repair or manually intervene to avoid incomplete or damaged stub code caused by direct restoration; when the backup file exists and is intact, the embodiment of the present application can quickly restore the original stub code state, providing a reliable basis for subsequent instrumentation, compilation or coverage analysis.

[0032] Specifically, before restoring the backup file to the stub code folder, the second script will first check whether the backup file exists or is damaged to avoid incomplete stubs or abnormal coverage statistics due to missing or damaged backup files. If it is detected that the backup folder does not exist or is damaged, the embodiment of the present application performs at least one of the following operations: generating an error message to inform the user of the abnormal situation, or providing manual processing prompts to guide the user to take appropriate measures (such as regenerating the backup file or repairing the damaged file). If the backup file exists and is not damaged, the restore operation is performed to restore the backup file to the original stub code folder, restoring the firmware stub to the state before the stub was inserted.

[0033] In one embodiment of the present application, script call parameters are added to the first script construction command and the second script construction command, wherein when the script construction command is executed, the automation script is called based on the script call parameters.

[0034] It is understandable that by calling the automation script based on the script call parameters when executing the script build command, the firmware stub operation can be automated. According to different parameters, the instrumentation, cleanup, backup or compression processes can be flexibly triggered, avoiding the tedious and error-prone manual operations.

[0035] The automated method for analyzing code coverage in software testing in the embodiment of the present application has the following process: Figure 2 As shown, the following steps are included: In step S201, the user executes the "make COV=1" command to trigger the predefined operation process in the Makefile. By adding the "COV=1" parameter, the Makefile can recognize and call the corresponding automation script to start the code coverage statistics and instrumentation operations.

[0036] In step S202, the Makefile calls a first script (e.g., add_patch_cov.py) to insert stubs into the stub code file to implement real-time monitoring of the program execution path. The first script monitors the program execution path by inserting stubs into the stub code file.

[0037] In step S203, to ensure the integrity of the stub code, the first script first copies the entire stub code folder, creating a copy named "xx_copy." All subsequent instrumentation, modification, and compilation operations are performed in this copy, avoiding direct impact on the original code. This also allows for rapid restoration of the firmware code to its original state in the event of an anomaly, ensuring operational safety and reliability.

[0038] In step S204, the script traverses all C language source files in the copy folder and inserts stub code at specific locations. The inserted stub code is mainly used to record the execution count of the corresponding code line to ensure that line-level coverage information can be obtained.

[0039] In step S205, after all C files have been instrumented, the script invokes a compilation toolchain, such as GCC (GNU Compiler Collection), to compile the firmware code in the replica and generate an instrumented executable file. During runtime, this executable file dynamically collects coverage information, including the execution count and status of each line of code, providing data for program analysis, debugging, and performance evaluation.

[0040] In step S206, the script packages the entire instrumented folder into a ZIP file for easy storage, management, and subsequent transmission. This compressed file is used to store all instrumented firmware code and the generated executable file, providing a complete and reusable data base for coverage analysis, debugging, and version management.

[0041] In step S102, the firmware code file is run. When it is identified that the firmware code file runs to the insertion position of the stub code, a statistical function in the stub code is called. The statistical function counts the executed codes in the firmware code file according to the first array and the second array.

[0042] It can be understood that by identifying the execution location of the stub code and calling the statistical function during the running of the firmware code, the execution status of the firmware code can be recorded in real time, the execution times of each code can be accurately collected, and line-level and file-level coverage statistics can be achieved.

[0043] In one embodiment of the present application, a statistical function counts the executed code in the firmware code file based on the first array and the second array, including: obtaining the current file index and the current code line number; querying the second array based on the current file index; if no matching file index is found in the second array, generating a warning message; if a matching file index is found in the second array, obtaining the address of the first array from the second array, and linking the first array based on the address of the first array; querying the first array based on the line number limit and the current code line number, if a matching code line number is found from the first array, accumulating the number of executions of the current code line number; if no matching code line number is found from the first array, generating a warning message.

[0044] It is understood that by using the statistical function to count the execution of the firmware code according to the first and second arrays, the execution count of each line of code in each file can be accurately recorded. If the statistical process finds a mismatch between the file index or code line number, a warning message will be generated, indicating that there may be an issue with incorrect instrumentation or firmware code changes, which helps to identify executed and unexecuted code lines.

[0045] The statistics function consists of a data structure definition and a coverage statistics function called COV. It is used to record code execution during firmware execution. When the firmware code executes to the inserted stub location, the statistics function is called and receives the current file index and code line number as parameters.

[0046] The counting function first traverses the second array to find an array element that matches the current file index. If no matching file index is found in the second array, a warning mechanism is triggered. If a matching file index is found in the second array, the address of the first array is obtained from the array element and the corresponding count array is accessed based on this address.

[0047] Next, the first array is searched for an element matching the current line of code. The execution count for that line of code is accumulated. There is an upper limit to the execution count, and if it is exceeded, it will no longer increment. For example, the upper limit for the execution count of a line of code is 65535. When the cumulative execution count for that line of code reaches 65535, even if it is executed again, the cumulative count will not increase and will remain at 65535, thus preventing overflow.

[0048] If the statistical function does not find a matching line number when searching for the element corresponding to the current code line number in the first array, it means that the line of code has not been recorded or the array is full. At this time, the embodiment of the present application will generate a warning message.

[0049] In one embodiment of the present application, if no matching code line number is found from the first array, before generating a warning message, it also includes: querying whether the first array records the number of executions of the target line number; if the first array records the number of executions of the target line number, writing the number of executions of the target line number into the current code line number, and accumulating the number of executions of the current code line number; if the first array does not record the number of executions of the target line number, generating a warning message.

[0050] It can be understood that by first querying whether the target row number has been executed in the first array, it can be ensured that the execution count of the current row number is accumulated based on the existing data to avoid repeated counting or missed counting; if the target row number has been recorded, the embodiment of the present application will write its execution count into the current row number and accumulate it, ensuring that statistical data will not be lost during multiple executions or different insertion positions; when the record of the target row number is not found in the first array, a warning message will be generated to remind developers that there may be problems such as missing insertions, full arrays or data anomalies, which will help to discover and handle potential errors as early as possible.

[0051] Figure 3 This section demonstrates the execution logic and related processing flow of the statistical function used in the code coverage statistics process in this application's embodiment. The overall process begins with the function call, determines the corresponding data location through the file index and line number, and ultimately accumulates the number of code executions, while outputting a warning message when no corresponding record can be matched.

[0052] The process begins at step S301, where a statistics function is first called. This function receives a file index and line number as input for subsequent statistical processing. Then, in step S302, the second array is traversed, storing file-related information for matching the target file index. In step S303, a determination is made as to whether an entry matching the target file index has been found. If not, a warning message is output and the process returns. If a matching file index is found, the address of the corresponding first array is retrieved in step S304 for subsequent line number matching and counting operations.

[0053] Next, in step S305, the first array is traversed, which records the specific code line numbers and their execution counts. In step S306, it is determined whether a record matching the target line number is found. If so, the address of the line number in the first array is directly obtained in step S307, and the execution count is accumulated in step S308 (the upper limit of the cumulative value is 65535). If no matching row number is found, then in step S309, it is further determined whether there is a record with row number 0. If it is a jump row number, then in step S310, the current row number is written into the array and the process jumps to step S308 for count accumulation. If there is no record with row number 0, it means that a counting position cannot be allocated for the current row number, and the embodiment of the present application will output a warning message and return.

[0054] The embodiment of the present application finds the corresponding file by traversing the second array, then finds the corresponding line number by traversing the first array, and decides whether to accumulate the number of executions based on whether it is a jump mark line number, thereby achieving accurate statistics on the execution of the firmware code.

[0055] In step S103, the total code of the firmware code file is obtained, and the firmware code coverage of the firmware code file is calculated according to the executed code and the total code in the firmware code file.

[0056] Among them, firmware code coverage is used to measure the completeness of firmware testing, usually expressed as the percentage of executed code to total code.

[0057] It can be understood that by obtaining the total code of the firmware code file and calculating the coverage rate in combination with the actually executed code lines, the test coverage can be accurately evaluated and the unexecuted code areas can be identified.

[0058] In one embodiment of the present application, before calculating the firmware code coverage of the firmware code file based on the executed code and the total code in the firmware code file, it also includes: obtaining a first interactive command, wherein the first interactive command is defined by a management command; in response to the first interactive command, exporting the area data of the first array and the area data of the second array, and determining the executed code in the firmware code file based on the exported data.

[0059] The first interactive command is a command sent by the host end for exporting firmware statistics. It can be understood that by obtaining and responding to the first interactive command, exporting the area data of the first array and the second array from the firmware, and thereby determining the actual execution status of the firmware code file, the test coverage can be accurately quantified and uncovered code areas can be identified.

[0060] The host sends a command to export firmware statistics. This export and clearing of statistics is accomplished by defining the format of the nvme vendor admin command (including fields such as Opcode, NSID, DW12, and DW13). During the data export phase, the data in the first and second arrays is selected for export based on the values ​​specified in the command. The size and range of the exported data are determined in conjunction with other command parameters. After receiving the command, the firmware returns the data in the corresponding areas to the host. The host then uses a parsing script to read the statistical results and generate a report containing relevant information. The report also counts the number of unexecuted lines of code and calculates the execution coverage of each file.

[0061] In one embodiment of the present application, before calculating the firmware code coverage of the firmware code file based on the executed code and the total code in the firmware code file, it also includes: obtaining a second interactive command, wherein the second interactive command is defined by a management command; and clearing the corresponding file data in the firmware code file in response to the second interactive command.

[0062] The second interactive command is a command sent by the host end for clearing firmware statistics records.

[0063] It can be understood that by obtaining and responding to the second interactive command and clearing the corresponding statistical data in the firmware code file, the coverage statistics can be ensured to be in the initial state before each test, effectively eliminating the interference of historical test data on the new round of coverage analysis and avoiding misjudgment of code execution.

[0064] During the record clearing phase, the host sends a command to clear the firmware statistics. Depending on the value specified in the command, different clearing operations are performed, including clearing the statistics for all files, clearing all statistics for a specified file, or clearing the statistics for a specific line number in a specified file. If the command format does not conform to the definition, an error message will be triggered in this embodiment of the application.

[0065] Through the first interactive command and the second interactive command, the host and the firmware can achieve accurate export and on-demand clearing of statistical data.

[0066] In one embodiment of the present application, the firmware code coverage of the firmware code file is calculated based on the executed code and the total code in the firmware code file, including: inputting the executed code and the total code in the firmware code file into a parsing module on the host side, the parsing module collaboratively calculates the firmware code coverage of the firmware code file through multiple parsing scripts, wherein the parsing module includes a first parsing script, a second parsing script and a third parsing script, the first parsing script reads the statistical results, the second parsing script performs statistics on the pile points, the third parsing script reads the data contained in the first parsing script and the second parsing script, calculates the unexecuted code, and calculates the firmware code coverage of the firmware code file based on the executed code and the total code in the firmware code file.

[0067] Among them, the first parsing script is used to read the firmware statistics and generate a structured data file containing information such as file index, line number and number of references; the second parsing script is used to count all the inserted stubs in the firmware and calculate the execution status of each code line or code block; the third parsing script is used to analyze the unexecuted code lines based on the data generated by the first two scripts, and calculate the execution coverage of each firmware code file.

[0068] It can be understood that by inputting the actually executed code and total code in the firmware code file into the host-side parsing module and using multiple parsing scripts to collaboratively calculate the coverage, the execution status of each firmware code file can be accurately obtained, and the executed and unexecuted code lines can be clearly identified.

[0069] This embodiment of the application implements coverage statistics through the collaboration of multiple parsing scripts. Specifically, the first parsing script reads firmware statistics through an interface, parses and generates a JSON (JavaScript Object Notation) formatted file containing information such as file index, line number, and number of references. The second parsing script summarizes and counts all inserted stub data. The third parsing script, based on the information generated by the first and second parsing scripts, analyzes unexecuted code lines and generates corresponding files, while also calculating the execution coverage of each file. If the data export format does not meet the specifications or is incomplete, the script will output an error message to indicate the abnormality.

[0070] In summary, this application discloses a firmware code coverage statistics method based on code instrumentation. The overall process includes a compilation phase, a firmware running phase, and a host-side data parsing phase. During the compilation phase, an automated script is used to insert stub code into the firmware code file. The stub includes a file index, a total number of functions, a specific header file, and a macro definition. At the same time, the Makefile is modified to support automatic insertion, compilation, and cleanup of stubs. For example, by adding a COV parameter switch to the Makefile, defining the targets for instrumentation, compilation, and cleanup, and calling the automated script in the target rule, the coverage statistics process is automated.

[0071] During the firmware's runtime phase, the firmware defines a data structure for recording information such as line numbers and execution counts, file indexes, and counter array addresses. It also implements a statistical function to accumulate the execution counts of each line of code, enabling accurate recording of code execution during runtime. Furthermore, this application defines an NVMe (Non-Volatile Memory Express) Vendor Admin Command format containing specific fields for efficiently exporting statistical data or clearing historical records between the host and the firmware, ensuring the accuracy of the statistical data.

[0072] To accurately monitor code execution, this application proposes a specialized data structure and statistical function to record the number of code executions during execution. This not only counts conditional branch statements (such as if / else if / else / case) individually, but also records the number of function calls at function entry, thereby enabling coverage collection for different execution paths and function call scenarios.

[0073] On the host side, the exported statistics are read through collaborative parsing scripts to generate detailed reports containing file execution status, analyze executed and unexecuted code lines, and calculate the execution coverage of each file. This includes the automated insertion of stubs during the compilation phase, which improves operational efficiency and ease of use. Efficient data interaction based on the NVMe protocol ensures the reliability of statistical data transmission. Precise data structures and statistical functions achieve the accuracy of coverage statistics. In addition, the collaborative parsing of multiple scripts on the host side provides comprehensive reports, providing reliable data support for firmware testing evaluation and version iteration. The NVMe protocol is a communication protocol designed specifically for high-speed solid-state drives based on the PCIe (Peripheral Component Interconnect Express) bus.

[0074] The firmware code coverage statistics method of the embodiment of the present application responds to the build command and calls the automated script to insert the stub code into the firmware code. The stub includes the file index, the statistical function and the macro definition, wherein the first array created by the macro definition records the code line number and the number of executions, and the second array records the file index, the upper limit of the line number and the first array address; when the firmware code is run, the statistical function is called at the stub, the executed code is counted according to the array, and the coverage is calculated in combination with the total code. Therefore, it can solve the problem that the related technology occupies a large amount of storage and memory and affects the running performance, and achieves the technical effect of reducing the firmware resource occupation without affecting the firmware running performance.

[0075] The present application also provides a firmware code coverage statistics device. In order to enable technicians in this technical field to better understand the present application solution, the present application is further described in detail below in conjunction with the accompanying drawings and specific implementation methods.

[0076] Figure 4 A schematic diagram of a firmware code coverage statistics device provided in an embodiment of the present application is shown in FIG. Figure 4 As shown, the firmware code coverage statistics device 10 includes: a calling module 100, a statistics module 200 and a calculation module 300.

[0077] Among them, the calling module 100 is used to respond to the first script construction command and call the automation script to insert the stub code in the firmware code file, wherein the stub code includes a file index, a statistical function and a macro definition, and a first array and a second array are created in the macro definition. The first array is used to record the code line number and the number of executions, and the second array is used to record the file index, the line number limit and the address of the first array; the statistical module 200 is used to run the firmware code file, and when it is recognized that the firmware code file runs to the insertion position of the stub code, the statistical function in the stub code is called, and the statistical function counts the executed code in the firmware code file according to the first array and the second array; the calculation module 300 is used to obtain the total code of the firmware code file, and calculate the firmware code coverage of the firmware code file according to the executed code and the total code in the firmware code file.

[0078] In one embodiment of the present application, the calling module 100 is further used to call an automated script to copy the folder of the stub code as a backup folder; insert the stub code into the firmware code file, and compile the firmware code file after the insertion is completed. If the firmware code file compilation fails, the compilation process of the firmware code file is terminated; after the firmware code file is compiled, the folder of the stub code is compressed.

[0079] In one embodiment of the present application, after calling the automated script to copy the folder of the stub code as a backup folder, the cleaning module is further used to respond to the second script construction command, call the automated script to delete the folder of the stub code; and restore the backup file to the folder of the stub code.

[0080] In one embodiment of the present application, before restoring the backup file to a folder of stub code, the detection module is further used to identify whether the backup file is damaged or does not exist; if the backup file is damaged or does not exist, at least one of an error message and a manual processing prompt is generated; if the backup file exists and is not damaged, the backup file is restored to a folder of stub code.

[0081] In one embodiment of the present application, script call parameters are added to the first script construction command and the second script construction command, wherein when the script construction command is executed, the automation script is called based on the script call parameters.

[0082] In one embodiment of the present application, the statistical module 200 is further used to obtain the current file index and the current code line number; query the second array according to the current file index; if no matching file index is found in the second array, a warning message is generated; if a matching file index is found in the second array, the address of the first array is obtained from the second array, and the first array is linked according to the address of the first array; query the first array based on the line number limit and the current code line number, if a matching code line number is found from the first array, the number of executions of the current code line number is accumulated; if no matching code line number is found from the first array, a warning message is generated.

[0083] In one embodiment of the present application, the accumulation module is further used to query whether the execution count of the target line number is recorded in the first array before generating a warning message if no matching code line number is found from the first array; if the execution count of the target line number is recorded in the first array, the execution count of the target line number is written into the current code line number, and the execution count of the current code line number is accumulated; if the execution count of the target line number is not recorded in the first array, a warning message is generated.

[0084] In one embodiment of the present application, the export module is further used to obtain a first interactive command before calculating the firmware code coverage of the firmware code file based on the executed code and the total code in the firmware code file, wherein the first interactive command is defined by the management command; in response to the first interactive command, the area data of the first array and the area data of the second array are exported, and the executed code in the firmware code file is determined based on the exported data.

[0085] In one embodiment of the present application, the export module is further used to obtain a second interactive command before calculating the firmware code coverage of the firmware code file based on the executed code and the total code in the firmware code file, wherein the second interactive command is defined by the management command; in response to the second interactive command, clear the corresponding file data in the firmware code file.

[0086] For the description of the features in the embodiment corresponding to the above-mentioned firmware code coverage statistics device, please refer to the relevant description of the embodiment corresponding to the firmware code coverage statistics method, which will not be repeated here.

[0087] The firmware code coverage statistics device of the embodiment of the present application responds to the build command and calls the automated script to insert the stub code into the firmware code. The stub includes the file index, the statistical function and the macro definition. The first array created by the macro definition records the code line number and the number of executions, and the second array records the file index, the upper limit of the line number and the first array address. When the firmware code is run, the statistical function is called at the stub, the executed code is counted according to the array, and the coverage is calculated in combination with the total code. Therefore, it can solve the problem that the related technology occupies a large amount of storage and memory and affects the running performance, and achieves the technical effect of reducing the firmware resource occupation without affecting the firmware running performance.

[0088] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0089] An embodiment of the present application further provides an electronic device, including a memory 501 and a processor 502, wherein the memory 501 stores a computer program, and the processor 502 is configured to run the computer program to execute the steps in the above-mentioned firmware code coverage statistics method embodiment.

[0090] The present application also provides a non-volatile computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of the above-mentioned firmware code coverage statistics method are implemented.

[0091] The present application also provides a computer program product, including a computer program, which implements the steps of the above-mentioned firmware code coverage statistics method when executed by a processor.

[0092] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0093] The above is a detailed introduction to a firmware code coverage statistics method and electronic device provided by this application. This article uses specific examples to illustrate the principles and implementation methods of this application. The description of the above embodiments is only applicable to help understand the method and core ideas of this application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of this application, several improvements and modifications can be made to this application, and these improvements and modifications also fall within the scope of protection of the claims of this application.

Claims

1. A firmware code coverage statistics method, characterized in that: include: In response to a first script construction command, calling an automated script to insert stub code into a firmware code file, wherein the stub code includes a file index, a statistical function, and a macro definition, wherein a first array and a second array are created in the macro definition, wherein the first array is used to record a code line number and an execution count, and the second array is used to record a file index, a line number limit, and an address of the first array; running the firmware code file, and when recognizing that the firmware code file runs to the insertion position of the stub code, calling a statistical function in the stub code, wherein the statistical function counts the executed code in the firmware code file according to the first array and the second array; The total code of the firmware code file is obtained, and the firmware code coverage of the firmware code file is calculated according to the executed code in the firmware code file and the total code.

2. The firmware code coverage statistics method according to claim 1, characterized in that: The calling of the automation script to insert the stub code into the firmware code file includes: Call the automation script to copy the folder of the stub code as a backup folder; Inserting a stub code into the firmware code file, compiling the firmware code file after the insertion is completed, and terminating the compilation process of the firmware code file if the compilation of the firmware code file fails; After the firmware code file is compiled, the folder of the stub code is compressed.

3. The firmware code coverage statistics method according to claim 2, characterized in that: After calling the automation script to copy the folder of the stub code as a backup folder, the method further includes: In response to the second script construction command, calling the automation script to delete the folder of the stub code; Restore the backup file to the folder of the stub code.

4. The firmware code coverage statistics method according to claim 3, characterized in that: Before restoring the backup file to the folder of the stub code, the method further includes: Identify whether the backup file is damaged or does not exist; If the backup file is damaged or does not exist, generating at least one of an error message and a manual processing prompt; If the backup file exists and is not damaged, the backup file is restored to the folder of the stub code.

5. The firmware code coverage statistics method according to claim 3, characterized in that: Script call parameters are added to the first script construction command and the second script construction command, wherein when the script construction command is executed, the automation script is called based on the script call parameters.

6. The firmware code coverage statistics method according to claim 1, characterized in that: The statistical function counts the executed codes in the firmware code file according to the first array and the second array, including: Get the current file index and current code line number; querying the second array according to the current file index; If no matching file index is found in the second array, a warning message is generated; If a matching file index is found in the second array, the address of the first array is obtained from the second array, and the first array is linked according to the address of the first array; Querying the first array based on the line number limit and the current code line number, and if a matching code line number is found in the first array, accumulating the number of executions of the current code line number; If no matching code line number is found from the first array, a warning message is generated.

7. The firmware code coverage statistics method according to claim 6, characterized in that: If no matching code line number is found from the first array, before generating a warning message, the following steps are also included: Check whether the first array records the number of executions of the target line number; If the execution count of the target line number is recorded in the query of the first array, the execution count of the target line number is written into the current code line number, and the execution count of the current code line number is accumulated; If the execution count of the target row number is not found in the first array, a warning message is generated.

8. The firmware code coverage statistics method according to claim 1, characterized in that: Before calculating the firmware code coverage of the firmware code file based on the executed code and the total code in the firmware code file, the method further includes: Acquire a first interaction command, wherein the first interaction command is defined by a management command; In response to the first interactive command, the region data of the first array and the region data of the second array are exported, and the executed code in the firmware code file is determined according to the exported data.

9. The firmware code coverage statistics method according to claim 1, characterized in that: Before calculating the firmware code coverage of the firmware code file based on the executed code and the total code in the firmware code file, the method further includes: Acquire a second interaction command, wherein the second interaction command is defined by a management command; In response to the second interactive command, corresponding file data in the firmware code file is cleared.

10. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the firmware code coverage statistics method according to any one of claims 1 to 9 when executing the computer program.

Images