Function call chain construction method and electronic equipment

Abstract

The invention discloses a function call chain construction method and electronic equipment, and relates to the technical field of software engineering.A first function link diagram which is obtained through static code analysis and contains a complete call relation is combined with a second function link diagram which is obtained through non-intrusive dynamic tracking and contains software actual operation behaviors, and a function call chain is constructed. A target function link diagram is created in a child-mother diagram fusion mode, the advantage of comprehensive coverage of static analysis is inherited, all possible function call paths can be displayed to ensure the integrity of links, the advantage of reflecting real execution by dynamic analysis is integrated, the actually called function and the execution frequency can be accurately identified, and meanwhile, the efficiency of dynamic analysis is improved. The non-intrusive tracking point setting effectively avoids code invasiveness, so that the authenticity and reliability of the call chain data are ensured under extremely low overhead.

Description

Technical Field

[0001] This application relates to the field of software engineering technology, and in particular to a method for constructing a function call chain and an electronic device. Background Technology

[0002] Function call chains play a crucial role in system debugging, performance optimization, and code analysis. During system debugging, function call chains can be used to quickly locate the root cause of problems; during performance optimization, they can identify redundant or unreasonable calls; and during code analysis, they help to understand the execution logic of complex or legacy systems.

[0003] When constructing function call chains, static analysis or dynamic analysis is usually used. However, among the related technologies, static analysis cannot reflect the actual behavior of the program system at runtime and cannot identify redundant functions and call relationships. Dynamic analysis has limited coverage and has significant performance overhead and intrusion, making it difficult to construct a complete and realistic function call chain. Summary of the Invention

[0004] This application provides a method and electronic device for constructing a function call chain, so as to at least solve the problem of how to construct a complete and realistic function call chain in the related art.

[0005] This application provides a method for constructing a function call chain, including: By performing static code analysis on the target program, multiple function call chains in the target program are determined, and multiple preset function call chains to be analyzed are determined from the multiple function call chains. Each function call chain includes the call relationship between multiple functions in the target program. The multiple target functions included in the target function call chain are identified as multiple observable functions. The multiple observable functions are taken as first nodes, and directed edges are created between the multiple first nodes based on the call relationship to obtain the first function link graph. Multiple non-intrusive function trace points are created for each of the observed functions, and the calling functions and the number of times each of the observed functions is called are obtained based on the function trace points during the execution of the target program. A link graph is created based on multiple observed functions, calling functions, and the number of times they are called, resulting in a second function link graph. This second function link graph is then used as a subgraph of the first function link graph for link graph fusion processing to obtain the target function link graph.

[0006] This application also provides a device for constructing a function call chain, comprising: The first determining unit is used to determine multiple function call chains in the target program by performing code analysis on the target program. The second determining unit is used to determine the target function call chain in which each of the multiple preset functions to be analyzed is located from multiple function call chains, wherein each function call chain includes the call relationship between multiple first functions in the target program; The second determining unit is also used to determine multiple objective functions included in the objective function call chain as multiple observable functions; The first construction unit is used to take multiple functions to be observed as first nodes, and to create directed edges between multiple first nodes based on the calling relationship to obtain the first function link graph; Create a unit to create non-intrusive function tracking points for each of the multiple functions to be observed; The acquisition unit is used to acquire, based on function tracing points, the calling functions and the number of times each of the multiple observable functions during the execution of the target program is called; The second building unit is used to create a link graph based on multiple observable functions, calling functions, and the number of times they are called, to obtain a second function link graph; The fusion unit is used to perform link graph fusion processing on the second function link graph as a subgraph of the first function link graph to obtain the target function link graph.

[0007] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of constructing any of the above-described function call chains when executing the computer program.

[0008] This application also provides a 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 constructing a function call chain.

[0009] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of constructing any of the above-described function call chains.

[0010] This application discloses a method and electronic device for constructing function call chains. By combining a first function link graph containing complete call relationships obtained through static code analysis with a second function link graph containing actual runtime behavior of the software obtained through non-intrusive dynamic tracing, and using a parent-child graph fusion approach to create the target function link graph, it inherits the comprehensive coverage advantage of static analysis, which can display all possible function call paths to ensure the integrity of the link, while incorporating the advantage of dynamic analysis, which reflects actual execution and can accurately identify the actually called functions and their execution frequency. Simultaneously, the non-intrusive tracing point setting effectively avoids code intrusion, thus ensuring the authenticity and reliability of the call chain data with extremely low overhead. Therefore, it can simultaneously solve the technical problems of static analysis's inability to reflect runtime behavior and identify redundant calls, and dynamic analysis's limited coverage, high performance overhead, and high intrusiveness, achieving the technical effect of constructing a complete and realistic function call chain. 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 A flowchart illustrating a method for constructing a function call chain, as provided in an embodiment of this application; Figure 2 This application provides a schematic diagram of the construction of a first function link graph according to an embodiment of the present application. Figure 3 This is a schematic diagram illustrating the construction of a second function link graph provided in an embodiment of this application; Figure 4 This application provides a schematic diagram of the construction of an objective function link graph. Figure 5 A schematic diagram of a function call chain construction apparatus provided in an embodiment of this application; Figure 6 This is a schematic diagram of another function call chain construction device provided in an embodiment of this application. Detailed Implementation

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

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

[0015] This application discloses a method for constructing a function call chain. By combining static analysis and dynamic tracing techniques, it constructs a function link graph that can comprehensively reflect the program's structural characteristics and runtime behavior. This enables accurate sorting and visualization of the function call relationships of the target program, effectively solving the problems of static analysis failing to reflect real runtime behavior and dynamic analysis being highly intrusive in traditional function call chain construction techniques.

[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] Figure 1 This document provides a flowchart illustrating a method for constructing a function call chain, as provided in an embodiment of this application. The method is described in detail below, taking into account the execution flow of the method for constructing a function call chain.

[0018] like Figure 1 As shown, the method for constructing this function call chain includes: Step 101: By performing static code analysis on the target program, multiple function call chains in the target program are determined, and multiple preset function call chains to be analyzed are determined from the multiple function call chains. Each function call chain includes the call relationship between multiple functions in the target program.

[0019] In the embodiments of this application, static code analysis is performed on the target program to determine its internal function call chains. Static code analysis refers to deriving the call relationships and nested structures between functions in the target program by parsing the program's source code, intermediate code, or binary code without actually running the program. This reveals all possible execution paths of the target program, forming function call chains composed of function nodes and their call relationships. Each function call chain clearly demonstrates the calling order and hierarchical relationship between multiple functions in the target program; that is, each function call chain includes multiple functions in the target program and the call relationships between them.

[0020] After completing a comprehensive static analysis, the parts related to several specified pre-defined functions to be analyzed are selected from all identified function call chains; these are known as target function call chains. Pre-defined functions to be analyzed refer to certain entry functions or core modules pre-specified based on debugging or performance analysis needs. A target function call chain is a chain that contains at least one pre-defined function to be analyzed and fully demonstrates the call path originating from or reaching that function. By identifying the target function call chain, the focus of analysis is narrowed from the vast network of call relationships throughout the entire program to a localized area closely related to the specific analysis objective.

[0021] Step 102: Determine the multiple target functions included in the target function call chain as multiple observation functions, take the multiple observation functions as first nodes, and create directed edges between the multiple first nodes based on the call relationship to obtain the first function link graph.

[0022] In the embodiments of this application, all functions involved in the target function call chain are extracted to form a set of functions to be observed. A function to be observed refers to a specific function existing in the target function call chain. Then, a first function link graph is constructed based on this set of functions to be observed.

[0023] During the construction process, each function to be observed is considered a first node, that is, a vertex in the graph structure of the first function link graph. Based on the function call relationships determined by static analysis, directed edges are created between the first nodes. A directed edge is a connection line with a direction, used to represent the call direction between functions. For example, a node pointing from function A to function B indicates that function A is called by function B. By visualizing the call relationships obtained from static analysis as a graph structure, namely the first function link graph, all possible function call paths at the code level are shown macroscopically.

[0024] Step 103: Create non-intrusive function trace points for each of the multiple functions to be observed, and obtain the calling functions and the number of times each function is called during the execution of the target program based on the function trace points.

[0025] In the embodiments of this application, during the dynamic analysis phase, non-intrusive function trace points are created for multiple functions to be observed. Non-intrusive function trace points are dynamic tracing techniques based on system-level mechanisms (such as the kprobes / uprobes mechanism of the Linux kernel). They are probe points temporarily inserted at specified function entry or return points without continuously modifying the original source code of the target program or restarting the target program.

[0026] When the target program reaches a function trace point, relevant information is collected, and the original instructions are automatically restored after execution, thus achieving transparent monitoring of the target program's runtime status. Through function trace points, information can be captured about which function calls each of the observed functions during the actual execution of the target program, i.e., the calling function, and the frequency of execution of each call path, i.e., the number of times it is called. This runtime information of the target program cannot be provided by static analysis, and it truly reflects the actual behavior of the target program in a specific scenario.

[0027] Step 104: Create a link graph based on multiple observed functions, calling functions, and the number of times they are called to obtain a second function link graph. Then, use the second function link graph as a subgraph of the first function link graph for link graph fusion processing to obtain the target function link graph.

[0028] In the embodiments of this application, the construction of the second function link graph is also based on multiple functions to be observed and their calling relationships, but the calling relationships and data weights here come from dynamic tracking results, namely the calling functions and the number of times they are called.

[0029] The second function link graph accurately depicts the actual call paths executed during the execution of the target program, as well as the execution frequency of each call path. Finally, link graph fusion processing is performed, integrating the second function link graph as a subgraph of the first function link graph. A subgraph is a graph in which the nodes and edges of one graph are completely contained within another larger graph. This means that the actual dynamic call paths (second function link graph) are superimposed on all possible static call paths (first function link graph).

[0030] Link graph fusion processing can be achieved through, but is not limited to, visual or data association techniques, combining the first function link graph and the second function link graph into one, ultimately generating the target function link graph.

[0031] This application constructs an objective function link graph, which represents the comprehensive results of dynamic and static analysis. It not only fully presents all potential calling logic in the target program's code, but also highlights or marks the calling paths and their frequencies that occur during actual operation, thereby clearly revealing uncovered code segments and performance hotspots, providing extremely intuitive and in-depth insights for program optimization and debugging.

[0032] In one possible implementation of this application embodiment, when constructing the first function link graph, the following methods may be used, but are not limited to: determining the first target node and at least one first calling node corresponding to the first target node based on the calling relationship, wherein the first target node is any node among a plurality of first nodes, and the first calling node is the first node that calls the first target node; creating directed edges from the first target node to at least one first calling node, until directed edge creation processing is performed on all the plurality of first nodes to obtain the first function link graph.

[0033] In the embodiments of this application, the first target node is the function node selected as the focus of relational analysis in the current processing stage. It is any one of multiple sets of first nodes, representing a function to be observed. The set of first nodes is traversed, and each node is set as the first target node for processing in turn, ensuring the integrity of the call relationship.

[0034] After identifying the first target node, based on the call relationships determined through static code analysis, all other nodes that directly call the first target node are identified; these are the first calling nodes. In other words, in the static call chain of the target program, the function corresponding to the first calling node directly calls the function corresponding to the first target node at the code level. Each first calling node has a clear call chain with the first target node. Identifying all first calling nodes related to the current first target node, these multiple first calling nodes together constitute the source set that calls the first target node.

[0035] Next, directed edges connecting the nodes in the graph are created. Specifically, directed edges are created from the first target node to one of its corresponding first calling nodes. A directed edge is a connection line with a direction, used to precisely represent the calling direction between functions. It should be noted that the pointing relationship here is related to the calling direction, that is, from the called function to the calling function, which clearly indicates the attribution of calling responsibility. A directed edge is created between the first target node and each corresponding first calling node, thus completing all the edges of the first target node (i.e., edges pointing to the first target node).

[0036] The above process involves identifying a primary target node, finding all its primary calling nodes, and creating directed edges from the primary target node to each primary calling node, constituting a basic processing procedure. This process is executed iteratively until directed edges have been created for multiple primary nodes. Each primary node in the set is processed as a primary target node in turn, ensuring that all calling relationships identified by static analysis are accurately represented in the graph as directed edges.

[0037] The construction of the first function link graph (static function call chain graph) can be achieved, but is not limited to, the following methods: First, deduce the static function call chain of the entire target program system by parsing binary code (or intermediate code or source code), forming a static function call chain library. Then, read the user-defined set of functions to be analyzed, extract all functions related to the set from the static function call chain library, forming a set of functions to be observed. Based on the call relationships of the functions to be observed, the static function call chain graph can be constructed. The method for forming the set of functions to be observed is as follows: traverse each function in the set of functions to be analyzed, extract the corresponding call chain from the static function call chain library, add all functions on that call chain to the set of functions to be observed, and the resulting set of functions to be observed is the final set of functions to be observed. The method for constructing the static function call chain graph is as follows: construct each function in the set of functions to be observed as a node in the graph; if function A is called by function B, create a directed edge from node A to node B; if function A is called by itself, create a directed edge from node A to itself.

[0038] Specifically, to facilitate understanding of the implementation process of this application, embodiments of this application provide a schematic diagram of the construction of a first function link graph, such as... Figure 2 As shown, the process involves deriving multiple static function call chains of the entire target program by parsing its binary code (a.out), forming a static function call chain library (static.lib). Then, a custom set of functions to be analyzed, {func1, func2, func3}, is read, and all functions related to this set are extracted from the static function call chain library, forming a set of functions to be observed, {func1, func2, func3, func4, func5, func6, func7, func8, func9}. Finally, a static function call chain graph, i.e., the first function link graph (static.graph), is constructed based on the call relationships of the functions to be observed.

[0039] The first function link graph created by this application can systematically depict the potential call network between all the functions to be observed through nodes and directed edges, ensuring the accuracy of the call relationship expression and the integrity of the graph structure, and enabling intuitive control over the static structure of the target program.

[0040] In one possible implementation of this application embodiment, when creating the second function link graph, it can be implemented in the following ways, but not limited to: creating multiple directed edges pointing to their respective corresponding calling functions to obtain an initial link graph, wherein the calling function is a function that calls multiple functions to be observed during the execution of the target program, and the number of times the multiple functions to be observed are called by their respective corresponding calling functions; the number of times the functions to be observed are marked to the directed edges pointing to their respective corresponding calling functions to obtain the second function link graph.

[0041] In the embodiments of this application, the initial link graph is a basic directed graph structure, whose node set consists of multiple functions to be observed. When creating the initial link graph, information about the actual calls made to each function during its execution is determined, i.e., its corresponding calling function is determined. The calling function refers to the parent function of a function to be observed that is activated by executing a calling instruction during the execution of the target program, reflecting the actual source of the call in the execution flow of the target program.

[0042] Based on this dynamic calling relationship, a directed edge is created from the called function node to its calling function node. The directionality of this directed edge is crucial, clearly indicating the flow of responsibility in the calling relationship, i.e., from the callee to the caller. Once the pointing relationships are established for all the functions to be observed and all their corresponding calling functions, an initial link graph containing multiple calling paths is formed.

[0043] After establishing the basic call relationship graph, i.e., the initial link graph, execution frequency information needs to be incorporated. This can be achieved by integrating the call count. The call count is a runtime metric that records the total number of times a specific function being observed is successfully called by its corresponding calling function during the execution of the target program. This call count directly reflects the activity and execution frequency of the call path. To visually represent this information, the value of each call count is labeled onto its corresponding directed edge. Specifically, clear numerical labels are added next to the previously created directed lines from the function being observed to its calling function.

[0044] The construction of the second function call graph (dynamic function call graph) can be achieved, but is not limited to, the following: Utilizing the kretprobes / uretprobes mechanism of perf probe, function return tracepoints are created for each function in the set of functions to be observed in the binary code of the target program. Afterward, the target program is run, and perf probe automatically collects the return point addresses (calling functions) of the functions to be observed, as well as the execution counts (number of calls) of each return point. Based on the information collected by perf probe, a dynamic function call graph, i.e., the second function call graph, can be constructed. perfprobe is a sub-tool of perf, a performance analysis tool built into the Linux system, allowing users to dynamically create tracepoints at any location in the kernel or user space. The process of perf probe creating tracepoints is non-intrusive: the target program's code is only dynamically replaced when it reaches a tracepoint, and it is restored to its original state once execution is complete.

[0045] Specifically, to facilitate understanding of the implementation process of this application, embodiments of this application provide a schematic diagram of the construction of a second function link graph, such as... Figure 3 As shown, the perf probe mechanism uses kretprobes / uretprobes to create function return trace points for each function in the set of functions to be observed in the binary code of the target program system. After running the target program system, the perf probe automatically collects the return point addresses (calling functions) of the functions to be observed, as well as the execution count of each return point. Based on the information collected by the perf probe, a dynamic function call chain graph, i.e., the second function link graph (dynamic.graph), is constructed. The second function link graph created through this application is no longer merely a static call relationship topology, but a visualization tool carrying rich dynamic execution information. Each directed edge in the graph not only indicates the call relationship, but also intuitively shows the number of times this path is called through the labeled values ​​on the directed edge. It can quickly identify high-frequency call paths (i.e., hot paths) and rarely executed or even never triggered edge paths in the target program, greatly facilitating in-depth analysis of the target program's runtime behavior and performance optimization.

[0046] In one possible implementation of this application embodiment, when constructing the target function link graph, the following methods can be used, but are not limited to: treating the second function link graph as a subgraph of the first function link graph and performing link graph fusion processing to obtain a fused function link graph; and using a preset visual algorithm to identify the subgraph portion corresponding to the second function link graph in the fused function link graph to obtain the target function link graph.

[0047] In the embodiments of this application, the link graph fusion process is a process of superimposing and semantically associating two graph structures that have an inclusion relationship. Specifically, it involves embedding a second function link graph that accurately reflects the program's runtime behavior as a subgraph of a first function link graph that displays the complete static structure of the target program. Through this embedding operation, a unified fused function link graph is generated. The fused function link graph is a composite data view that simultaneously carries static code structure information and dynamic runtime information, forming a complete analysis basis.

[0048] To ensure significant visual differentiation of dynamic execution paths within a unified view, a pre-defined visual algorithm is introduced. This algorithm consists of predefined computer graphics rules for visually enhancing and classifying graphical elements. The algorithm is applied to the fused function link graph, processing the subgraph portion corresponding to the second function link graph within the fused function link graph. This subgraph portion, within the fused function link graph, is a set of graph elements whose nodes and edges exist not only in the first function link graph but also in the second function link graph, representing the functions and call paths actually executed during the current run of the target program.

[0049] Identification processing refers to the technique of altering the visual attributes of graphic elements to make them stand out within the overall graph. This typically includes, but is not limited to, assigning nodes and edges of subgraphs distinct colors, thicknesses, line styles, fill patterns, or dynamic blinking effects from other elements. For example, actually executed paths can be rendered with highlighted colors and thick lines, while statically existing but not executed paths can be displayed as thin gray lines. Through this differentiated visual encoding, executed and unexecuted paths, as well as hot and cold code points, are clearly presented.

[0050] The construction of the target function call graph (dynamic and static function call graph) can be achieved in, but is not limited to, the following ways: Summarize the static and dynamic function call graphs to form a dynamic and static function call graph; treat the dynamic function call graph as a subgraph of the static function call graph, highlight the subgraph using visual encoding or other methods, and finally form a parent function call graph. Figure 1 It clearly shows which function call paths are not overridden and which function call paths are execution hotspots.

[0051] Specifically, to facilitate understanding of the implementation process of this application, embodiments of this application provide a schematic diagram of the construction of an objective function link graph, such as... Figure 4As shown, the static function call graph (static.graph) and the dynamic function call graph (dynamic.graph) are combined to form a dynamic-static function call graph (call.graph): the dynamic function call graph is considered a subgraph of the static function call graph, and the subgraph is highlighted through visual encoding and other means, finally forming a parent graph of function call chains, as shown. Figure 4 As shown, the chain can be chained via function calls. Figure 1 It clearly shows which function call paths are not overridden, such as func1->func2; and which function call paths are execution hotspots, such as func2->func8.

[0052] The target function link diagram created by this application is no longer a simple structure diagram, but an analytical result with clear information hierarchy and powerful insight. It successfully integrates the program's capabilities (all possible calls) and behaviors (actual calls) into the same view, and clearly identifies the intersection and differences between the two through visual means, which greatly improves the speed and accuracy of code coverage analysis, performance bottleneck location and system understanding.

[0053] In one possible implementation of this application, after obtaining the target function link graph, it is necessary to extract key information on uncalled paths and hot-spot called paths from the target function link graph, and use intuitive annotations and clear prompts to assist developers in carrying out subsequent code optimization, testing and improvement work.

[0054] Specifically, but not limited to the following methods can also be used: perform image recognition processing on the target function link graph to obtain recognition results; in response to the recognition result that there are uncalled paths, mark the uncalled paths and generate path redundancy prompt information based on the uncalled paths; in response to the recognition result that there are hot call paths, mark the hot call paths and generate key path prompt information based on the hot call paths.

[0055] In the embodiments of this application, image recognition processing refers to an automated parsing and analysis technique for nodes, edges, and their visual attributes in a graph data structure. It scans the entire objective function link graph structure, identifies the semantic information represented by different visual encodings, and particularly obtains structured recognition results by comparing the differences between static paths and dynamically identified paths. The recognition results are a machine-readable summary of the program behavior characteristics contained in the graph, systematically revealing the actual execution state of the call path.

[0056] Uncalled paths refer to directed edges and their connected node sequences that exist in the first function link graph but do not appear in the second function link graph generated during this execution; in other words, function call relationships written in the code but not executed. Uncalled paths will then be marked, possibly using a visual scheme that contrasts sharply with the highlighted execution paths, such as using dashed lines, gray tones, or special icons for clear visual distinction. Based on this, path redundancy warnings will be automatically generated for the uncalled paths. These warnings can be text or graphical, and their content aims to inform developers or testers of uncovered code segments in the program. Path redundancy warnings are crucial for evaluating the coverage completeness of test cases and identifying useless code or potential program logic errors.

[0057] Hotspot call paths refer to call chains in the second function chain graph whose execution frequency is significantly higher than other paths, identified by the number of calls marked on the directed edges. Hotspot call paths are usually system performance bottlenecks or key business logic locations. These hotspot call paths are then marked, and the visual approach used here aims to further enhance their prominence, for example, by using more eye-catching warm colors (such as red and orange), increasing the width of the edges, or adding dynamic effects. Simultaneously, key path prompts are generated based on the hotspot call paths. These key path prompts highlight the analysis conclusions of critical execution paths, guiding developers to prioritize high-frequency execution areas and providing clear direction for performance optimization, caching design, or strengthening and monitoring core logic.

[0058] This application, through the aforementioned image recognition, annotation processing, and prompt generation process, transforms the objective function link diagram from a static graphical display into a tool with analytical and guiding capabilities. This helps developers quickly discover potentially redundant paths that are not being called, and accurately locates high-frequency execution paths that require key optimization. It fully leverages the advantages of combining dynamic and static analysis, providing deeper support for system debugging, performance optimization, code maintenance, and other tasks.

[0059] In one possible implementation of this application embodiment, when performing image recognition processing on the target function link graph, it can be implemented in the following ways, but not limited to: determining the identified part of the target function link graph as the subgraph part corresponding to the second function link graph, and determining the unidentified part of the target function link graph as the parent graph part corresponding to the first function link graph; determining the call path in the parent graph part that is not covered by the subgraph part as the uncalled path, wherein the call path is determined by the directed edge in the target function link graph; and determining the call path with the highest number of calls in the subgraph part as the hot call path.

[0060] In the embodiments of this application, the entire target function link graph structure is scanned according to visual rules set by a preset visual algorithm. All nodes and edges with specific visual identifiers are grouped into one category, and this part is identified as the identified part. The identified part is the area that is particularly emphasized during the fusion process; it intuitively corresponds to the trajectory traversed by the actual program execution. Based on this, the identified part is explicitly identified and defined as the subgraph part corresponding to the second function link graph. The subgraph part is a logical subset that contains all function nodes and their call relationships verified to exist during dynamic program execution.

[0061] Meanwhile, the remaining area in the target function link graph after removing the marked parts—that is, the nodes and edges not marked by special visual identifiers—is determined as the parent graph part corresponding to the first function link graph. The parent graph part represents all possible call relationship frameworks possessed by the program, derived from static analysis, and constitutes the complete background of the entire function call chain. As an inclusive underlying framework, the parent graph part clearly demonstrates all design possibilities at the code level.

[0062] Based on the subgraph and parent graph of the successful region, a set subtraction operation is performed, specifically comparing the path sets. All call paths present in the parent graph are compared with the actual paths present in the subgraph. A call path is a sequence of continuous, directional edges in the target function link graph, representing a complete function call chain. Through fine-grained comparison, paths present in the parent graph but absent in the subgraph can be precisely located; these paths are formally identified as uncalled paths. Uncalled paths reveal execution logic that has been written in the code but not activated during this runtime, providing direct evidence for test coverage analysis and redundant code identification.

[0063] For the subgraph portion, a different dimension of analysis is performed. The call count information for each call path within the subgraph is traversed. By comparing the call count values, specific chains with significantly higher call counts than other paths can be identified. Paths with significantly higher execution frequency are identified as hotspot call paths. Hotspot call paths are the busiest and most frequently executed code channels during program runtime, and they are crucial for locating performance bottlenecks, optimizing resource allocation, and understanding the flow of core business logic.

[0064] This application employs the image recognition process described above, which distinguishes between parent and subgraphs, identifies uncalled paths, and identifies frequently called paths. The final recognition result not only includes qualitative conclusions about the existence of uncalled paths and frequently called paths, but also specific information about the two types of paths (such as the path's node sequence, directed edge identifiers, and the number of times it has been called). This recognition process relies entirely on the existing visual features and annotation information of the objective function link graph, without introducing external data or complex algorithms. This ensures the accuracy and reliability of the recognition results and provides precise and detailed basic data for annotation processing and prompt information generation for the two types of paths, further enhancing the practical value of the objective function link graph in system debugging and performance optimization.

[0065] In one possible implementation of this application embodiment, when creating non-intrusive function trace points, the following methods can be used, but are not limited to: through the dynamic tracing mechanism of a preset performance analysis tool, non-intrusive function trace points are set for each of the multiple functions to be observed in the binary code of the target program, wherein the preset performance analysis tool is used to non-intrusively create trace points at any position in the binary code.

[0066] In the embodiments of this application, the preset performance analysis tool is a system-level diagnostic and performance profiling software built into the operating system level. It has the ability to deeply observe running programs and can dynamically intervene in the compiled machine instructions without modifying the source code of the target program or recompiling, thus achieving non-intrusive analysis.

[0067] Dynamic tracing is a complex infrastructure provided by the operating system kernel that allows temporary probe points to be dynamically inserted at specific locations in the code during the execution of the target program. These probe points can capture context information at the point of execution, such as function parameters and return addresses, and this capture process is completed while the target program is running normally.

[0068] The creation of tracepoints occurs within the target program's binary code. The target program's binary code refers to a sequence of machine instructions that has been compiled and linked and can be directly executed by a computer processor. Pre-defined performance analysis tools locate the start address of the machine instruction corresponding to each function to be observed within the target program's binary code (or, for function return traces, instructions near the end address). At this precise binary location, a dynamic tracing mechanism is used to non-intrusively set the corresponding function tracepoint.

[0069] Non-intrusive setup means that the entire setup process does not permanently change the target program's binary code itself, does not introduce additional code instructions, and does not require restarting the target program. The set trace points are only activated when data collection is needed and are automatically removed after data collection is complete, restoring the code area to its original state.

[0070] This application ensures that the behavior and performance characteristics of the target program will not be permanently changed due to the observed behavior itself by setting temporary and recoverable function trace points, thereby guaranteeing the authenticity and reliability of the collected call relationships and execution counts.

[0071] In one possible implementation of this application embodiment, when determining multiple target functions included in the target function call chain as multiple observable functions, the following method can be used, but is not limited to: performing deduplication on multiple target functions to obtain multiple observable functions.

[0072] In the embodiments of this application, the purpose of deduplication is to remove all redundant copies from an original set containing potentially duplicate elements, ensuring that each element in the final set is unique. That is, the direct objects of deduplication are the multiple objective functions initially extracted by the static analysis module.

[0073] The reason for deduplication is that when deriving function call chains through static analysis, the same function may appear on multiple different call paths. For example, a general utility function may be called by multiple different modules or functions in the program. When traversing each target function call chain related to the pre-defined function to be analyzed and simply merging all functions on it, this general utility function will be added to the initial set multiple times, resulting in multiple identical function entities within the set. These duplicate entities not only fail to provide new information but also introduce noise and directly lead to a waste of resources in subsequent steps. Therefore, deduplication is necessary.

[0074] This application, through deduplication, firstly eliminates data redundancy, preventing the creation of multiple identical tracking points for the same function when creating non-intrusive function tracking points for each observed function. This saves system resources and reduces the performance overhead of dynamic tracing mechanisms. Secondly, it ensures that each function in the constructed function link graph corresponds to only one unique node, making the graph structure clearer and more accurate, and avoiding confusion in call relationships and increased graph complexity caused by duplicate nodes.

[0075] In one possible implementation of this application embodiment, after obtaining the target function link graph, the following method can also be used, but is not limited to: visualizing the target function link graph.

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

[0077] Embodiments of this application also provide an apparatus for constructing a function call chain. Figure 5 A schematic diagram of a function call chain construction device provided in this application is shown below. Figure 5 As shown, it includes: The first determining unit 51 is used to determine multiple function call chains in the target program by performing code analysis on the target program. The second determining unit 52 is used to determine the target function call chain in which each of the multiple preset functions to be analyzed is located from multiple function call chains, wherein each function call chain includes the call relationship between multiple first functions in the target program; The second determining unit 52 is also used to determine the multiple objective functions included in the objective function call chain as multiple observable functions; The first construction unit 53 is used to take multiple functions to be observed as first nodes, and create directed edges between multiple first nodes based on the calling relationship to obtain the first function link graph; Create unit 54 to create non-intrusive function tracking points for each of the multiple functions to be observed; Acquisition unit 55 is used to acquire the calling functions and the number of times each of the multiple observable functions during the execution of the target program is called, based on function tracing points; The second building unit 56 is used to create a link graph based on multiple observable functions, calling functions and the number of times they are called, to obtain a second function link graph; The fusion unit 57 is used to perform link graph fusion processing on the second function link graph as a subgraph of the first function link graph to obtain the target function link graph.

[0078] In one embodiment of this application, the first building unit 53 is specifically used for: The first target node and at least one first calling node corresponding to the first target node are determined based on the calling relationship, wherein the first target node is any one of a plurality of first nodes, and the first calling node is the first node that calls the first target node; Create directed edges from the first target node to at least one first calling node, and continue this process until directed edges are created for multiple first nodes to obtain the first function link graph.

[0079] In one embodiment of this application, the second building unit 56 is specifically used for: Create multiple directed edges pointing to their respective calling functions to obtain an initial link graph. Here, the calling function is the function that calls the multiple observing functions during the execution of the target program, and the number of times the multiple observing functions are called is the number of times each of the multiple observing functions is called by its respective calling function. The number of times each function is called is labeled onto the directed edges pointing to the corresponding calling functions of the multiple observed functions, thus obtaining the second function link graph.

[0080] In one embodiment of this application, the fusion unit 57 is specifically used for: The second function link graph is used as a subgraph of the first function link graph for link graph fusion processing to obtain the fused function link graph; The target function link graph is obtained by identifying the subgraph corresponding to the second function link graph in the fused function link graph using a preset visual algorithm.

[0081] In one embodiment of this application, such as Figure 6 As shown, the function call chain construction device further includes: an identification unit 58. The identification unit 58 is used for: Image recognition processing is performed on the objective function link graph to obtain the recognition results; In response to the identification result indicating the existence of unused paths, the unused paths are marked, and path redundancy prompts are generated based on the unused paths; In response to the identification result indicating the existence of hot call paths, the hot call paths are marked, and key path prompts are generated based on the hot call paths.

[0082] In one embodiment of this application, the identification unit 58 is specifically used for: The identified parts in the target function link graph are determined as the subgraph parts corresponding to the second function link graph, and the unidentified parts in the target function link graph are determined as the parent graph parts corresponding to the first function link graph. Call paths in the parent graph that are not covered by the subgraph are identified as uncalled paths. These call paths are determined by the directed edges in the target function link graph. The call path with the highest number of calls in the subgraph is identified as the hot call path.

[0083] In one embodiment of this application, the creation unit 54 is specifically used to: non-intrusively set corresponding function tracking points for multiple functions to be observed in the binary code of the target program through the dynamic tracing mechanism of the preset performance analysis tool, wherein the preset performance analysis tool is used to non-intrusively create tracking points at any position in the binary code.

[0084] In one embodiment of this application, the second determining unit 52 is specifically used for: Multiple objective functions are deduplicated to obtain multiple observation functions.

[0085] In one embodiment of this application, such as Figure 6 As shown, the device for constructing a function call chain also includes: Display unit 59 is used to visualize the objective function link diagram.

[0086] For a description of the features in the embodiment corresponding to the function call chain construction device, please refer to the relevant description in the embodiment corresponding to the function call chain construction method, which will not be repeated here.

[0087] 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-described embodiments of the method for constructing a function call chain.

[0088] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described embodiments of the function call chain construction method at runtime.

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

[0090] 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-described methods for constructing function call chains.

[0091] 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-described methods for constructing function call chains.

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

[0093] The foregoing has provided a detailed description of a method for constructing a function call chain and an electronic device provided in this application. 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 constructing a function call chain, characterized in that, include: By performing static code analysis on the target program, multiple function call chains in the target program are determined, and multiple preset function call chains to be analyzed are determined from the multiple function call chains. Each function call chain includes the call relationship between multiple functions in the target program. The multiple target functions included in the target function call chain are identified as multiple functions to be observed. The multiple functions to be observed are taken as first nodes. Directed edges are created between the multiple first nodes based on the call relationship to obtain a first function link graph. Non-intrusive function tracking points are created for each of the multiple functions to be observed, and the calling functions and the number of times each of the multiple functions to be observed are obtained during the execution of the target program based on the function tracking points. A link graph is created based on the multiple functions to be observed, the calling functions, and the number of times they are called, to obtain a second function link graph. The second function link graph is then used as a subgraph of the first function link graph for link graph fusion processing to obtain the target function link graph.

2. The method for constructing a function call chain according to claim 1, characterized in that, The step of taking the plurality of observed functions as first nodes and creating directed edges between the plurality of first nodes based on the calling relationship to obtain the first function link graph includes: Based on the calling relationship, a first target node and at least one first calling node corresponding to the first target node are determined, wherein the first target node is any one of the plurality of first nodes, and the first calling node is the first node that calls the first target node; Create directed edges from the first target node to at least one of the first calling nodes, until directed edge creation is performed on all of the multiple first nodes, to obtain the first function link graph.

3. The method for constructing a function call chain according to claim 1, characterized in that, The process of creating a link graph based on the multiple observed functions, the calling functions, and the number of times they are called, to obtain the second function link graph, includes: Create directed edges pointing to the multiple observed functions and their corresponding calling functions to obtain an initial link graph, wherein the calling function is the function that calls the multiple observed functions during the execution of the target program, and the number of times the multiple observed functions are called by their respective calling functions. The number of times each function is called is labeled onto the directed edges pointing from the multiple observed functions to their respective calling functions, thus obtaining the second function link graph.

4. The method for constructing a function call chain according to claim 1, characterized in that, The step of performing link graph fusion processing on the second function link graph as a subgraph of the first function link graph to obtain the target function link graph includes: The second function link graph is used as a subgraph of the first function link graph for link graph fusion processing to obtain a fused function link graph; The target function link graph is obtained by identifying the subgraph portion corresponding to the second function link graph in the fused function link graph using a preset visual algorithm.

5. The method for constructing a function call chain according to claim 1, characterized in that, After performing link graph fusion processing on the second function link graph as a subgraph of the first function link graph to obtain the target function link graph, the method further includes: The objective function link graph is subjected to image recognition processing to obtain the recognition result; In response to the identification result indicating the existence of an uncalled path, the uncalled path is marked, and path redundancy prompt information is generated based on the uncalled path; In response to the identification result indicating the existence of a hotspot call path, the hotspot call path is marked, and key path prompt information is generated based on the hotspot call path.

6. The method for constructing a function call chain according to claim 5, characterized in that, The image recognition processing of the objective function link graph to obtain the recognition result includes: The identified portion of the target function link graph is determined as the subgraph portion corresponding to the second function link graph, and the unidentified portion of the target function link graph is determined as the parent graph portion corresponding to the first function link graph. The call paths in the mother graph that are not covered by the subgraph are identified as the uncalled call paths, wherein the call paths are determined by the directed edges in the target function link graph; The call path with the highest number of calls in the subgraph portion is identified as the hot call path.

7. The method for constructing a function call chain according to claim 1, characterized in that, The process of creating non-intrusive function tracking points corresponding to each of the multiple functions to be observed includes: Through the dynamic tracing mechanism of the preset performance analysis tool, the corresponding function tracing points are set non-intrusively for each of the multiple functions to be observed in the binary code of the target program. The preset performance analysis tool is used to create tracing points non-intrusively at any position in the binary code.

8. The method for constructing a function call chain according to claim 1, characterized in that, The step of determining the multiple target functions included in the target function call chain as multiple observable functions includes: The multiple objective functions are deduplicated to obtain the multiple observation functions.

9. The method for constructing a function call chain according to claim 1, characterized in that, After performing link graph fusion processing on the second function link graph as a subgraph of the first function link graph to obtain the target function link graph, the method further includes: The objective function link graph is then visualized.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the method for constructing a function call chain as described in any one of claims 1 to 9 when executing the computer program.

Images