Firmware code coverage statistics method and electronic device

Abstract

The application discloses a firmware code coverage statistics method and electronic equipment, and relates to the technical field of program detection, and comprises the following steps: responding to a first script construction command, calling an automatic script to insert a stub point code in a firmware code file, and the stub point code comprising a file index, a statistics function and a macro definition; wherein, a first array created by the macro definition records a code line number and an execution frequency, a second array created by the macro definition records a file index, a line number limit value and a first array address; when executing the firmware code file, the statistics function is called when executing the stub point position, the statistics function counts the executed code in the firmware code file according to the first array and the second array, and the firmware coverage is calculated by combining the executed code with the total code of the firmware code file, thereby solving the problems that the related art occupies a large amount of storage and memory and affects the running performance, and achieving the technical effects of reducing the firmware resource occupation and not affecting the firmware running performance.

Description

Technical Field

[0001] This application relates to the field of program detection technology, and in particular to a firmware code coverage statistical method and an electronic device. Background Technology

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

[0003] Currently, the relevant technologies have significant shortcomings in the field of firmware code coverage statistics: on the one hand, some tools can only provide basic block coverage, which is complex and inefficient; on the other hand, although some tools support more refined metrics such as branch coverage and conditional coverage, they are prone to code bloat during instrumentation, increasing storage and memory overhead, and are difficult to implement in resource-constrained firmware environments. Summary of the Invention

[0004] This application provides a firmware code coverage statistics method and an electronic device to at least solve the problem of excessive storage and memory consumption and impact on operating performance when performing firmware code coverage statistics in related technologies.

[0005] This application provides a firmware code coverage statistics method, comprising: responding to a first script build 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 the macro definition creates a first array and a second array, the first array being used to record code line numbers and execution counts, and the second array being used to record file indexes, line number limits, and the address of the first array; running the firmware code file, and when the firmware code file is identified to have reached the insertion position of the stub code, calling the statistical function in the stub code, the statistical function calculating the executed code in the firmware code file based on 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 based on the executed code and the total code in the firmware code file.

[0006] This application provides a firmware code coverage statistics device, comprising: a calling module, used to respond to a first script build command and call 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 the macro definition creates a first array and a second array, the first array being used to record code line numbers and execution counts, and the second array being used to record the file index, line number limits, and the address of the first array; a statistics module, used to run the firmware code file, and when the firmware code file is run to the insertion position of the stub code, call the statistical function in the stub code, the statistical function counting the executed code in the firmware code file according to the first array and the second array; and a calculation module, 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] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the above-described firmware code coverage statistics method when executing the computer program.

[0008] This application also provides a non-volatile computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the above-described firmware code coverage statistics method.

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

[0010] This application addresses the issue of related technologies consuming excessive storage and memory, impacting performance, by invoking an automated script to insert stub code into the firmware code in response to a build command. The stub code includes a file index, statistical functions, and macro definitions. The first array created by the macro definitions records the line number and execution count, while the second array records the file index, line number limit, and the address of the first array. When the firmware code runs, execution reaches the stub, invoking the statistical functions. The executed code is statistically analyzed using the arrays, and the coverage rate is calculated based on the total code. Therefore, this approach solves the problem of related technologies consuming large amounts of storage and memory, thus reducing firmware resource consumption without affecting firmware performance. Attached Figure Description

[0011] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1This is a schematic diagram of a firmware code coverage statistics method provided in an embodiment of this application;

[0013] Figure 2 A flowchart of automated analysis of firmware code coverage statistics is provided for embodiments of this application;

[0014] Figure 3 The flowchart of the firmware code coverage statistics function execution provided in the embodiments of this application;

[0015] Figure 4 A schematic diagram of the firmware code coverage statistics device provided in the embodiments of this application;

[0016] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

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

[0019] To enable those skilled in the art to better understand the present application, the following description is provided in conjunction with the appendix. Figure 1 The present application will be further described in detail with reference to specific embodiments.

[0020] Figure 1 This is a schematic diagram of the structure of a firmware code coverage statistics method provided in an embodiment of this application, as shown below. Figure 1 As shown, this firmware code coverage statistics method includes the following steps:

[0021] In step S101, in response to the first script build command, an automated script is invoked to insert stub code into the firmware code file. The stub code includes a file index, statistical functions, and macro definitions. The macro definitions create a first array and a second array. The first array is used to record the code line number and execution count, and the second array is used to record the file index, line number limit, and address of the first array.

[0022] The first script is an automated script for instrumenting firmware code. Statues are additional code inserted into firmware code files to collect coverage statistics during firmware runtime. File indexes are unique identifiers for each firmware code file in the firmware project, used to distinguish data sources from different files during coverage statistics. Statistical functions are functions called by the statues; during firmware runtime, they accumulate the count value corresponding to the current execution position and store it in a specified data structure. Macro definitions are macros declared using the C language preprocessor directive `#define`, used during the compilation phase to automatically expand into the data structures, array declarations, and statistical function calls required for statues, thereby quickly generating coverage collection code in the firmware code and avoiding manual writing. The first array is a `file_coverage_cnt_t` type array used to store firmware code line-level coverage statistics; array elements contain line numbers and their corresponding execution counts. Line numbers are the position numbers of each statement or line of code in the firmware code, used to count the number of executions. The second array is a `file_coverage_cfg_t` array used to store file-level code coverage configuration information. Array elements include the file index, line number limit, and the address of the first array corresponding to that file. The file index is a unique identifier used to associate each file with its corresponding statistical data in coverage statistics, ensuring that line-level execution counts are correctly recorded in the corresponding file's array. The line number limit restricts the maximum number of lines of code that can be recorded in the first array, preventing out-of-bounds access.

[0023] It is understandable that by inserting stub code into the firmware code file, this embodiment of the application can automatically collect code coverage data during firmware operation, achieving precise tracking of firmware code execution. Specifically, the first array records the line number of each line of code and its corresponding execution count, thereby obtaining line-level coverage information; the second array stores the file index, line number limits, and the address of the first array corresponding to that file. Defining line number limits restricts the statistical range, prevents invalid access and array out-of-bounds errors, and improves the query security of the statistical function. This enables grouping and accurate positioning of different firmware code coverage data, ensuring that the statistical process does not confuse the execution status of different files. Simultaneously, the statistical function is dynamically called during firmware runtime, continuously accumulating the execution count in the first array to ensure the integrity and accuracy of the coverage data.

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

[0025] The automation script is a program used to perform firmware code instrumentation, backup, compilation, and compression operations. These operations can be automated by calling the script. The stub code file is the original, uninstrumented firmware code file. The backup folder is generated by the automation script copying the stub code folder before instrumentation and is used to restore the original firmware code in case of stub insertion or compilation failure. Compilation is the process of processing the instrumented firmware code file, including syntax checking and generating object files, to produce an executable firmware file. Compression packages the instrumented firmware code folder into a compressed file for archiving and subsequent analysis.

[0026] Understandably, the automated script can copy the folder containing the stub code to create a backup folder before instrumentation, ensuring that the original code can be restored in case of instrumentation or compilation failure; it can 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 will be automatically terminated to avoid the generation of erroneous firmware; after compilation, the folder containing the instrumented stub code will be compressed and saved for easy archiving, management, and subsequent coverage analysis.

[0027] The first script build command in this embodiment is completed collaboratively by an automated script and a Makefile configuration. It is used to insert stub code into the firmware code to achieve coverage data collection. When the "make" command is executed with the parameter "COV=1", the Makefile will call the automated script to start the instrumentation 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 invocation of the automated script and the compilation, instrumentation, and cleanup of the firmware code.

[0028] Specifically, firstly, the first script copies the folder containing the stub code to create a backup folder, used to restore the original code in case of exceptions during instrumentation or compilation. Then, the first script processes the target C files, inserting stub code into each file, specifically including:

[0029] 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 with the COV_ENTRY macro definition inserted in the current firmware code file; include necessary header files to ensure the availability of statistical functions and data structures. The macro definitions generate unique variable names by concatenating parameters and place the variables in the specified memory segment so that statistical functions can access them quickly, achieving automatic generation of line-level coverage statistics code.

[0030] After insertion, the script compiles the firmware code file to verify that the instrumented code can correctly generate executable firmware. If a C file format error or other exception occurs during compilation, the script will output an error message and terminate the compilation process, prompting the user to repair it to ensure the normal execution of subsequent processes. Finally, the script compresses the folder containing the inserted instrumentation points into a ZIP file for easy archiving and management.

[0031] In one embodiment of this application, after calling the automated script to copy the folder containing the stub code as a backup folder, the method further includes: responding to a second script build command, calling the automated script to delete the folder containing the stub code; and restoring the backup files to the folder containing the stub code.

[0032] The second script is an automated operation script used to delete inserted stub code and restore the backup folder. Restoration involves copying the backup files back to their original location to restore the stub code folder to its previous state, thus completing the instrumentation cleanup and recovery operation.

[0033] It is understood that, in response to the second script build command, this application embodiment calls an automated script to delete the folder containing inserted stub code and restores the backup file to the original stub code folder. This achieves safe cleanup and rapid recovery of the instrumented code, enabling the restoration of the original state through backup files when anomalies occur during firmware code instrumentation or compilation, ensuring the integrity and stability of the stub code. Simultaneously, the automated script uniformly performs the deletion and restoration operations, allowing backup files to be reused, thereby improving testing efficiency and simplifying the operation process.

[0034] The second script build command in this embodiment is jointly completed by an automated script and a Makefile configuration, and is used for the firmware code cleanup process. When the "make DCOV=1" command is executed, the Makefile calls the corresponding automated script to start the cleanup operation.

[0035] First, the script deletes the folder containing the stub code for inserted stubs to clean up the instrumentation data. Then, the script restores the backup folder generated before instrumentation to its original location to restore the original firmware code state. Furthermore, the cleanup process does not process compressed ZIP files. A ZIP file is a compressed file format used to package and compress one or more files or folders to reduce storage space or facilitate transfer.

[0036] In one embodiment of this application, before restoring the backup file to the folder of stub codes, the method further includes: identifying whether the backup file is corrupted or does not exist; if the backup file is corrupted 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 corrupted, restoring the backup file to the folder of stub codes.

[0037] Understandably, when the backup file is abnormal, the automated script promptly prompts the user to repair or manually intervene, avoiding direct restoration that could result in incomplete or damaged stub code. When the backup file exists and is intact, the embodiments of this application can quickly restore the original stub code state, providing a reliable foundation for subsequent instrumentation, compilation, or coverage analysis.

[0038] Specifically, before restoring the backup files to the stub code folder, the second script first checks whether the backup files exist or are corrupted to avoid incomplete stubs or abnormal coverage statistics due to missing or corrupted backup files. If the backup folder is detected to be missing or corrupted, this embodiment performs at least one of the following operations: generating an error message to inform the user of the abnormal situation, or providing manual handling prompts to guide the user to take appropriate measures (such as regenerating the backup files or repairing the corrupted files). If the backup files exist and are not corrupted, a restore operation is performed to restore the backup files to the original stub code folder, restoring the firmware stubs to their state before instrumentation.

[0039] In one embodiment of this application, script call parameters are added to the first script building command and the second script building command, wherein when the script building command is executed, an automated script is called based on the script call parameters.

[0040] Understandably, firmware stubbing operations can be automated by invoking automated scripts based on script call parameters during the execution of script build commands. This allows for flexible triggering of processes such as instrumentation, cleanup, backup, or compression based on different parameters, avoiding the tediousness and errors of manual operations.

[0041] The automated method for code coverage analysis in software testing according to embodiments of this application has the following process: Figure 2 As shown, it includes the following steps:

[0042] In step S201, the user executes the command "make COV=1" to trigger the predefined operation process in the Makefile. By adding the "COV=1" parameter, the Makefile can recognize and call the corresponding automated script to start code coverage statistics and instrumentation operations.

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

[0044] In step S203, to ensure the integrity of the stub code, the first script first copies the entire stub code folder, generating a copy named "xx_copy". All subsequent instrumentation, modification, and compilation operations are performed on this copy, thereby avoiding direct impact on the original code. This also facilitates rapid restoration of the firmware code to its original state in case of anomalies, ensuring the safety and reliability of the operation.

[0045] In step S204, the script iterates through all C 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, ensuring that line-level coverage information can be obtained.

[0046] In step S205, after instrumenting all C files, the script calls a compilation toolchain, such as GCC (GNU Compiler Collection), to compile the firmware code in the copy, generating an instrumented executable file. This executable file can dynamically collect coverage information during runtime, including the execution count and execution status of each line of code, providing data for program analysis, debugging, and performance evaluation.

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

[0048] In step S102, the firmware code file is run. When the firmware code file reaches the insertion position of the stub code, the statistical function in the stub code is called. The statistical function counts the executed code in the firmware code file based on the first array and the second array.

[0049] Understandably, by identifying the location of the stub code during firmware code execution and calling the statistics function, the execution status of the firmware code can be recorded in real time, accurately collecting the execution count of each line of code, and achieving line-level and file-level coverage statistics.

[0050] In one embodiment of this application, the statistical function counts the executed code in the firmware code file based on a first array and a 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 in the first array, accumulating the execution count of the current code line number; if no matching code line number is found in the first array, generating a warning message.

[0051] Understandably, by using statistical functions to track the execution of firmware code according to the first and second arrays, the execution count of each line of code in each file can be accurately recorded. When a mismatch is found in the file index or line number during the statistical process, a warning message is generated, indicating potential issues such as incorrect instrumentation or firmware code changes. This helps identify executed and non-executed lines of code.

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

[0053] The counting function first iterates through the second array to find the 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 that array element, and the corresponding counting array is accessed based on that address.

[0054] Next, the system searches the first array for the element that matches the current line number and increments the execution count of that line of code. There is an upper limit to the number of executions; once exceeded, the count stops increasing. For example, the upper limit for the number of executions of a line of code might be 65535. When the cumulative execution count of a 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.

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

[0056] In one embodiment of this application, before generating a warning message if no matching line number is found in the first array, the method further includes: querying whether the first array records the execution count of the target line number; if the first array records the execution count of the target line number, the execution count of the target line number is written to the current line number, and the execution count of the current line number is accumulated; if the first array does not record the execution count of the target line number, a warning message is generated.

[0057] Understandably, by first checking whether the execution count of the target line number already exists in the first array, it can be ensured that the execution count of the current line number is accumulated based on existing data, avoiding duplicate counting or omissions. If the target line number already has a record, this embodiment will write its execution count into the current line number and accumulate it, ensuring that the statistical data will not be lost when executed multiple times or at different instrumentation positions. When no record of the target line number is found in the first array, a warning message will be generated to remind developers that there may be problems such as missing instrumentation, array fullness, or data abnormality, which helps to discover and handle potential errors as early as possible.

[0058] Figure 3 This document illustrates the execution logic and related processing flow of the statistical function during code coverage statistics in this embodiment. The overall process begins with a function call, determines the corresponding data location using file index and line number, and ultimately accumulates the number of code executions. A warning message is output when a matching record cannot be found.

[0059] The process begins in step S301, first calling a statistical function that takes the file index and line number as input for subsequent statistical processing. Then, in step S302, the second array, which stores file-related information, is traversed to match the target file index. In step S303, it is determined 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 obtained in step S304 for subsequent line number matching and counting operations.

[0060] Next, in step S305, the first array is traversed, which records the specific code line number and its execution count. In step S306, it is determined whether a record matching the target line number has been found. If it is found, in step S307, the address of the line number in the first array is directly obtained, and in step S308, its execution count is incremented (the maximum cumulative value is 65535).

[0061] If no matching row number is found, step S309 further determines whether there is a record with row number 0. If it is a jump row number, the current row number is written into the array in step S310, and the process jumps to step S308 to perform a counting accumulation operation; if there is no record with row number 0, it means that a counting position cannot be assigned to the current row number, and this embodiment of the application will output a warning message and return.

[0062] In this embodiment, the corresponding file is found by traversing the second array, and the corresponding line number is found by traversing the first array. The number of executions is then incremented based on whether the line number is a jump marker, thereby achieving accurate statistics on the execution status of the firmware code.

[0063] 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 based on the executable code and the total code in the firmware code file.

[0064] Firmware code coverage is used to measure the completeness of firmware testing, and is usually expressed as the percentage of executed code out of the total code.

[0065] Understandably, by obtaining the total code in the firmware code file and calculating the coverage based on the actual lines of code executed, test coverage can be accurately assessed and unexecuted code regions can be identified.

[0066] In one embodiment of this application, before calculating the firmware code coverage of the firmware code file based on the executable code and the total code in the firmware code file, the method further includes: obtaining a first interactive command, wherein the first interactive command is defined by a management command; responding to the first interactive command, exporting a first array of region data and a second array of region data, and determining the executable code in the firmware code file based on the exported data.

[0067] The first interactive command is a command sent by the host to export firmware statistics.

[0068] Understandably, by acquiring and responding to the first interactive command, the region data of the first and second arrays can be exported from the firmware, thereby determining the actual execution status of the firmware code file, accurately quantifying test coverage, and identifying uncovered code regions.

[0069] The host sends a command to export firmware statistics. The export and clearing of statistics are achieved 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 system selects to export region data from the first and second arrays based on the values ​​specified in the command, and determines the size and range of the exported data by combining other parameters in the command. After receiving the command, the firmware returns the data for the corresponding region to the host. The host then reads the statistical results through a parsing script, generates a report containing relevant information, counts unexecuted lines of code, and calculates the execution coverage for each file.

[0070] In one embodiment of this application, before calculating the firmware code coverage of the firmware code file based on the executable code and the total code in the firmware code file, the method further includes: obtaining a second interactive command, wherein the second interactive command is defined by a management command; and responding to the second interactive command by clearing the corresponding file data in the firmware code file.

[0071] The second interactive command is a command sent by the host to clear firmware statistics records.

[0072] Understandably, by obtaining and responding to the second interactive command to clear the corresponding statistical data in the firmware code file, it is possible to ensure that the coverage statistics are 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.

[0073] During the record clearing phase, the host sends a command to clear firmware statistics records. Different clearing operations are performed based on the values ​​specified in the command, including clearing statistics records for all files, clearing all statistics records for a specified file, or clearing statistics records for a specific line number in a specified file. If the command format does not conform to the definition, an error will be triggered in this embodiment.

[0074] Through the first and second interactive commands, the host and firmware can accurately export and clear statistical data as needed.

[0075] In one embodiment of this application, calculating the firmware code coverage of a firmware code file based on the executable code and the total code in the firmware code file includes: inputting the executable code and the total code in the firmware code file into a parsing module on the host side; the parsing module calculates the firmware code coverage of the firmware code file collaboratively 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 statistical results; the second parsing script performs statistics on stubs; the third parsing script reads data from the first and second parsing scripts it contains, calculates unexecuted code, and calculates the firmware code coverage of the firmware code file based on the executable code and the total code in the firmware code file.

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

[0077] Understandably, by inputting the actual executed code and the total code in the firmware code file into the host-side parsing module, and using multiple parsing scripts to collaboratively calculate coverage, the execution status of each firmware code file can be accurately obtained, clearly identifying the executed and unexecuted lines of code.

[0078] This application embodiment achieves coverage statistics through the collaboration of multiple parsing scripts. Specifically, the first parsing script reads the firmware statistical results through an interface and parses them to generate a JSON (JavaScript Object Notation) format file containing information such as file index, line number, and reference count. The second parsing script summarizes and statistically analyzes all inserted stub data. The third parsing script analyzes the unexecuted lines of code based on the information generated by the first and second parsing scripts and generates corresponding files, while simultaneously calculating the execution coverage of each file. If the data export format is not compliant or incomplete, the script will output error messages to indicate an exception.

[0079] In summary, this application discloses a firmware code coverage statistics method based on code instrumentation. The overall process includes a compilation phase, a firmware runtime phase, and a host-side data parsing phase. During the compilation phase, stub code is inserted into the firmware code file using an automated script. Each stub contains a file index, the total number of functions, specific header files, and macro definitions. Simultaneously, the Makefile is modified to support automatic stub insertion, compilation, and cleanup. For example, by adding a COV parameter switch to the Makefile, the targets for instrumentation, compilation, and cleanup are defined, and the automated script is called within the target rules, thus automating the coverage statistics process.

[0080] During firmware runtime, the firmware internally defines data structures for recording information such as line numbers and execution counts, file indexes, and count array addresses, and implements statistical functions to accumulate the execution counts of each code line, thereby accurately recording code execution status 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 firmware, ensuring the accuracy of the statistical data.

[0081] To achieve precise monitoring of code execution, this application proposes a specialized data structure and statistical functions to record the number of times the code is executed during runtime. It can not only perform individual statistics on conditional branch statements (such as if / else if / else / case), but also record the number of function calls at function entry points, thereby achieving coverage collection of different execution paths and function call patterns.

[0082] On the host side, exported statistical data is read through collaborative parsing scripts to generate detailed reports containing file execution information, analyze executed and non-executed lines of code, and calculate execution coverage for each file. Features include automated insertion of stubs during the compilation phase, improved operational efficiency and ease of use; efficient data interaction based on the NVMe protocol, ensuring reliable transmission of statistical data; precise data structures and statistical functions, ensuring accurate coverage statistics; and comprehensive reports provided by multi-script collaborative parsing on the host side, offering reliable data support for firmware testing, evaluation, and version iteration. The NVMe protocol is a communication protocol specifically designed for high-speed solid-state drives based on the PCIe (Peripheral Component Interconnect Express) bus.

[0083] The firmware code coverage statistics method of this application, in response to a build command, calls an automated script to insert stub code into the firmware code. The stub includes a file index, a statistical function, and macro definitions. The macro definitions create a first array that records the line number and execution count, and a second array that records the file index, the upper limit of the line number, and the address of the first array. When the firmware code runs, the statistical function is called upon the stub, and the executed code is counted based on the array. The coverage is then calculated by combining this with the total code. Therefore, this method can solve the problem of related technologies consuming large amounts of storage and memory and affecting running performance, achieving the technical effect of reducing firmware resource consumption without affecting firmware running performance.

[0084] This application also provides a firmware code coverage statistics device. In order to enable those skilled in the art to better understand the solution of this application, the following detailed description is provided in conjunction with the accompanying drawings and specific embodiments.

[0085] Figure 4 This is a schematic diagram of the structure of a firmware code coverage statistics device provided in an embodiment of this application, as shown below. 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.

[0086] The system includes: a calling module 100, which responds to the first script build command and calls an automated script to insert stub code into the firmware code file; the stub code includes a file index, a statistical function, and a macro definition; the macro definition creates a first array and a second array, the first array records the line number and execution count, and the second array records the file index, line number limit, and the address of the first array; a statistics module 200, which runs the firmware code file and, upon detecting the insertion position of the stub code, calls the statistical function in the stub code; the statistical function uses the first and second arrays to count the executed code in the firmware code file; and a calculation module 300, which obtains the total code in the firmware code file and calculates the firmware code coverage based on the executed code and the total code.

[0087] In one embodiment of this application, the calling module 100 is further used to call an automated script to copy the folder containing the stub code as a backup folder; insert the stub code into the firmware code file; after insertion, compile the firmware code file; if the firmware code file fails to compile, terminate the compilation process of the firmware code file; and after the firmware code file is compiled, compress the folder containing the stub code.

[0088] In one embodiment of this application, after calling the automated script to copy the folder containing the stub code as a backup folder, the cleanup module is further used to respond to the second script build command, call the automated script to delete the folder containing the stub code, and restore the backup files to the folder containing the stub code.

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

[0090] In one embodiment of this application, script call parameters are added to the first script building command and the second script building command, wherein when the script building command is executed, an automated script is called based on the script call parameters.

[0091] In one embodiment of this application, the statistics module 200 is further configured to obtain the current file index and the current line number; query the second array based on 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 based on the address of the first array; query the first array based on the line number limit and the current line number; if a matching line number is found in the first array, the execution count of the current line number is incremented; if no matching line number is found in the first array, a warning message is generated.

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

[0093] In one embodiment of this application, the export module is further configured to obtain a first interactive command before calculating the firmware code coverage of the firmware code file based on the executable code and the total code in the firmware code file, wherein the first interactive command is defined by a management command; in response to the first interactive command, export a first array of region data and a second array of region data, and determine the executable code in the firmware code file based on the exported data.

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

[0095] For a description of the features applied to the aforementioned firmware code coverage statistics device in the corresponding embodiment, please refer to the relevant description of the firmware code coverage statistics method in the corresponding embodiment, which will not be repeated here.

[0096] The firmware code coverage statistics device of this application embodiment, in response to a build command, calls an automated script to insert stub code into the firmware code. The stub includes a file index, a statistical function, and a macro definition. The macro definition creates a first array that records the code line number and execution count, and a second array that records the file index, the upper limit of the line number, and the address of the first array. When the firmware code is run, the statistical function is called when the stub is reached. The executed code is counted according to the array, and the coverage is calculated by combining it with the total code. Therefore, it can solve the problem of related technologies occupying a lot of storage and memory and affecting running performance, and achieve the technical effect of reducing firmware resource consumption without affecting firmware running performance.

[0097] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0098] Embodiments of this application also provide 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 perform the steps in the above-described firmware code coverage statistics method embodiments.

[0099] This application also provides a non-volatile computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the above-described firmware code coverage statistics method.

[0100] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described firmware code coverage statistics method.

[0101] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can 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.

[0102] The firmware code coverage statistics method and electronic device provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for calculating firmware code coverage, characterized in that, include: In response to the first script build command, an automated script is invoked to insert stub code into the firmware code file. The stub code includes a file index, a statistical function, and a macro definition. The macro definition creates a first array and a second array. The first array is used to record the code line number and the number of executions. The second array is used to record the file index, the line number limit, and the address of the first array. When the firmware code file is run and the insertion point of the stub code is detected, a statistical function in the stub code is called. This 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 line number; querying the second array based on 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 based on the address; querying the first array based on the line number limit and the current line number; if a matching line number is found in the first array, the execution count of the current line number is incremented; if no matching line number is found in the first array, a warning message is generated. Obtain the total code of the firmware code file, and calculate the firmware code coverage of the firmware code file based on the executable 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 process of calling the automation script to insert stub code into the firmware code file includes: The automated script is invoked to copy the folder containing the stub code as a backup folder; Insert stub code into the firmware code file. After insertion, compile the firmware code file. If the firmware code file fails to compile, terminate the compilation process of the firmware code file. After the firmware code file is compiled, the folder containing the stub code is compressed.

3. The firmware code coverage statistics method according to claim 2, characterized in that, After calling the automated script to copy the folder containing the stub code as a backup folder, the process also includes: In response to the second script build command, an automated script is invoked to delete the folder containing the stub code; Restore the backup files to the folder containing the stub code.

4. The firmware code coverage statistics method according to claim 3, characterized in that, Before restoring the backup files to the folder containing the stub code, the following is also included: Identify whether the backup file is corrupted or does not exist; If the backup file is corrupt or does not exist, at least one of the following will be generated: an error message and a manual handling prompt. If the backup file exists and is not corrupted, then the backup file is restored to the folder containing the stub code.

5. The firmware code coverage statistics method according to claim 3, characterized in that, The first script building command and the second script building command include script call parameters. When the script building command is executed, the automated script is called based on the script call parameters.

6. The firmware code coverage statistics method according to claim 1, characterized in that, If no matching line number is found in the first array, the following steps are included before generating the warning message: Check if the first array records the execution count of the target row number; If the execution count of the target line number is found in the first array, then the execution count of the target line number is written to the current line number, and the execution count of the current line number is accumulated. If the execution count of the target line number is not found in the first array, a warning message will be generated.

7. 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: Obtain the first interactive command, wherein the first interactive command is defined by the 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 executable code in the firmware code file is determined based on the exported data.

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: Obtain a second interactive command, wherein the second interactive command is defined by the management command; In response to the second interactive command, the corresponding file data in the firmware code file is cleared.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the firmware code coverage statistics method of any one of claims 1 to 8 when executing the computer program.

Images