Sharing variable dependency chain fracture detection method and device

By disassembling and monitoring the program under optimized and non-optimized compilation configurations, and combining static and dynamic analysis, the system identifies and judges the breakpoints in the shared variable dependency chain, thus solving the program anomaly problem caused by compiler optimization and improving the accuracy and efficiency of detection.

CN120929339AActive Publication Date: 2025-11-11INSPUR SUZHOU INTELLIGENT TECH CO LTD
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
CN202511464147.0
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-10-14
Publication Date
2025-11-11
Estimated Expiration
2045-10-14

AI Technical Summary

Technical Problem

In existing technologies, compiler optimization may cause shared variable dependency chains to break, leading to abnormal program execution. Dynamic analysis has high performance overhead, static analysis has limited automation, formal verification has limited coverage of scenarios, and it is difficult to reproduce complex race conditions in production environments.

Method used

By compiling and disassembling the program with optimized compilation configurations disabled and enabled, and combining the static disassembly channel and the dynamic PMU channel, suspicious breakpoints are identified, performance monitoring points are set, static and dynamic breakpoints are calculated, and it is determined whether the comprehensive breakpoint is greater than the threshold to identify dependency chain breakpoints.

Benefits of technology

It improves the accuracy and efficiency of dependency chain break detection, reduces dynamic detection overhead, can cover competitive conditions in real production environments, and enhances the accuracy and comprehensiveness of detection.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120929339A_ABST
    Figure CN120929339A_ABST
Patent Text Reader

Abstract

The invention discloses a shared variable dependency chain breakage detection method and device, and relates to the technical field of multiprocessor programming, the method comprises the steps that two detection channels including a static disassembling channel and a dynamic PMU channel are coupled, the static disassembling channel uses the principle that related disassembling codes can change when a shared variable dependency chain breaks, and the dynamic PMU channel is used for detecting whether the shared variable dependency chain breaks or not; the dynamic PMU channel constructs a shared variable dependency chain fracture detection architecture by utilizing the principle that the number of related PMU events in the program running process changes when the shared variable dependency chain fractures, and the problems that in the related technology, the performance overhead of a dynamic analysis method is large, and the automation degree of a static analysis method is limited are solved; besides, the technical problems that the coverage scene of a formalized verification method is limited, and complex competition conditions of the production environment are difficult to reproduce are solved, and the technical effects that the detection accuracy and efficiency are effectively improved, the dynamic detection overhead is reduced, and the competition conditions in the real production environment can be covered are achieved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of multiprocessor programming technology, and in particular to a method and apparatus for detecting broken shared variable dependency chains. Background Technology

[0002] In some programming scenarios, the compiler's optimization mechanisms may have adverse effects. For example, in programming scenarios where multiple processors work together, the optimization operations performed by the compiler to improve efficiency may disrupt the dependency chain of shared variables, thereby causing abnormal problems in program execution. Currently, relevant technologies can detect harmful optimizations in compilers through methods such as dynamic analysis, static analysis, and formal verification.

[0003] However, among related technologies, dynamic analysis methods have high performance overhead, static analysis methods have limited automation and cannot accurately map to abnormal behavior during program runtime; in addition, formal verification methods have limited coverage scenarios and are difficult to reproduce complex competitive conditions in production environments, which urgently need to be addressed. Summary of the Invention

[0004] This application provides a method and apparatus for detecting broken shared variable dependency chains, which at least solves the technical problems in related technologies, such as the large performance overhead of dynamic analysis methods, the limited automation of static analysis methods and their inability to accurately map abnormal behavior during program runtime; in addition, formal verification methods have limited coverage scenarios and are difficult to reproduce complex competitive conditions in production environments.

[0005] This application provides a method for detecting shared variable dependency chain breaks, comprising the following steps: compiling and disassembling the program to be analyzed with and without optimized compilation configuration, respectively, to obtain disassembled files before and after optimization; comparing and analyzing the disassembled files before and after optimization to obtain corresponding analysis results; based on the analysis results, identifying suspicious breakpoints in the program to be analyzed that meet preset dependency chain change requirements, determining the dependency chain change requirement type corresponding to the suspicious breakpoints, and determining the requirement weights corresponding to different requirements in the preset dependency chain change requirements according to the dependency chain change requirement type, so as to calculate the static disassembly pass of the suspicious breakpoints through the dependency chain change requirement type and the requirement weights. The process involves: setting performance monitoring points at suspected breakpoints; recompiling the program to be analyzed after setting performance monitoring points to generate an executable program with performance monitoring points; running the executable program with performance monitoring points to determine the number of performance monitoring events that meet the preset dependency chain break correlation requirements before and after optimization; calculating the dynamic performance monitoring channel breakpoint of the suspected breakpoint based on the number of occurrences; calculating the comprehensive breakpoint of the suspected breakpoint based on the static disassembly channel breakpoint and the dynamic performance monitoring channel breakpoint; and determining whether the comprehensive breakpoint is greater than a breakpoint threshold. If the comprehensive breakpoint is greater than the breakpoint threshold, the suspected breakpoint is determined to be a dependency chain breakpoint.

[0006] This application also provides a shared variable dependency chain break detection device, comprising: a disassembly module, used to perform compilation and disassembly operations on the program to be analyzed with optimized compilation configuration disabled and optimized compilation configuration enabled respectively, to obtain disassembly files before and after optimization, and to compare and analyze the disassembly files before and after optimization to obtain corresponding analysis results; and an identification module, used to identify suspicious breakpoints in the program to be analyzed that meet preset dependency chain change requirements based on the analysis results, and to determine the dependency chain change requirement type corresponding to the suspicious breakpoints, and to determine the requirement weights corresponding to different requirements in the preset dependency chain change requirements according to the dependency chain change requirement type, so as to calculate the static disassembly channel break of the suspicious breakpoints through the dependency chain change requirement type and the requirement weights. The module is configured to: a breakpoint calculation module, which sets performance monitoring points at the suspected breakpoints, recompiles the program to be analyzed after setting performance monitoring points to generate an executable program with performance monitoring points, and runs the executable program with performance monitoring points to determine the number of performance monitoring events that meet the preset dependency chain break correlation requirements before and after optimization, and calculates the dynamic performance monitoring channel breakpoint of the suspected breakpoint based on the number of occurrences; and a judgment module, which calculates the comprehensive breakpoint of the suspected breakpoint based on the static disassembly channel breakpoint and the dynamic performance monitoring channel breakpoint, and determines whether the comprehensive breakpoint is greater than a breakpoint threshold, wherein if the comprehensive breakpoint is greater than the breakpoint threshold, the suspected breakpoint is determined to be a dependency chain breakpoint.

[0007] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described shared variable dependency chain break detection methods 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 any of the above-described methods for detecting broken shared variable dependency chains.

[0009] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described methods for detecting broken shared variable dependency chains.

[0010] This application allows for the compilation and disassembly of the program to be analyzed, with and without optimized compilation configuration, to obtain disassembled files before and after optimization. A comparative analysis of these disassembled files yields corresponding analysis results. Based on these results, suspicious breakpoints in the program to be analyzed that meet preset dependency chain change requirements are identified. The type of dependency chain change requirement corresponding to each suspicious breakpoint is determined, and the requirement weights for different requirements within the preset dependency chain change requirements are determined based on the dependency chain change requirement type. The static disassembly channel breakpoint score is then calculated using the dependency chain change requirement type and requirement weights. Performance monitoring points are set at the suspicious breakpoints, and the program to be analyzed after setting these monitoring points is recompiled to generate an executable program with performance monitoring points. This executable program with performance monitoring points is then run to determine the performance of the program to be analyzed. The algorithm calculates the number of performance monitoring events that meet the preset dependency chain break correlation requirements before and after optimization, and calculates the dynamic performance monitoring channel break score of the suspected breakpoint based on the number of occurrences. It then calculates the comprehensive break score of the suspected breakpoint based on the static disassembly channel break score and the dynamic performance monitoring channel break score, and determines whether the comprehensive break score is greater than a break threshold. If the comprehensive break score is greater than the break threshold, the suspected breakpoint is determined to be a dependency chain breakpoint. Therefore, this algorithm addresses the technical problems of high performance overhead of dynamic analysis methods, limited automation of static analysis methods, and inability to accurately map abnormal behavior during program runtime. Furthermore, it addresses the limitations of formal verification methods in covering various scenarios and their difficulty in reproducing complex competitive conditions in production environments. This approach effectively improves the accuracy and efficiency of detection, reduces dynamic detection overhead, and covers competitive conditions in real production environments. 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 1 This is a flowchart of a shared variable dependency chain break detection method provided according to an embodiment of this application; Figure 2 A schematic diagram of the logical architecture of a shared variable dependency chain break detection method provided for one embodiment of this application; Figure 3 A schematic diagram of the execution logic of a shared variable dependency chain break detection method provided for one embodiment of this application; Figure 4 This is an example diagram of a shared variable dependency chain breakage detection device according to an embodiment of this application.

[0013] Among them, 10-shared variable dependency chain break detection device, 100-disassembly module, 200-identification module, 300-break calculation module, and 400-judgment module. Detailed Implementation

[0014] 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.

[0015] 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.

[0016] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0017] The specific application environment architecture or specific hardware architecture on which the shared variable dependency chain break detection method depends is described here.

[0018] The embodiments of this application provide a method for detecting broken shared variable dependency chains.

[0019] like Figure 1 The diagram shown is a flowchart of a shared variable dependency chain break detection method according to an embodiment of this application. The shared variable dependency chain break detection method includes the following steps: In step S101, the program to be analyzed is compiled and disassembled with the optimization compilation configuration turned off and with the optimization compilation configuration turned on, respectively, to obtain disassembled files before and after optimization. The disassembled files before and after optimization are compared and analyzed to obtain the corresponding analysis results.

[0020] Those skilled in the art should understand that, in related technologies, harmful optimization detection techniques based on decoders and encoders mainly include three categories: dynamic analysis, static analysis, and formal verification.

[0021] Dynamic analysis techniques generally need to be combined with instrumentation techniques to detect defective code during program execution, such as the Valgrind tool and the ThreadSanitizer tool. Although this technique can capture abnormal behavior at runtime with high precision, the performance overhead introduced by instrumentation is relatively large.

[0022] Static analysis techniques detect defective code at compile time and can be broadly categorized into the following two types: 1. Recognition Class: Identification-based methods can identify defective code at compile time based on prompts. For example, they can declare data dependencies through code annotations and have the compiler verify the dependency logic; or they can analyze data flow based on symbolic execution to identify violations. Although this type of technology has low runtime overhead, it relies too much on manual annotations or configurations, has a low degree of automation, and cannot accurately map to abnormal behavior during program runtime.

[0023] 2. Comparison type: Comparison methods can compare the results of the same source code before and after optimization, injecting inspection instructions at the points of difference, such as the DiffKemp tool. While this type of method can overcome the problem of low automation of identification methods to some extent, it still has the problem of not being able to accurately map to abnormal behavior during program runtime.

[0024] Formal verification methods can verify whether the execution results meet the expectations of the memory model by constructing benchmark concurrent code. They can directly retain the behavior of hardware / compiler that violates the memory model. However, the design of test cases depends on experience, has limited coverage of scenarios, and is difficult to reproduce the complex race conditions in the production environment.

[0025] Therefore, in order to solve the problems existing in related technologies, the embodiments of this application can construct a shared variable dependency chain break detection architecture that includes two detection channels: a static disassembly channel and a dynamic PMU (Performance Monitor Unit) channel, such as... Figure 2 As shown, the static disassembly channel utilizes the principle that the disassembled code changes when the shared variable dependency chain breaks, while the dynamic PMU channel utilizes the principle that the number of related PMU events during program execution changes when the shared variable dependency chain breaks.

[0026] Therefore, the embodiments of this application can effectively improve the accuracy and efficiency of dependency chain break detection by coupling the static disassembly channel and the dynamic PMU channel.

[0027] Optionally, in one embodiment of this application, the program to be analyzed is compiled and disassembled to obtain disassembled files before and after optimization, including: compiling the program to be analyzed with the optimization compilation configuration disabled to obtain a compiled file before optimization, and compiling the program to be analyzed with the optimization compilation configuration enabled to obtain a compiled file after optimization; and performing disassembly operations on the compiled file before optimization and the compiled file after optimization respectively to generate corresponding disassembled files before and after optimization.

[0028] It should be noted that the embodiments of this application can use different compilation options (such as disabling or enabling optimized compilation configuration) to compile the program to be analyzed, resulting in executable programs with different optimization levels, specifically binary executable programs. The different optimization levels are mainly reflected in whether optimized compilation configuration is enabled. If optimized compilation configuration is disabled, it means that the program to be analyzed is not optimized during compilation, resulting in the lowest optimization level; compilation at this time yields the unoptimized compiled file. If optimized compilation configuration is enabled, multiple compilation options with different optimization levels can be enabled, resulting in the optimized compiled file.

[0029] For example, embodiments of this application can use GCC (GNU Compiler Collection) with -O0 to compile and obtain the unoptimized binary executable program bin_O0, and use GCC with -O2 to compile and obtain the optimized binary executable program bin_O2; secondly, embodiments of this application can disassemble bin_O0 and bin_O2 to obtain disasm_O0 disassembled file (unoptimized disassembled file) and disasm_O2 disassembled file (i.e. optimized disassembled file) respectively.

[0030] Therefore, the embodiments of this application can intuitively demonstrate the compiler optimization effect by comparing the binary programs generated by different compilation options and their disassembled files, which helps to understand the optimization mechanism.

[0031] Optionally, in one embodiment of this application, a comparative analysis of the disassembled files before and after optimization is performed to obtain corresponding analysis results. This includes: inputting the disassembled files before and after optimization into a preset static disassembled channel to perform code structured parsing on the disassembled files respectively, generating structured code data containing instruction type, operation object, and code location information; based on the structured code data, performing dependency chain comparison on the code segments in the disassembled files before and after optimization to obtain corresponding comparison data, and analyzing the code locations in the code segments that meet the preset dependency chain change requirements based on the comparison data to obtain analysis results.

[0032] As one possible approach, this embodiment of the application can input the disassembly files disasm_O0 and disasm_O2 before and after optimization into a static disassembly channel when processing the disassembly files before and after optimization. Furthermore, this embodiment of the application can introduce a multi-level parsing framework through the static disassembly channel. Specifically, this embodiment of the application first uses an instruction segmenter to disassemble each instruction and extract basic information such as opcodes and operands; secondly, it uses a control flow graph generation module to associate code locations with jump logic, ultimately generating structured code data containing instruction types (such as arithmetic operations and memory accesses), operands (registers / memory addresses), code locations, and control flow relationships. Subsequently, this application embodiment can employ a bidirectional tracing comparison method to compare dependency chains. On one hand, this application embodiment can start from the instructions of the optimized code segment and trace back to its corresponding dependent instructions before optimization; on the other hand, this application embodiment can start from the starting point of the dependency chain before optimization and verify the dependency inheritance relationship of the optimized instructions in a forward manner. In the embodiments of this application, the comparison data not only includes the addition or removal of dependent instructions, but also marks changes in dependency strength (such as strong dependency turning into weak dependency).

[0033] It should be noted that the embodiments of this application can analyze the code locations in the code segment that meet the preset dependency chain change requirements based on comparison data, so as to obtain the analysis results presented in a structured table format of "code location-change type-risk level". The dependency chain change requirements in the embodiments of this application, i.e., the key detection points, include but are not limited to: whether the mov instruction sequence (data copy) is replaced with independent memory access, whether intermediate variables are optimized and eliminated, and whether the memory access order has changed. In actual execution, the embodiments of this application can refine the dependency chain change requirements into three levels: core dependency chain breakage (requires urgent investigation), non-core dependency chain addition (requires impact assessment), and dependency order adjustment (requires verification of logical consistency). Therefore, the embodiments of this application accurately capture changes in the dependency chain after code optimization through multi-layer analysis and bi-directional source tracing comparison, identify risk points, and provide efficient support for verifying the rationality of optimization and investigating potential problems.

[0034] In step S102, based on the analysis results, suspicious breakpoints in the program to be analyzed that meet the preset dependency chain change requirements are identified, and the dependency chain change requirement type corresponding to the suspicious breakpoint is determined. The requirement weights corresponding to different requirements in the preset dependency chain change requirements are determined according to the dependency chain change requirement type, so as to calculate the static disassembly channel breakpoint of the suspicious breakpoint through the dependency chain change requirement type and requirement weight.

[0035] Furthermore, embodiments of this application detect whether there are suspicious locations of dependency chain breaks in the program to be analyzed based on the analysis results. If so, embodiments of this application can mark the corresponding locations as suspicious breakpoints, determine the dependency chain change requirement type corresponding to the suspicious breakpoints, and determine the requirement weights corresponding to different requirements in the preset dependency chain change requirements (such as data copy instruction sequences being replaced with independent memory access, intermediate variables being optimized and eliminated, memory access order being changed, etc.) based on the dependency chain change requirement type and requirement weights, so as to calculate the static disassembly channel break score of the suspicious breakpoints through the dependency chain change requirement type and requirement weights.

[0036] Therefore, the embodiments of this application can accurately locate potential risk points in the program and quantify the degree of risk by detecting suspicious locations of dependency chain breaks based on the analysis results and calculating the corresponding static disassembly channel break points, thereby providing clear guidance for troubleshooting program problems and ensuring the stability of the optimized program.

[0037] Optionally, in one embodiment of this application, based on the analysis results, suspicious breakpoints in the program to be analyzed that meet preset dependency chain change requirements are identified, and the dependency chain change requirement type corresponding to the suspicious breakpoint is determined. Furthermore, the requirement weights corresponding to different requirements in the preset dependency chain change requirements are determined according to the dependency chain change requirement type. The static disassembly channel breakpoint score is calculated using the dependency chain change requirement type and requirement weight. This includes: based on the analysis results, determining the code locations in the code segments of the disassembled files before and after optimization of the program to be analyzed that meet the preset dependency chain change requirements, and using these code locations as the corresponding suspicious breakpoints. The preset dependency chain change requirements include data copy instruction sequences being replaced with independent memory accesses, intermediate variables being optimized and eliminated, and memory access order being changed; determining the dependency chain change requirement type to which the current suspicious breakpoint belongs, and assigning values ​​to preset dependency chain change indicators according to the dependency chain change requirement type; based on the dependency chain change requirement type, determining the data copy instruction sequence weight, intermediate variable weight, and memory access order weight corresponding to the suspicious breakpoint, and calculating the static disassembly channel breakpoint score based on the data copy instruction sequence weight, intermediate variable weight, memory access order weight, and the assigned dependency chain change indicator.

[0038] In actual execution, this application embodiment, based on the static disassembly channel, compares the disassembled code before and after optimization (e.g., -O0 and -O2), detects code locations in the code segment where dependency chain changes exist, and marks them as suspicious breakpoints; secondly, this application embodiment can determine the type of dependency chain change requirement to which the current suspicious breakpoint belongs (e.g., data copy instruction sequence is replaced with independent memory access type, intermediate variable is optimized and eliminated type, memory access order is changed type), so as to assign values ​​to the preset dependency chain change index; furthermore, this application embodiment can calculate the static disassembly channel breakpoint score of each suspicious breakpoint based on the analysis results and dependency chain change index.

[0039] As one possible approach, the calculation expression for the static disassembly channel breakpoint in this embodiment of the application is as follows:

[0040] in, The weight of the data copy instruction sequence is used to measure the relative importance of whether the "mov instruction sequence is replaced by an independent memory access" in the calculation of the break time division. It can be trained based on historical experience. This indicates that the data copy instruction sequence has been replaced with an independent memory access type. It indicates whether the "mov instruction sequence has been replaced with an independent memory access" condition has occurred at the current checkpoint. If so, then... Assign a value of 1 if the value is 1, otherwise assign a value of 0. Indicates the weight of intermediate variables; This indicates that intermediate variables are being optimized away from their original type. Indicates the weight of memory access order; This indicates a change in the memory access order.

[0041] Therefore, the embodiments of this application, by clearly defining different dependency chain change requirements and combining weight assignment to calculate static disassembly channel break points, quantify the risk of suspicious breakpoints, accurately locate potential problems after code optimization, and provide quantifiable data basis for verifying the rationality of optimization and ensuring program stability.

[0042] In step S103, performance monitoring points are set at suspected breakpoints, and the program to be analyzed after setting performance monitoring points is recompiled to generate an executable program with performance monitoring points. The executable program with performance monitoring points is run to determine the number of performance monitoring events that meet the preset dependency chain break correlation requirements before and after optimization in the program to be analyzed. The dynamic performance monitoring channel break score of the suspected breakpoint is calculated based on the number of occurrences.

[0043] Subsequently, embodiments of this application can set PMU monitoring points (i.e., performance monitoring points) at suspected breakpoints in the program to be analyzed, and recompile the program to be analyzed after setting performance monitoring points, such as -O0 and -O2, to generate binary executable programs bin_O0_PMU and bin_O2_PMU with PMU monitoring points. Furthermore, embodiments of this application can input the binary executable programs bin_O0_PMU and bin_O2_PMU with PMU monitoring points into the dynamic PMU channel (i.e., the dynamic performance monitoring channel) for execution, and count the number of PMU events (i.e., performance monitoring events) related to dependency chain breaks before and after optimization, so as to calculate the dynamic PMU channel breakpoint (i.e., the dynamic performance monitoring channel breakpoint) for each suspected breakpoint based on the number of occurrences.

[0044] Therefore, the embodiments of this application set PMU monitoring points at suspected breakpoints and recompile the program. By running the dynamic PMU channel to count the number of related events, the breakpoint of the dynamic performance monitoring channel is calculated. This allows for the quantification of dependency chain break risk at the operational level, supplementing static analysis and improving the comprehensiveness and accuracy of program problem detection.

[0045] Optionally, in one embodiment of this application, performance monitoring points are set at suspected breakpoints, and the program to be analyzed after setting performance monitoring points is recompiled to generate an executable program with performance monitoring points. The executable program with performance monitoring points is then run to determine the number of performance monitoring events that meet the preset dependency chain break correlation requirements before and after optimization. The dynamic performance monitoring channel break score of the suspected breakpoint is calculated based on the number of occurrences. This includes: setting performance monitoring points at suspected breakpoints to generate corresponding intermediate program code; compiling the intermediate program code using different compilation options to generate an executable program with performance monitoring points; running the executable program with performance monitoring points in a preset dynamic performance monitoring channel to monitor performance monitoring events that meet the preset dependency chain break correlation requirements before and after optimization; counting the number of occurrences of performance monitoring events that meet the preset dependency chain break correlation requirements, wherein the performance monitoring events include the number of first-level cache hits or misses, the number of second-level cache hits or misses, and the number of instruction cycles consumed; and calculating the dynamic performance monitoring channel break score of the suspected breakpoint based on the number of occurrences.

[0046] It should be noted that in the program dependency chain break detection scenario, the embodiments of this application first perform precise monitoring point implantation operation on the suspicious breakpoints of the program to be analyzed. Unlike the traditional coarse instrumentation, this method deeply binds the performance monitoring point (PMU monitoring point) with the instruction logic of the suspicious breakpoint, ensuring that the monitoring point only captures the dependency chain-related behavior at that location, avoiding interference from irrelevant instructions, and generating intermediate program code containing precise monitoring logic. Secondly, the embodiments of this application can use multi-dimensional compilation options to perform differentiated compilation of the intermediate code: in addition to the conventional no optimization (-O0) and secondary optimization (-O2) options, additional options such as memory access optimization (-O3 -ftree-vectorize) and instruction scheduling optimization (-Os -fschedule-insns) are introduced to generate multiple sets of binary executable programs with PMU monitoring points (such as bin_O0_PMU, bin_O2_PMU, bin_O3_PMU, etc.) to cover the possibility of dependency chain changes under different optimization scenarios. During the operation of the dynamic performance monitoring channel, this application embodiment can construct an "event-scenario" mapping model: PMU events (number of L1 cache hits / misses (L1_HIT / L1_MISS), number of L2 cache hits / misses (L2_HIT / L2_MISS), number of instruction cycles consumed (CYCLES), etc.) are associated with dependency chain break types (such as data dependency break, control dependency break). For example, when a sudden increase in the number of L1 cache misses is detected, this application embodiment can prioritize associating dependency chain break scenarios such as "change in memory access order". At the same time, the channel has a built-in real-time data filtering module that automatically removes invalid PMU event (i.e., performance monitoring event) data generated by system resource competition (such as CPU (Central Processing Unit) preemption) to ensure the accuracy of monitoring results.

[0047] Finally, in the PMU event statistics stage, this application embodiment can adopt a time-slice segmented statistics strategy combined with a weighted aggregation strategy. Specifically, this application embodiment can divide the program running cycle into multiple equal-length time slices, count the occurrence of target PMU events in each time slice, and then calculate the total number of events after weighting based on the importance of the program business logic in different time slices (e.g., the time slice weight of the core computing module is set to 1.2, and the weight of the auxiliary function module is set to 0.8). This provides data support that is more in line with the actual running scenario for subsequent dynamic performance monitoring channel breakage calculation.

[0048] Therefore, the embodiments of this application couple the static disassembly channel and the dynamic PMU channel, thereby using the suspicious breakpoints identified by the static disassembly channel as monitoring points for the dynamic PMU channel, effectively reducing the scope and overhead of dynamic detection and improving detection efficiency. In addition, the embodiments of this application improve the accuracy of PMU event capture related to dependency chain breakage through precise instrumentation, multi-compilation option adaptation and intelligent event monitoring, providing reliable data for dynamic breakpoint calculation.

[0049] Alternatively, in one embodiment of this application, the accuracy of dynamic performance monitoring can also be improved by the following methods: 1. Based on the analysis results of static dependency chains and cross-validation with control flow graphs and data flow graphs, a priority evaluation model for suspected breakpoints is constructed. For the top 30% of breakpoints, abstract syntax tree traversal technology is used to set performance monitoring points before and after the code block to record the initial and post-execution phasor states. 2. Establish a database mapping compilation options to monitoring requirements, select the optimal combination of compilation parameters for different measurement targets, generate multiple versions of binary programs with monitoring points, and introduce post-compilation optimization techniques to trim redundant code and rearrange instructions; 3. Construct a master-slave distributed monitoring channel architecture. The master channel collects core phasor data in real time, while the slave channel collects secondary data asynchronously. An event filtering engine is embedded to filter the raw data according to preset rules. Valid events are classified through machine learning algorithms, and the occurrence of events is statistically analyzed in layers using a sliding time window.

[0050] Therefore, the embodiments of this application can accurately locate key monitoring points, optimize compilation and channel design, reduce interference data, and improve the accuracy and completeness of data collection.

[0051] Optionally, in one embodiment of this application, the dynamic performance monitoring channel break score of the suspected breakpoint is calculated based on the number of occurrences, including: calculating the difference in the number of first-level cache hits, the difference in the number of first-level cache misses, the difference in the number of second-level cache hits, the difference in the number of second-level cache misses, and the difference in the number of instruction cycles consumed before and after optimization; and constructing a break feature matrix based on the difference in the number of first-level cache hits, the difference in the number of first-level cache misses, the difference in the number of second-level cache hits, the difference in the number of second-level cache misses, and the difference in the number of instruction cycles consumed; determining the weights of different performance monitoring events; and calculating the dynamic performance monitoring channel break score based on the break feature matrix and the weights of different performance monitoring events.

[0052] In actual implementation, the embodiment of this application calculates the fracture time division of the dynamic performance monitoring channel. First, a fracture feature matrix can be established, as shown in the following formula:

[0053] in, Represents the fracture feature matrix. This represents the difference in the number of first-level cache hits before and after optimization; , which represents the difference in the number of first-level missing values ​​before and after optimization; This represents the difference in the number of L2 cache hits before and after optimization; , which represents the difference in the number of second-level missing values ​​before and after optimization.

[0054] Secondly, embodiments of this application can calculate the fracture component of the dynamic performance monitoring channel based on the fracture feature matrix, as shown in the following formula:

[0055] in, The weight of different performance monitoring events is indicated, which can measure the relative importance of each PMU event in calculating the fracture time division. This parameter can be obtained by training based on historical experience. This indicates a break in the dynamic performance monitoring channel. This represents the difference between each PMU event in the fracture feature matrix before and after optimization.

[0056] Therefore, the embodiments of this application only need to configure key detection points and fracture feature matrices, thereby identifying the differences before and after the optimization of the same source code, effectively improving the accuracy and reliability of automated calculation of dynamic PMU channel fractures.

[0057] In step S104, the comprehensive break score of the suspected break point is calculated based on the break score of the static disassembly channel and the break score of the dynamic performance monitoring channel, and it is determined whether the comprehensive break score is greater than the break threshold. If the comprehensive break score is greater than the break threshold, the suspected break point is determined to be a dependency chain break point.

[0058] Furthermore, embodiments of this application may rely on a chain break analysis engine to calculate a comprehensive break score for suspicious breakpoints based on the detection results of two channels (i.e., break score of the static disassembly channel and break score of the dynamic performance monitoring channel), and determine that the suspicious breakpoint is a dependent chain breakpoint when the comprehensive break score exceeds the break threshold.

[0059] It should be noted that the entire dependency chain break detection process in this application embodiment is performed on specific source code, thereby covering race conditions in a real production environment.

[0060] Optionally, in one embodiment of this application, a comprehensive breakpoint score for a suspected breakpoint is calculated based on the breakpoint scores of the static disassembly channel and the dynamic performance monitoring channel, and it is determined whether the comprehensive breakpoint score is greater than a breakpoint threshold. Specifically, when the comprehensive breakpoint score is greater than the breakpoint threshold, the suspected breakpoint is determined to be a dependency chain breakpoint. This includes: performing a fusion calculation on the breakpoint scores of the static disassembly channel and the dynamic performance monitoring channel to obtain a comprehensive breakpoint score for the suspected breakpoint, and comparing the comprehensive breakpoint score with a preset breakpoint threshold; when the comprehensive breakpoint score is less than or equal to the breakpoint threshold, the corresponding suspected breakpoint is determined not to be a dependency chain breakpoint; when the comprehensive breakpoint score is greater than the breakpoint threshold, the corresponding suspected breakpoint is determined to be a dependency chain breakpoint, and dependency chain breakpoint information corresponding to the dependency chain breakpoint is collected to generate a corresponding detection report based on the dependency chain breakpoint information.

[0061] It should be noted that the embodiments of this application may introduce a hierarchical weighted fusion algorithm, a scene adaptation weight factor, a baseline dynamic calibration mechanism, and a multi-level information acquisition mechanism to calculate the comprehensive fracture score of suspected fracture points and generate a corresponding detection report, as detailed below: 1. First, the embodiments of this application can standardize the static disassembly channel break score (focusing on code structure level risk) and the dynamic performance monitoring channel break score (focusing on actual runtime performance), and map the values ​​of both to the [0,1] interval to avoid the fusion result being affected by the difference in units. 2. Secondly, when the suspected breakpoint is located in the core calculation module of the program (such as data encryption, high-frequency loop segment), considering that the static code structure has a greater impact on the stability of the dependency chain, this application embodiment can assign a weight of 0.6 to the static score and a weight of 0.4 to the dynamic score; when the suspected breakpoint is located in the auxiliary function module (such as log printing, configuration reading), this application embodiment can focus on runtime data and assign a weight of 0.6 to the dynamic score and a weight of 0.4 to the static score, so as to ensure that the fusion result fits the actual function scenario of the code. 3. In this embodiment, the average comprehensive fracture score of historical programs without fracture risk is used as the initial threshold (e.g., 0.5). Then, the comprehensive fracture score data of normal code segments of new detection programs are collected periodically, and the threshold is updated by the moving average method to avoid threshold adaptation deviation due to differences in program type (e.g., real-time program, batch processing program). 4. After determining the dependency chain breakpoint, in addition to collecting the conventional code location and breakpoint value, this application embodiment can also additionally associate the instruction sequence differences in static disassembly and the abnormal data of PMU events in dynamic monitoring (such as the period of sudden increase in L1 cache misses), and integrate this information into the detection report in a structured manner. The report also includes breakpoint impact prediction information, which, based on the code logic where the breakpoint is located, infers the possible program abnormalities (such as data calculation errors and running lag).

[0062] Therefore, the embodiments of this application can accurately calculate the comprehensive break score through hierarchical weighted fusion and dynamic threshold calibration, thereby improving the accuracy of dependency chain break point determination, providing clear and accurate data guidance for subsequent positioning and repair, and ensuring the stability of the optimized program.

[0063] Optionally, in one embodiment of this application, the static disassembly channel break score and the dynamic performance monitoring channel break score are fused to obtain a comprehensive break score for suspected breakpoints. This includes: collecting dependency chain break annotation data of historical program samples under different compilation scenarios and corresponding historical static disassembly channel break scores and historical dynamic performance monitoring channel break scores; training a pre-built dependency chain break analysis model based on the dependency chain break annotation data, historical static disassembly channel break scores, and historical dynamic performance monitoring channel break scores; inputting the static disassembly channel break scores and dynamic performance monitoring channel break scores into the trained dependency chain break analysis model to output the static disassembly channel weights corresponding to the static disassembly channel break scores, the dynamic performance monitoring channel weights corresponding to the dynamic performance monitoring channel break scores, and the break threshold; and calculating a comprehensive break score based on the static disassembly channel break scores, static disassembly channel weights, dynamic performance monitoring channel break scores, and dynamic performance monitoring channel weights.

[0064] In the specific implementation process, the embodiments of this application can be classified and stored according to the compilation scenario. Each piece of data contains manually annotated dependency chain break tags, static break scores, dynamic break scores, and compilation parameter metadata to build a multi-dimensional sample library. Secondly, the dependency chain breakage analysis model in this application embodiment can adopt a dual-output neural network architecture. Its input layer receives static and dynamic breakage scores, the hidden layer learns the feature importance under different compilation scenarios through an attention mechanism, and the output layer generates static weights, dynamic weights, and breakage thresholds simultaneously, achieving collaborative optimization of the three. During the training of the dependency chain breakage analysis model, this embodiment can introduce a contrastive learning strategy. That is, this embodiment applies correlation constraints to variant data of the same sample under different compilation scenarios, enhancing the model's adaptability to scenario differences, while employing an early stopping mechanism to prevent overfitting. When applying the model, this embodiment can input the real-time calculated static disassembly channel breakage score and dynamic performance monitoring channel breakage score into the dependency chain breakage analysis model to obtain scenario-adaptive weights and thresholds. A weighted summation is then used to obtain the comprehensive breakage score, thereby improving the consistency of cross-scenario analysis. The calculation expression for the comprehensive breakage score is as follows:

[0065] in, This represents the static disassembly channel weight, which measures the degree of influence of the static disassembly channel on the overall breakage score. It can be obtained through training based on historical experience. This represents the weight of the dynamic performance monitoring channel, which measures the influence of the dynamic PMU channel on the overall fracture score. It can also be derived from historical experience through training. Indicates the comprehensive fracture components; This indicates a break in the static disassembly channel; This indicates a break in the dynamic performance monitoring channel.

[0066] Therefore, the embodiments of this application can train the model based on historical data and dynamically generate weights and thresholds that are suitable for the scenario, thereby improving the accuracy and generalization ability of the comprehensive fracture calculation and enhancing the intelligence level of dependency chain fracture detection.

[0067] Optionally, in one embodiment of this application, the specific process of training the dependency chain breakage analysis model is as follows: 1. Data preprocessing: The collected dependency chain break annotation data is encoded and converted. The historical static disassembly channel break scores and historical dynamic performance monitoring channel break scores are normalized and divided into training set, validation set and test set in a 7:2:1 ratio. Oversampling or weighted loss function is used to balance the samples. 2. Training process optimization: The Adam (Adaptive Moment Estimation) optimization algorithm is adopted, and a multi-task loss function (i.e., fusing MSE (Mean Squared Error) and MAE (Mean Absolute Error)) is designed. The model is trained by combining Dropout, L2 regularization and early stopping strategy, and the hyperparameters are tuned through the validation set. 3. Model Validation: The model prediction accuracy is evaluated using a test set to ensure that the output channel weights and break thresholds meet the error requirements.

[0068] Therefore, the embodiments of this application can efficiently utilize multi-dimensional data, improve the model's ability to capture dependency chain breakage features, avoid overfitting, ensure the accuracy of the output channel weights and breakage thresholds, and provide reliable model support for subsequent dependency chain breakage analysis.

[0069] Optionally, in one embodiment of this application, after generating the corresponding detection report based on the dependency chain breakpoint information, the method further includes: obtaining the dependency chain breakpoint information of the detection report, and constructing a standardized analysis dataset based on the dependency chain breakpoint information; evaluating the dependency chain breakpoint detection performance of the static disassembly channel and the dynamic performance monitoring channel based on the standardized analysis dataset to obtain the corresponding evaluation results; identifying defect information in the dependency chain breakpoint detection process based on the evaluation results, adjusting the weights of the static disassembly channel and the dynamic performance monitoring channel based on the defect information, and calculating a new comprehensive breakpoint score using the adjusted weights of the static disassembly channel and the dynamic performance monitoring channel, so as to re-perform the dependency chain breakpoint determination operation using the new comprehensive breakpoint score.

[0070] As one possible approach, the specific process of constructing a standardized analysis dataset, evaluating performance, identifying defect information, and optimizing adjustments in embodiments of this application is described below: 1. When constructing a standardized analysis dataset, the embodiments of this application can decompose the dependency chain breakpoint information into core feature fields and related scenario fields. The core feature fields cover the code location of the breakpoint, static / dynamic breakpoint score, comprehensive breakpoint score, and judgment result to ensure the standardization of basic data. The related scenario fields supplement the code module type (such as calculation module, IO module), compilation options (such as -O0 / -O2), and program runtime environment parameters (such as CPU model, memory size) where the breakpoint is located, providing a scenario-based analysis dimension for subsequent performance evaluation. At the same time, the data structure is unified by using JSON-LD (JavaScript ObjectNotation for Linked Data) format, which is convenient for cross-tool calling and analysis.

[0071] 2. During the performance evaluation process, the embodiments of this application can design a two-dimensional, multi-index evaluation system: (1) The first dimension is the "accuracy index", which calculates the true positive rate (number of correctly detected breakpoints / actual number of breakpoints), false positive rate (number of misjudged breakpoints / total number of non-breakpoints) and F1 score (harmonic mean of true positive rate and accuracy rate) of the static disassembly channel and the dynamic performance monitoring channel. (2) The second dimension is “efficiency indicators”, which statistically analyze the average time spent and resource utilization (such as CPU utilization and memory consumption) of a single dependency chain detected by the two channels.

[0072] During the evaluation, the embodiments of this application can group according to the associated scenario fields and calculate the index values ​​under different compilation options and different code modules to accurately locate the detection performance shortcomings in each scenario.

[0073] 3. In the process of identifying defect information, the embodiments of this application can introduce a defect root cause mapping model. Specifically, the embodiments of this application can match abnormal indicators in the evaluation results (such as a false positive rate of more than 30% for dynamic channels under a certain compilation option) with a preset defect type library (such as inaccurate dynamic monitoring event filtering or omissions in static dependency chain comparison logic), and combine them with historical optimization cases to locate the root cause of the defect. For example, if the true positive rate of static channels is low in I / O (Input / Output) intensive modules, it is determined that "the IO instruction dependency characteristics were not fully considered during static code structured parsing"; if dynamic channels take too long in high-frequency loop modules, it is determined that "the sampling frequency of PMU monitoring points does not match the loop period".

[0074] 4. During the optimization and adjustment process, the embodiments of this application may adopt a scenario-based parameter iterative optimization strategy. Specifically, the embodiments of this application may address static channel defects by optimizing the static fracture calculation logic and increasing the IO instruction dependency weight coefficient if the IO instruction dependency is insufficiently parsed; and address dynamic channel defects by dynamically adjusting the sampling interval of the PMU monitoring points (e.g., shortening the sampling interval of the high-frequency loop module to 1 / 2 of the original interval) if the sampling frequency is incompatible.

[0075] Furthermore, the embodiments of this application can be optimized through an iterative process of "small-batch verification - feedback adjustment - large-scale application" to ensure that the calculated fractures of the two channels are more in line with the actual detection scenario and improve the detection accuracy of actual dependent chain fracture points.

[0076] Therefore, the embodiments of this application construct a standardized dataset by decomposing the breakpoint information and evaluate the detection performance with two-dimensional indicators, thereby improving the detection accuracy and efficiency, and can be adapted to different scenarios, providing a scientific and accurate optimization path for dependency chain breakpoint detection.

[0077] The logical architecture and execution logic of the shared variable dependency chain break detection method of this application are described below with reference to the accompanying drawings.

[0078] Figure 2 This is a schematic diagram of the logical architecture of the shared variable dependency chain break detection method of this application. Figure 2 As shown, this application can detect instruction sequences through a static disassembly channel in the target system to identify suspicious breakpoints in the program to be analyzed, and send the suspicious breakpoints to a dynamic performance monitoring channel for event flow detection, thereby obtaining the detection results corresponding to instruction sequence detection and event flow detection (i.e., breakpoints in the static disassembly channel and breakpoints in the dynamic performance monitoring channel). Subsequently, embodiments of this application can use a dependency chain break analysis engine to calculate the comprehensive breakpoint of the suspicious breakpoints based on the detection results, and determine the dependency chain breakpoints based on the comprehensive breakpoints, and generate a detection report containing relevant information about the dependency chain breakpoints.

[0079] Figure 3 This is a schematic diagram illustrating the execution logic of the shared variable dependency chain break detection method of this application. For example... Figure 3 As shown, the execution process of the shared variable dependency chain break detection method of this application is as follows: S301: Compile the program to be analyzed using different compilation options to obtain binary executable programs before and after optimization, and disassemble the binary executable programs before and after optimization to obtain disassembled files before and after optimization respectively; S302: Input the disassembled files before and after optimization into the static disassembler for comparative analysis to detect whether there are suspicious locations where dependency chains are broken. If so, mark the corresponding locations as suspicious breakpoints. S303: Calculate the static disassembly channel break points for each suspected break point; S304: Set performance monitoring points at suspicious breakpoints in the program to be analyzed, and recompile the program to be analyzed after setting performance monitoring points to generate an executable program with performance monitoring points. S305: Input the binary executable program with performance monitoring points into the dynamic performance monitoring channel for execution, and count the number of performance monitoring events related to dependency chain breakage before and after optimization; S306: Calculate the dynamic performance monitoring channel fracture analysis for each suspected fracture point; S307: The dependency chain breakage analysis engine calculates the comprehensive breakage score of suspicious breakpoints based on the breakage score of the static disassembly channel and the breakage score of the dynamic performance monitoring channel. When the comprehensive breakage score exceeds the breakage threshold, the suspicious breakpoint is determined to be a dependency chain breakpoint, and a detection report containing relevant information about the dependency chain breakpoint is generated.

[0080] 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.

[0081] Embodiments of this application also provide a shared variable dependency chain breakage detection device.

[0082] like Figure 4 As shown, the shared variable dependency chain break detection device 10 includes: a disassembly module 100, an identification module 200, a break calculation module 300, and a judgment module 400.

[0083] The disassembly module 100 is used to compile and disassemble the program to be analyzed with and without optimized compilation configuration, respectively, to obtain disassembled files before and after optimization, and to compare and analyze the disassembled files before and after optimization to obtain the corresponding analysis results.

[0084] The identification module 200 is used to identify suspicious breakpoints in the program to be analyzed that meet the preset dependency chain change requirements based on the analysis results, determine the dependency chain change requirement type corresponding to the suspicious breakpoint, and determine the requirement weights corresponding to different requirements in the preset dependency chain change requirements according to the dependency chain change requirement type, so as to calculate the static disassembly channel breakpoint of the suspicious breakpoint through the dependency chain change requirement type and requirement weight.

[0085] The fracture score calculation module 300 is used to set performance monitoring points at suspected fracture points, and to recompile the program to be analyzed after setting performance monitoring points to generate an executable program with performance monitoring points. The executable program with performance monitoring points is run to determine the number of performance monitoring events that meet the preset dependency chain fracture correlation requirements before and after optimization in the program to be analyzed, and to calculate the dynamic performance monitoring channel fracture score of suspected fracture points based on the number of occurrences.

[0086] The determination module 400 is used to calculate the comprehensive break score of the suspected breakpoint based on the break score of the static disassembly channel and the break score of the dynamic performance monitoring channel, and to determine whether the comprehensive break score is greater than the break threshold. When the comprehensive break score is greater than the break threshold, the suspected breakpoint is determined to be a dependency chain breakpoint.

[0087] Optionally, in one embodiment of this application, the disassembly module 100 includes a first compilation unit and a generation unit.

[0088] The first compilation unit is used to compile the program to be analyzed with the optimization compilation configuration disabled to obtain the unoptimized compiled file, and with the optimization compilation configuration enabled to compile the program to be analyzed to obtain the optimized compiled file.

[0089] The generation unit is used to perform disassembly operations on the unoptimized and optimized compiled files respectively to generate corresponding unoptimized and optimized disassembled files.

[0090] Optionally, in one embodiment of this application, the disassembly module 100 further includes a parsing unit and a comparison unit.

[0091] The parsing unit is used to input the disassembled files before and after optimization into a preset static disassembler channel to perform structured code parsing on the disassembled files and generate structured code data containing instruction type, operation object and code location information.

[0092] The comparison unit is used to perform dependency chain comparison on code segments in the disassembled files before and after optimization based on structured code data to obtain corresponding comparison data. Based on the comparison data, it analyzes the code locations in the code segments that meet the preset dependency chain change requirements to obtain analysis results.

[0093] Optionally, in one embodiment of this application, the identification module 200 includes: a determining unit, a judging unit, and a first calculation unit.

[0094] The determining unit is used to determine, based on the analysis results, the code locations in the code segments of the disassembled files before and after optimization of the program to be analyzed that meet the preset dependency chain change requirements, and to use the code locations as the corresponding suspicious breakpoints. The preset dependency chain change requirements include the replacement of data copy instruction sequences with independent memory accesses, the optimization and elimination of intermediate variables, and the change of memory access order.

[0095] The judgment unit is used to determine the type of dependency chain change requirement to which the current suspicious breakpoint belongs, and to assign values ​​to the preset dependency chain change index according to the type of dependency chain change requirement.

[0096] The first calculation unit is used to determine the data copy instruction sequence weight, intermediate variable weight, and memory access order weight corresponding to the suspicious breakpoint based on the dependency chain change requirement type, and to calculate the static disassembly channel breakpoint based on the data copy instruction sequence weight, intermediate variable weight, memory access order weight, and the assigned dependency chain change index.

[0097] Optionally, in one embodiment of this application, the fracture calculation module 300 includes: a setting unit, a second compilation unit, a monitoring unit, a statistics unit, and a second calculation unit.

[0098] The setting unit is used to set performance monitoring points at suspected breakpoints in order to generate corresponding intermediate program code.

[0099] The second compilation unit is used to compile the intermediate code of the program using different compilation options to generate an executable program with performance monitoring points.

[0100] The monitoring unit is used to run an executable program with performance monitoring points in a preset dynamic performance monitoring channel to monitor performance monitoring events that meet the preset dependency chain break correlation requirements before and after optimization.

[0101] The statistics unit is used to count the number of performance monitoring events that meet the preset dependency chain break correlation requirements. The performance monitoring events include the number of first-level cache hits or misses, the number of second-level cache hits or misses, and the number of instruction cycles consumed.

[0102] The second calculation unit is used to calculate the dynamic performance monitoring channel fracture score of suspected fracture points based on the number of occurrences.

[0103] Optionally, in one embodiment of this application, the second calculation unit includes a matrix calculation subunit and a weight calculation subunit.

[0104] The matrix calculation subunit is used to calculate the difference in the number of first-level cache hits, the difference in the number of first-level cache misses, the difference in the number of second-level cache hits, the difference in the number of second-level cache misses, and the difference in the number of instruction cycles consumed before and after optimization. Based on the difference in the number of first-level cache hits, the difference in the number of first-level cache misses, the difference in the number of second-level cache hits, the difference in the number of second-level cache misses, and the difference in the number of instruction cycles consumed, a fracture feature matrix is ​​constructed.

[0105] The weight calculation subunit is used to determine the weights of different performance monitoring events and calculate the dynamic performance monitoring channel fracture based on the fracture feature matrix and the weights of different performance monitoring events.

[0106] Optionally, in one embodiment of this application, the determination module 400 includes: a comparison unit, a first analysis unit, and a second analysis unit.

[0107] The comparison unit is used to perform a fusion calculation on the break points of the static disassembly channel and the break points of the dynamic performance monitoring channel to obtain the comprehensive break points of the suspected break points, and compare the comprehensive break points with the preset break threshold.

[0108] The first analysis unit is used to determine that the corresponding suspicious break point is not a dependent chain break point when the comprehensive break score is less than or equal to the break threshold.

[0109] The second analysis unit is used to determine the corresponding suspicious breakpoint as a dependency chain breakpoint when the comprehensive breakpoint is greater than the breakpoint threshold, and to collect the dependency chain breakpoint information corresponding to the dependency chain breakpoint, so as to generate a corresponding detection report based on the dependency chain breakpoint information.

[0110] Optionally, in one embodiment of this application, the comparison unit includes: a collection subunit, a training subunit, an input subunit, and a calculation subunit.

[0111] The acquisition subunit is used to collect dependency chain break annotation data of historical program samples under different compilation scenarios, as well as the historical static disassembly channel break points and historical dynamic performance monitoring channel break points corresponding to the dependency chain break annotation data.

[0112] The training subunit is used to train a pre-built dependency chain break analysis model based on dependency chain break annotation data, historical static disassembly channel break segments, and historical dynamic performance monitoring channel break segments.

[0113] The input sub-unit is used to input the static disassembly channel breakage score and the dynamic performance monitoring channel breakage score into the trained dependency chain breakage analysis model, so as to output the static disassembly channel weight corresponding to the static disassembly channel breakage score, the dynamic performance monitoring channel weight corresponding to the dynamic performance monitoring channel breakage score, and the breakage threshold.

[0114] The operation subunit is used to calculate the comprehensive break score based on the static disassembly channel break score, the static disassembly channel weight, the dynamic performance monitoring channel break score, and the dynamic performance monitoring channel weight.

[0115] Optionally, in one embodiment of this application, the shared variable dependency chain break detection device 10 further includes: an acquisition module, an evaluation module, and an optimization module.

[0116] The acquisition module is used to acquire the dependency chain breakpoint information of the detection report after generating the corresponding detection report based on the dependency chain breakpoint information, and to construct a standardized analysis dataset based on the dependency chain breakpoint information.

[0117] The evaluation module is used to evaluate the dependency chain breakpoint detection performance of the static disassembly channel and the dynamic performance monitoring channel based on a standardized analysis dataset, so as to obtain the corresponding evaluation results.

[0118] The optimization module is used to identify defect information in the dependency chain breakpoint detection process based on the evaluation results, adjust the weights of the static disassembly channel and the dynamic performance monitoring channel according to the defect information, and calculate a new comprehensive breakpoint using the adjusted weights of the static disassembly channel and the dynamic performance monitoring channel, so as to re-perform the dependency chain breakpoint determination operation with the new comprehensive breakpoint.

[0119] For a description of the features in the embodiment of the shared variable dependency chain break detection device, please refer to the relevant description of the embodiment of the shared variable dependency chain break detection method, which will not be repeated here.

[0120] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above embodiments of the shared variable dependency chain break detection method.

[0121] Embodiments of this application also provide a non-volatile computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above embodiments of the shared variable dependency chain break detection method at runtime.

[0122] In one exemplary embodiment, the aforementioned non-volatile computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0123] The embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above embodiments of the shared variable dependency chain break detection method.

[0124] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above embodiments of the shared variable dependency chain break detection method.

[0125] 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.

[0126] The foregoing has provided a detailed description of a method, apparatus, device, and medium for detecting broken shared variable dependency chains. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for detecting broken shared variable dependency chains, characterized in that, Includes the following steps: The program to be analyzed is compiled and disassembled with the optimization compilation configuration disabled and with the optimization compilation configuration enabled, respectively, to obtain disassembled files before and after optimization. The disassembled files before and after optimization are compared and analyzed to obtain the corresponding analysis results. Based on the analysis results, suspicious breakpoints in the program to be analyzed that meet the preset dependency chain change requirements are identified, and the dependency chain change requirement type corresponding to the suspicious breakpoint is determined. The requirement weights corresponding to different requirements in the preset dependency chain change requirements are determined according to the dependency chain change requirement type, so as to calculate the static disassembly channel breakpoint of the suspicious breakpoint through the dependency chain change requirement type and the requirement weight. Performance monitoring points are set at the suspected breakpoints, and the program to be analyzed after setting the performance monitoring points is recompiled to generate an executable program with performance monitoring points. The executable program with performance monitoring points is run to determine the number of performance monitoring events that meet the preset dependency chain break correlation requirements before and after optimization of the program to be analyzed. The dynamic performance monitoring channel break score of the suspected breakpoint is calculated based on the number of occurrences. The composite breakpoint of the suspected breakpoint is calculated based on the breakpoint of the static disassembly channel and the breakpoint of the dynamic performance monitoring channel, and it is determined whether the composite breakpoint is greater than the breakpoint threshold. If the composite breakpoint is greater than the breakpoint threshold, the suspected breakpoint is determined to be a dependency chain breakpoint.

2. The method for detecting broken shared variable dependency chains according to claim 1, characterized in that, The compilation and disassembly operations performed on the program to be analyzed to obtain disassembled files before and after optimization include: With the optimization compilation configuration disabled, the program to be analyzed is compiled to obtain the unoptimized compiled file; with the optimization compilation configuration enabled, the program to be analyzed is compiled to obtain the optimized compiled file. Disassembly operations are performed on the unoptimized and optimized compiled files respectively to generate corresponding unoptimized and optimized disassembled files.

3. The method for detecting broken shared variable dependency chains according to claim 2, characterized in that, The comparative analysis of the disassembled files before and after optimization yields the following analysis results: The disassembled files before and after optimization are input into a preset static disassembler channel to perform code structured parsing on the disassembled files respectively, generating structured code data containing instruction type, operation object and code location information; Based on the structured code data, dependency chain comparison is performed on the code segments in the disassembled files before and after optimization to obtain corresponding comparison data. The code locations in the code segments that meet the preset dependency chain change requirements are analyzed based on the comparison data to obtain the analysis results.

4. The method for detecting broken shared variable dependency chains according to claim 3, characterized in that, Based on the analysis results, the process involves identifying suspicious breakpoints in the program to be analyzed that meet preset dependency chain change requirements, determining the dependency chain change requirement type corresponding to the suspicious breakpoints, and determining the requirement weights corresponding to different requirements in the preset dependency chain change requirements based on the dependency chain change requirement type. This is then used to calculate the static disassembly channel breakpoint score of the suspicious breakpoint using the dependency chain change requirement type and the requirement weights. Based on the analysis results, the code locations in the code segments of the disassembled files before and after optimization of the program to be analyzed that meet the preset dependency chain change requirements are determined, and the code locations are used as the corresponding suspicious breakpoints. The preset dependency chain change requirements include data copy instruction sequences being replaced with independent memory accesses, intermediate variables being optimized and eliminated, and memory access order being changed. Determine the dependency chain change requirement type to which the current suspected breakpoint belongs, and assign values ​​to the preset dependency chain change index according to the dependency chain change requirement type; Based on the dependency chain change requirement type, the data copy instruction sequence weight, intermediate variable weight, and memory access order weight corresponding to the suspected breakpoint are determined, and the static disassembly channel breakpoint is calculated based on the data copy instruction sequence weight, the intermediate variable weight, the memory access order weight, and the assigned dependency chain change index.

5. The method for detecting broken shared variable dependency chains according to claim 1, characterized in that, The process involves setting performance monitoring points at the suspected breakpoints, recompiling the program to be analyzed after setting the performance monitoring points to generate an executable program with performance monitoring points, and running the executable program with performance monitoring points to determine the number of performance monitoring events that meet the preset dependency chain break correlation requirements before and after optimization in the program to be analyzed. The process also includes calculating the dynamic performance monitoring channel break score of the suspected breakpoint based on the number of occurrences. The performance monitoring point is set at the suspected breakpoint to generate the corresponding intermediate program code; The intermediate code of the program is compiled using different compilation options to generate the executable program with performance monitoring points; The executable program with performance monitoring points is run in the preset dynamic performance monitoring channel to monitor performance monitoring events that meet the preset dependency chain break correlation requirements before and after optimization. The number of performance monitoring events that meet the preset dependency chain break correlation requirements is counted. The performance monitoring events include the number of first-level cache hits or misses, the number of second-level cache hits or misses, and the number of instruction cycles consumed. Based on the number of occurrences, the dynamic performance monitoring channel fracture score of the suspected fracture point is calculated.

6. The method for detecting broken shared variable dependency chains according to claim 5, characterized in that, The calculation of the dynamic performance monitoring channel fracture score of the suspected fracture point based on the number of occurrences includes: Calculate the difference in the number of first-level cache hits, the difference in the number of first-level cache misses, the difference in the number of second-level cache hits, the difference in the number of second-level cache misses, and the difference in the number of instruction cycles consumed before and after optimization. Based on the difference in the number of first-level cache hits, the difference in the number of first-level cache misses, the difference in the number of second-level cache hits, the difference in the number of second-level cache misses, and the difference in the number of instruction cycles consumed, construct a fracture feature matrix. The weights of different performance monitoring events are determined, and the fracture score of the dynamic performance monitoring channel is calculated based on the fracture feature matrix and the weights of the different performance monitoring events.

7. The method for detecting broken shared variable dependency chains according to claim 1, characterized in that, The step of calculating the comprehensive breakpoint of the suspected breakpoint based on the breakpoint of the static disassembly channel and the breakpoint of the dynamic performance monitoring channel, and determining whether the comprehensive breakpoint is greater than the breakpoint threshold, wherein, when the comprehensive breakpoint is greater than the breakpoint threshold, the suspected breakpoint is determined to be a dependency chain breakpoint, including: The static disassembly channel break score and the dynamic performance monitoring channel break score are fused and calculated to obtain the comprehensive break score of the suspected break point, and the comprehensive break score is compared with a preset break threshold. When the comprehensive fracture score is less than or equal to the fracture threshold, the corresponding suspicious fracture point is determined to be a dependency chain fracture point. When the overall fracture score is greater than the fracture threshold, the corresponding suspicious fracture point is determined to be a dependency chain fracture point, and the dependency chain fracture point information corresponding to the dependency chain fracture point is collected to generate a corresponding detection report based on the dependency chain fracture point information.

8. The method for detecting broken shared variable dependency chains according to claim 7, characterized in that, The process of fusing the static disassembly channel breakpoints and the dynamic performance monitoring channel breakpoints to obtain the comprehensive breakpoint score for the suspected breakpoint includes: Collect dependency chain breakage annotation data of historical program samples under different compilation scenarios, and the corresponding historical static disassembly channel breakage score and historical dynamic performance monitoring channel breakage score of the dependency chain breakage annotation data; Based on the dependency chain break annotation data, the historical static disassembly channel break scores, and the historical dynamic performance monitoring channel break scores, a pre-built dependency chain break analysis model is trained. The static disassembly channel break score and the dynamic performance monitoring channel break score are input into the trained dependency chain break analysis model to output the static disassembly channel weight corresponding to the static disassembly channel break score, the dynamic performance monitoring channel weight corresponding to the dynamic performance monitoring channel break score, and the break threshold. The comprehensive break score is calculated based on the break score of the static disassembly channel, the weight of the static disassembly channel, the break score of the dynamic performance monitoring channel, and the weight of the dynamic performance monitoring channel.

9. The method for detecting broken shared variable dependency chains according to claim 7, characterized in that, After generating the corresponding detection report based on the dependency chain breakpoint information, the process also includes: Obtain the dependency chain breakpoint information from the detection report, and construct a standardized analysis dataset based on the dependency chain breakpoint information; Based on the standardized analysis dataset, the dependency chain breakpoint detection performance of the static disassembly channel and the dynamic performance monitoring channel is evaluated to obtain the corresponding evaluation results. Based on the evaluation results, defect information in the dependency chain breakpoint detection process is identified, and the weights of the static disassembly channel and the dynamic performance monitoring channel are adjusted according to the defect information. A new comprehensive breakpoint score is calculated using the adjusted static disassembly channel weights and dynamic performance monitoring channel weights, so that the dependency chain breakpoint determination operation is performed again using the new comprehensive breakpoint score.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the shared variable dependency chain break detection method as described in any one of claims 1 to 9 when executing the computer program.

Citation Information

Patent Citations

  • Software vulnerability detection method based on static analysis and dynamic analysis

    CN116049831A

  • Vulnerability identification method based on semantic learning of slice code dependency graph

    CN116305158A

  • System and method for automatic decompilation and detection of errors in software

    US20230236564A1