Precise interrupt-driven embedded software data race dynamic detection method

Abstract

The application discloses a precise interrupt-driven embedded software data race dynamic detection method, comprising the following steps: step one, obtaining a candidate synchronization operation set; step two, screening the candidate synchronization operation; step three, verifying the accuracy of the synchronization operation; and step four, detecting the data race in the program. Compared with the existing data race dynamic detection method, the application can accurately detect the data race in the program by identifying the synchronization operation in the interrupt program, solve the problem that the existing method cannot identify the self-defined synchronization operation in the interrupt program, and cause a large number of false positives in the data race detection, refine the data race detection result, and improve the reliability of the interrupt-driven embedded software. The application can effectively improve the accuracy of the interrupt program data race defect detection by adopting the dynamic and static combination mode for the synchronization operation identification, improve the software development and test efficiency, and improve the safety of the software.

Description

Technical Field

[0001] This invention relates to the field of software defect detection technology, specifically to a precise method for dynamic detection of data contention in interrupt-driven embedded software. Background Technology

[0002] Interrupt-driven programs are widely used in safety-critical fields such as aerospace, aviation, automotive electronics, and medical equipment. This type of software introduces interrupt mechanisms to control I / O devices in real-time to respond to external tasks. Since most of its critical calculations or functions are initiated or processed through interrupts, a large number of complex, interleaved execution sequences are generated during software runtime, making data races highly likely. A data race occurs when program execution involves two accesses to the same memory location, one of which is a write, and the two accesses are not ordered according to the happens-before relationship. Data races can lead to serious concurrency defects, causing various system failures and even serious security problems.

[0003] Currently, the most common strategy used in data competition detection is dynamic detection. Traditional methods of dynamic competition detection typically reveal defects by repeatedly executing the program to obtain specific execution intervals. Because it is based on real program execution sequences, it often has high accuracy.

[0004] Many methods exist for dynamically detecting data races in multithreaded programs, but these methods are not applicable to interrupt-driven programs. This is because over 90% of synchronization in interrupt routines uses custom synchronization via flag variables, which is fundamentally different from multithreaded programs. Synchronization is fundamental to ensuring the correctness and performance of concurrent programs. Synchronization operations typically involve a happens-before relationship; identifying synchronization operations allows us to determine whether operations can occur concurrently. Incorrect or incomplete synchronization identification severely limits the effectiveness of concurrent program analysis tools. Custom synchronization in interrupt routines is difficult to identify, further complicating the happens-before relationships of memory accesses and leading to a large number of false positives in the detection results. Summary of the Invention

[0005] The purpose of this invention is to provide an accurate dynamic detection method for data contention in interrupt-driven embedded software, in order to solve the problem that the existing methods mentioned in the background art cannot identify custom synchronization operations in interrupt programs, resulting in a large number of false alarms in data contention detection.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a precise interrupt-driven embedded software data contention dynamic detection method, comprising the following steps: Step 1, obtaining a set of candidate synchronization operations; Step 2, filtering candidate synchronization operations; Step 3, verifying the accuracy of the synchronization operations; Step 4, detecting data contention in the program;

[0007] In step one above, based on the characteristics of synchronization operations in interrupt-driven programs, static analysis is performed on the program to be processed to identify candidate synchronization operations and generate a set of candidate synchronization operations.

[0008] In step two above, the program to be processed is dynamically executed and the execution sequence is collected. Based on the execution sequence and the candidate synchronization operation set, unsupervised reasoning is performed to filter candidate synchronization operations.

[0009] In step three above, before / after the candidate synchronization operation selected in step two, the corresponding interrupt is triggered, and the program is executed again to identify whether the candidate operation is a synchronization operation, thereby verifying the accuracy of the synchronization operation and obtaining the accurate synchronization operation.

[0010] In step four above, based on the synchronization operations identified in step three, the three types of synchronization in the execution sequence—synchronization based on flag variables, interrupt switch, and interrupt entry / exit—are labeled; based on the labeled execution sequence, happens-before relationship analysis is performed on the access of shared variables in different processes, and data races in the program are detected.

[0011] Preferably, step one specifically includes the following steps:

[0012] 1.1 By modeling memory access to shared data at various granularities, precise access to data regions is ensured, and shared variables accessed by the main program and interrupts, as well as those accessed by two different interrupts, are identified.

[0013] 1.2 Identify explicit and implicit interrupt switch operations in embedded systems. For explicit operations, consider the standard interrupt switch API; for implicit operations, consider the interrupt switch implemented by registers.

[0014] 1.3 Based on interrupt synchronization features, candidate flag variables are identified in the program, and shared variables that are only assigned the value of constant, or shared variables that are only assigned the value of such variables, are identified as candidate flag variables;

[0015] 1.4 Construct a candidate set of synchronous operations, which consists of interrupt switches, interrupt exit / entry points, and read / write operations of candidate flag variables.

[0016] Preferably, in step 1.3, the interrupt synchronization feature is:

[0017] 1) Synchronization based on flag variables in interrupt routines is only achieved through constant read and write. That is, flag variables in interrupt routines must be shared variables, and their read / write access must be performed on constants. In other words, they are always assigned the value of constants and are always read on constants.

[0018] 2) The value of a flag variable may be passed to other flag variables, which together enable synchronization of shared resource access between the main program and the interrupt or between interrupts.

[0019] Preferably, step two specifically includes the following steps:

[0020] 2.1 The program to be processed is executed dynamically, and the program execution sequence is collected;

[0021] 2.2 Based on the execution sequence generated after execution, a synchronization window is constructed, that is, each pair of conflicting accesses is identified from the execution log and a synchronization window is constructed for them. The synchronization window contains a release window and a get window;

[0022] 2.3 Encode each operation object in the synchronization window as a variable, and its probability value represents the possibility of it being a synchronization operation, thereby refining the candidate synchronization operation set generated in step 1.4 and filtering out candidate synchronization operations that satisfy the inference rules.

[0023] Preferably, in step 2.1, the following information is set according to the test cases during dynamic execution:

[0024] 1) Set the interrupt conditions for the first round of program execution;

[0025] 2) Set program breakpoints to achieve precise memory control and monitoring;

[0026] 3) Set test inputs to achieve coverage and provide sufficient information for synchronous reasoning and competition detection.

[0027] Preferably, in step 2.1, the execution sequence includes the following four types of events:

[0028] 1) The entry / exit points of the main program and ISR;

[0029] 2) Disconnect / shutdown operation;

[0030] 3) Reading / writing candidate flag variables;

[0031] 4) Reading / writing of shared variables other than candidate flag variables.

[0032] Preferably, in step 2.3, the reasoning rule is:

[0033] 1) Write-Release / Read-Acquire: A write operation on a variable will not be an acquire operation, and a read operation on a variable will not release 0;

[0034] 2) Exit - release / Entry - acquire: The exit of an interrupt will not be an acquire, and the entry of an interrupt will not be a release;

[0035] 3) enable-release / disable-acquire: Enabling an interrupt will not be acquired, and disabling an interrupt will not be released;

[0036] 4) "Conflicting" access pairs are usually protected by synchronous operations: For a pair of release windows and get windows, the operations in the release window are r1, r2, ...rn, and the operations in the get window are a1, a2, ...am. There is a high probability that there will be a release operation in the release window and a high probability that there will be a get window in the get window, so as to protect the access pair from conflict.

[0037] 5) Flag variables always appear in pairs: a synchronization based on a flag variable is achieved by a read-write pair of the same flag variable; for synchronization based on a flag variable, if a write to a flag variable is used to release it, then the corresponding acquisition should also come from a read of the same flag variable; that is, if an operation on a variable only appears in one type of window, then that variable is not a flag variable, and its operation is not a synchronization operation.

[0038] 6) The differences in the values ​​of the marker variables will not be too great; in order to achieve synchronization based on the marker variables, the number of values ​​is likely to be 2. Therefore, among all candidate marker variables, the one with the closest number of values ​​to 2 is more likely to be the marker variable.

[0039] 7) Synchronization operations will not occur frequently: Synchronization operations will only occur when necessary, and will not occur frequently in the program.

[0040] Preferably, in step four, the three synchronization methods are as follows:

[0041] 1) For synchronization based on flag variables, write(flag) is marked as rel(flag), and read(flag) is marked as acq(flag);

[0042] 2) For interrupt switches, enable(i) is marked as rel(i), and disable(i) is marked as acq(i);

[0043] 3) For interrupt exits / entries, isri exit(i) is labeled as rel(i), rel(j1), rel(j2), ... rel(jn), and isri entry(i) is labeled as acq(i), acq(j1), acq(j2), ... acq(jn), where the priority of isrj1, isrj2, ..., isrjn is equal to the priority of isri.

[0044] Compared with existing technologies, the beneficial effects of this invention are as follows: Compared with existing dynamic data contention detection methods, this invention accurately detects data contention in programs by identifying synchronization operations in interrupt programs, solving the problem that existing methods cannot identify custom synchronization operations in interrupt programs, leading to a large number of false alarms in data contention detection. This refines the data contention detection results and improves the reliability of interrupt-driven embedded software. Furthermore, by adopting a combination of dynamic and static methods for synchronization operation identification, this invention effectively improves the accuracy of interrupt program data contention defect detection, enhances software development and testing efficiency, and improves software security. Attached Figure Description

[0045] Figure 1 This is a step diagram of the present invention;

[0046] Figure 2 This is a flowchart of the method of the present invention. Detailed Implementation

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

[0048] Please see Figure 1-2 The present invention provides an embodiment of a precise interrupt-driven embedded software data contention dynamic detection method, comprising the following steps: Step 1, obtaining a candidate synchronization operation set; Step 2, filtering candidate synchronization operations; Step 3, verifying the accuracy of synchronization operations; Step 4, detecting data contention in the program.

[0049] In step one above, based on the characteristics of synchronization operations in interrupt-driven programs, static analysis is performed on the program to be processed to identify candidate synchronization operations and generate a set of candidate synchronization operations. This specifically includes the following steps:

[0050] 1.1 By modeling memory access to shared data at various granularities, precise access to data regions is ensured, and shared variables accessed by the main program and interrupts, as well as those accessed by two different interrupts, are identified.

[0051] 1.2 Identify explicit and implicit interrupt switch operations in embedded systems. For explicit operations, consider standard interrupt switch APIs, such as disable_isr(-1) / enable_isr(-1) to control the on / off state of all interrupts. For implicit operations, consider interrupt switches implemented by registers, such as using the interrupt enable register IE in C51 to control interrupts to be enabled or disabled.

[0052] 1.3 Based on interrupt synchronization characteristics, candidate flag variables are identified in the program. Shared variables that are only assigned the value of constant, or shared variables that are only assigned the value of such variables, are identified as candidate flag variables. The interrupt synchronization characteristics are:

[0053] 1) Synchronization based on flag variables in interrupt routines is only achieved through constant read and write. That is, flag variables in interrupt routines must be shared variables, and their read / write access must be performed on constants. In other words, they are always assigned the value of constants and are always read on constants.

[0054] 2) The value of a flag variable may be passed to other flag variables, which together enable synchronization of shared resource access between the main program and the interrupt or between interrupts;

[0055] 1.4 Construct a candidate set of synchronization operations, which consists of interrupt switches, interrupt exit / entry points, and read / write operations of candidate flag variables;

[0056] In step two above, the program to be processed is dynamically executed and the execution sequence is collected. Based on the execution sequence and the candidate synchronization operation set, unsupervised reasoning is performed to filter candidate synchronization operations. Specifically, this includes the following steps:

[0057] 2.1 The program to be processed is executed dynamically, and the program execution sequence is collected; during the dynamic execution process, the following information is set according to the test cases:

[0058] 1) Set the interrupt conditions for the first round of program execution;

[0059] 2) Set program breakpoints to achieve precise memory control and monitoring;

[0060] 3) Set test inputs to achieve coverage and provide sufficient information for simultaneous reasoning and race detection;

[0061] The execution sequence includes the following four types of events:

[0062] 1) The entry / exit points of the main program and ISR;

[0063] 2) Disconnect / shutdown operation;

[0064] 3) Reading / writing candidate flag variables;

[0065] 4) Reading / writing of shared variables other than candidate flag variables;

[0066] 2.2 Based on the execution sequence generated after execution, a synchronization window is constructed. That is, each pair of conflicting accesses is identified from the execution log, and a synchronization window is constructed for them. The synchronization window contains a release window and a get window. For example, if there are conflicting accesses S1 and S2, where S1 occurs before S2 in the execution sequence, S1 occurs in process 1, and S2 occurs in process 2, among the operations that occur between S1 and S2 in the execution sequence, the operations that belong to process 1 and are included in the candidate synchronization operation set constitute the release window, and the operations that belong to process 2 and are included in the candidate synchronization operation set constitute the get window.

[0067] 2.3 Each operation object in the synchronization window is encoded as a variable, and its probability value represents the likelihood that it is a synchronization operation. This refines the candidate synchronization operation set generated in step 1.4, filtering out candidate synchronization operations that satisfy the inference rules. The inference rules are as follows:

[0068] 1) Write-Release / Read-Acquire: A write operation on a variable will not be an acquire operation, and a read operation on a variable will not release 0;

[0069] 2) Exit - release / Entry - acquire: The exit of an interrupt will not be an acquire, and the entry of an interrupt will not be a release;

[0070] 3) enable-release / disable-acquire: Enabling an interrupt will not be acquired, and disabling an interrupt will not be released;

[0071] 4) "Conflicting" access pairs are usually protected by synchronous operations: For a pair of release windows and get windows, the operations in the release window are r1, r2, ...rn, and the operations in the get window are a1, a2, ...am. There is a high probability that there will be a release operation in the release window and a high probability that there will be a get window in the get window, so as to protect the access pair from conflict.

[0072] 5) Flag variables always appear in pairs: a synchronization based on a flag variable is achieved by a read-write pair of the same flag variable; for synchronization based on a flag variable, if a write to a flag variable is used to release it, then the corresponding acquisition should also come from a read of the same flag variable; that is, if an operation on a variable only appears in one type of window, then that variable is not a flag variable, and its operation is not a synchronization operation.

[0073] 6) The differences in the values ​​of the flag variables will not be too great: In order to achieve synchronization based on the flag variables, the number of values ​​is likely to be 2 (e.g., 0xaa and 0x55). Therefore, among all candidate flag variables, the closer the number of values ​​is to 2, the more likely it is to be a flag variable.

[0074] 7) Synchronization operations will not occur frequently: Synchronization operations will only occur when necessary, and will not occur frequently in the program;

[0075] In step three above, before / after the candidate synchronization operations selected in step two, corresponding interrupts are triggered, and the program is executed again to identify whether the candidate operation is a synchronization operation, thereby verifying the accuracy of the synchronization operation and obtaining the precise synchronization operation. For example, if the observation results collected in the first round of execution infer that R is the most likely release operation between conflicting accesses S1 and S2, and R belongs to the main program / low-priority interrupt, while S2 occurs in the interrupt ISR, then in the second execution, the ISR is triggered before R. If S2 still appears normally in the ISR, then R is not a true release operation; if S2 is delayed by one cycle or no longer appears in the ISR, then R is a true release operation. Similarly, if the observation results collected in the first round of execution infer that A is the most likely acquire operation between conflicting accesses S1 and S2, and S1 occurs in the interrupt ISR, while A occurs in the main program / low-priority interrupt, then in the second execution, the ISR is triggered after A. If S2 still appears normally in the main program, then A is not a true acquire operation; if S2 is delayed by one cycle or no longer appears in the ISR, then A is a true acquire operation.

[0076] In step four above, based on the synchronization operations identified in step three, three types of synchronization in the execution sequence are labeled: synchronization based on flag variables, interrupt switch, and interrupt entry / exit. Based on the labeled execution sequence, happens-before relationship analysis is performed on shared variable accesses in different processes, and data races in the program are detected. Specifically, the three types of synchronization are:

[0077] 1) For synchronization based on flag variables, write(flag) is marked as rel(flag), and read(flag) is marked as acq(flag);

[0078] 2) For interrupt switches, enable(i) is marked as rel(i), and disable(i) is marked as acq(i);

[0079] 3) For interrupt exits / entries, isri exit(i) is labeled as rel(i), rel(j1), rel(j2), ... rel(jn), and isri entry(i) is labeled as acq(i), acq(j1), acq(j2), ... acq(jn), where the priority of isrj1, isrj2, ..., isrjn is equal to the priority of isri.

[0080] Based on the above, the advantages of this invention are as follows: First, this invention achieves accurate identification of synchronization operations through a combination of static and dynamic methods. Specifically, it initially identifies candidate synchronization operations through a lightweight analysis; collects and analyzes information generated during the entire program execution process, using an unsupervised reasoning process to filter candidate synchronization operations; executes the program multiple times, controlling interruptions to occur before and after suspected synchronization operations to observe changes in conflicting accesses, further refining the results of synchronization operation identification; then, based on the identified synchronization operations, this invention fully understands the happens-before relationship between shared variable accesses in the main program and each of its interrupt handlers, achieving accurate interrupt program data race detection; this method achieves zero false alarms in thousands of lines of code and can be extended to tens of thousands of lines of code, meeting the interrupt program detection requirements in the aerospace field. It can also realize automated defect detection in the virtual dynamic testing process of embedded software. If a pluggable prototype for dynamic interrupt data race detection can be implemented as expected, it can be applied to dynamic testing processes in the future, improving automatic defect detection capabilities and reducing the omission of concurrent defects during testing.

[0081] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. A precise method for dynamic detection of data contention in interrupt-driven embedded software, comprising the following steps: Step 1: Obtain a set of candidate synchronization operations; Step 2: Filter candidate synchronization operations; Step 3: Verify the accuracy of the synchronization operations; Step 4: Detect data races in the program; Its characteristics are: In step one above, based on the characteristics of synchronization operations in interrupt-driven programs, static analysis is performed on the program to be processed to identify candidate synchronization operations and generate a set of candidate synchronization operations. In step two above, the program to be processed is dynamically executed and the execution sequence is collected. Based on the execution sequence and the candidate synchronization operation set, unsupervised reasoning is performed to filter candidate synchronization operations. In step three above, before / after the candidate synchronization operation selected in step two, the corresponding interrupt is triggered, and the program is executed again to identify whether the candidate synchronization operation is a synchronization operation, thereby verifying the accuracy of the synchronization operation and obtaining the accurate synchronization operation. In step four above, based on the synchronization operations identified in step three, the three types of synchronization in the execution sequence—synchronization based on flag variables, interrupt switch, and interrupt entry / exit—are labeled; based on the labeled execution sequence, happens-before relationship analysis is performed on the access of shared variables in different processes, and data races in the program are detected.

2. The precise interrupt-driven embedded software data contention dynamic detection method according to claim 1, characterized in that: Step one specifically includes the following steps: 1.1 By modeling the access of shared data at various granularities, the system ensures accurate access to data regions and identifies shared variables accessed by the main program and interrupts, as well as those accessed by two different interrupts. 1.2 Identify explicit and implicit interrupt switch operations in embedded systems. For explicit operations, consider the standard interrupt switch API; for implicit operations, consider interrupt switches implemented using registers. 1.3 Based on interrupt synchronization features, candidate flag variables are identified in the program, and shared variables that are only assigned the value of constant, or shared variables that are only assigned the value of such variables, are identified as candidate flag variables; 1.4 Construct a candidate set of synchronous operations, which consists of interrupt switches, interrupt exit / entry points, and read / write operations of candidate flag variables.

3. The precise interrupt-driven embedded software data contention dynamic detection method according to claim 2, characterized in that: In step 1.3, the interrupt synchronization feature is as follows: 1) Synchronization based on flag variables in interrupt routines is only achieved through constant read and write. That is, flag variables in interrupt routines must be shared variables, and their read / write access must be performed on constants. In other words, they are always assigned the value of constants and are always read on constants. 2) The value of a flag variable may be passed to other flag variables, which together enable synchronization of shared resource access between the main program and the interrupt or between interrupts.

4. The precise interrupt-driven embedded software data contention dynamic detection method according to claim 1, characterized in that: Step two specifically includes the following steps: 2.1 The program to be processed is executed dynamically, and the program execution sequence is collected; 2.2 Based on the execution sequence generated after execution, a synchronization window is constructed, that is, each pair of conflicting accesses is identified from the execution log and a synchronization window is constructed for them. The synchronization window contains a release window and a get window; 2.3 Encode each operation object in the synchronization window as a variable, and its probability value represents the possibility of it being a synchronization operation, thereby refining the candidate synchronization operation set generated in step 1.4 and filtering out candidate synchronization operations that satisfy the inference rules.

5. The precise interrupt-driven embedded software data contention dynamic detection method according to claim 4, characterized in that: In step 2.1, the following information is set according to the test cases during dynamic execution: 1) Set the interrupt conditions for the first round of program execution; 2) Set program breakpoints to achieve precise memory control and monitoring; 3) Set test inputs to achieve coverage and provide sufficient information for synchronous reasoning and competition detection.

6. The precise interrupt-driven embedded software data contention dynamic detection method according to claim 4, characterized in that: In step 2.1, the execution sequence includes the following four types of events: 1) The entry / exit points for the main program and ISR; 2) Disconnect / shutdown operation; 3) Reading / writing candidate flag variables; 4) Reading / writing of shared variables other than candidate flag variables.

7. The precise interrupt-driven embedded software data contention dynamic detection method according to claim 4, characterized in that: In step 2.3, the reasoning rule is as follows: 1) Write-Release / Read-Acquire: A write operation on a variable will not be an acquire operation, and a read operation on a variable will not release 0; 2) Exit - release / Entry - acquire: The exit of an interrupt will not be an acquire, and the entry of an interrupt will not be a release; 3) enable-release / disable-acquire: Enabling an interrupt will not be acquired, and disabling an interrupt will not be released; 4) "Conflicting" access pairs are usually protected by synchronous operations: For a pair of release windows and get windows, the operations in the release window are r1, r2, ...rn, and the operations in the get window are a1, a2, ...am. There is a release operation in the release window and a get window in the get window to protect the access pair from conflict. 5) Flag variables always appear in pairs: a synchronization based on a flag variable is achieved by a read-write pair of the same flag variable; for synchronization based on a flag variable, if a write to a flag variable is used to release it, then the corresponding acquisition should also come from a read of the same flag variable; that is, if an operation on a variable only appears in one type of window, then that variable is not a flag variable, and its operation is not a synchronization operation. 6) The value of the flag variable is 2: In order to achieve synchronization based on the flag variable, the number of its values ​​is 2. Therefore, among all candidate flag variables, the one with 2 values ​​is given priority as the flag variable. 7) Synchronization operations only occur before and after accessing shared resources.

8. The precise interrupt-driven embedded software data contention dynamic detection method according to claim 1, characterized in that: In step four, the three synchronization methods are as follows: 1) For synchronization based on flag variables, write(flag) is marked as rel(flag), and read(flag) is marked as acq(flag); 2) For interrupt switches, enable(i) is marked as rel(i), and disable(i) is marked as acq(i); 3) For interrupt exits / entries, isri exit(i) is labeled as rel(i), rel(j1), rel(j2), ... rel(jn), and isri entry(i) is labeled as acq(i), acq(j1), acq(j2), ... acq(jn), where the priority of isrj1, isrj2, ..., isrjn is equal to the priority of isri.

Images