Code instrumentation processing method and device, electronic equipment and readable storage medium

Abstract

The invention provides a code instrumentation processing method and device, electronic equipment and a readable storage medium, and the method comprises the steps: responding to the completion of construction of an abstract syntax tree corresponding to a to-be-instrumented source code, traversing the abstract syntax tree, and determining at least one candidate instrumentation point in the abstract syntax tree; calling a user script, screening out at least one target instrumentation point from the candidate instrumentation points, and determining a probe code for each target instrumentation point; inserting a probe code into each target instrumentation point to obtain an instrumentation source code, storing the instrumentation source code in a temporary storage position, and mapping a file reading path of the instrumentation source code to the temporary storage position through a virtual file system; and in response to a source file reading instruction, reading the instrumentation source code stored in the temporary storage position based on the file reading path to obtain a compiled target code. Thus, under the condition that the source code is not polluted, the compiled target code is obtained, the flexibility of instrumentation processing can be improved, and the complexity of file management can be reduced.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to processing methods, apparatus, electronic devices, and readable storage media for code instrumentation. Background Technology

[0002] Software instrumentation is a technique that inserts additional code (i.e., "stubs" or "probes") along the critical path of program execution to collect runtime information or alter program behavior. This information is crucial for software debugging, performance analysis, coverage testing, dynamic program analysis, security monitoring, and other scenarios requiring in-depth understanding of the program's internal state and execution flow.

[0003] Instrumentation methods can include manual instrumentation and automatic instrumentation. Manual instrumentation involves developers adding print statements, logging calls, or specific monitoring functions directly to the source code. This method is highly flexible but inefficient, prone to errors, and intrusive to the source code, making it difficult to apply systematically in large-scale projects.

[0004] In related technologies, automatic instrumentation generates new source files containing stub code after instrumentation, or directly modifies the original source files. This pollutes the user's source code repository, causing inconvenience for version control, code review, and collaboration. Furthermore, the instrumentation filtering logic is often hard-coded within plugins or controlled through complex configuration files or command-line parameters. This approach lacks sufficient flexibility, making it difficult to adapt to dynamically changing filtering needs in projects or to express complex filtering conditions. Summary of the Invention

[0005] In view of this, the purpose of this disclosure is to provide a method, apparatus, electronic device, and readable storage medium for code instrumentation. By calling an external user script to filter candidate instrumentation points, at least one target instrumentation point that meets the user's instrumentation detection requirements is dynamically obtained without modifying the source code, and the instrumentation source code is generated and stored in a temporary storage location. At the same time, the file reading path of the instrumentation source code is mapped to the temporary storage location through a virtual file system. After the compilation process is triggered, the instrumentation source code stored in the temporary storage location is read and compiled, so that the compilation process no longer reads the source code. The compiled target code is obtained without polluting the source code, which can improve the flexibility of instrumentation processing and reduce the complexity of file management.

[0006] In a first aspect, embodiments of this disclosure provide a code instrumentation method applied to a compiler; the method includes: In response to the completion of the abstract syntax tree corresponding to the source code to be instrumented, the abstract syntax tree is traversed to determine at least one candidate instrumentation point in the abstract syntax tree. Invoke the user script to filter at least one target instrumentation point from the candidate instrumentation points, and determine the probe code for each target instrumentation point; Probe code is inserted at each target instrumentation point to obtain instrumentation source code, which is then stored in a temporary storage location. A virtual file system is used to map the file read path of the instrumentation source code to this temporary storage location; wherein, the temporary storage location is different from the storage location of the source code. In response to the source file read instruction, the instrumented source code stored in the temporary storage location is read based on the file read path to obtain the compiled target code.

[0007] Secondly, this disclosure also provides a code instrumentation processing apparatus applied to a compiler; the processing apparatus includes: The candidate instrumentation point determination module is used to traverse the abstract syntax tree and determine at least one candidate instrumentation point in the abstract syntax tree in response to the completion of the construction of the abstract syntax tree corresponding to the source code to be instrumented. The target instrumentation point filtering module is used to call a user script to filter at least one target instrumentation point from the candidate instrumentation points and determine the probe code for each target instrumentation point. An instrumentation source code storage module is used to insert probe code at each target instrumentation point to obtain instrumentation source code, store the instrumentation source code in a temporary storage location, and map the file read path of the instrumentation source code to the temporary storage location through a virtual file system; wherein, the temporary storage location is different from the storage location of the source code; The code compilation module is used to respond to the source file read instruction, read the instrumented source code stored in the temporary storage location based on the file read path, and obtain the compiled target code.

[0008] Thirdly, embodiments of this disclosure also provide an electronic device, including: a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the code instrumentation processing method as described in the first aspect.

[0009] Fourthly, embodiments of this disclosure also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the code instrumentation processing method as described in the first aspect.

[0010] The code instrumentation processing method, apparatus, electronic device, and readable storage medium provided in this disclosure, in response to the completion of the construction of the abstract syntax tree corresponding to the source code to be instrumented, traverses the abstract syntax tree to determine at least one candidate instrumentation point in the abstract syntax tree; calls a user script to filter at least one target instrumentation point from the candidate instrumentation points, and determines probe code for each target instrumentation point; inserts probe code at each target instrumentation point to obtain instrumented source code, stores the instrumented source code in a temporary storage location, and maps the file read path of the instrumented source code to the temporary storage location through a virtual file system; wherein the temporary storage location is different from the storage location of the source code; in response to a source file read instruction, reads the instrumented source code stored in the temporary storage location based on the file read path to obtain the compiled target code. In this way, by calling an external user script to filter candidate instrumentation points, at least one target instrumentation point that meets the user's instrumentation detection requirements can be dynamically obtained without modifying the source code, and the instrumentation source code can be generated and stored in a temporary storage location. At the same time, the file reading path of the instrumentation source code is mapped to the temporary storage location through a virtual file system. After the compilation process is triggered, the instrumentation source code stored in the temporary storage location is read and compiled, so that the compilation process no longer reads the source code. The compiled target code is obtained without polluting the source code, which can improve the flexibility of instrumentation processing and reduce the complexity of file management.

[0011] To make the above-mentioned objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0012] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of this disclosure and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 A flowchart illustrating a code instrumentation method provided in an embodiment of this disclosure; Figure 2 This is one of the structural schematic diagrams of a code instrumentation processing device provided in an embodiment of the present disclosure; Figure 3 A second schematic diagram of a code instrumentation processing device provided in an embodiment of this disclosure; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. The components of the embodiments of this disclosure described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this disclosure provided in the accompanying drawings is not intended to limit the scope of the claimed disclosure, but merely represents selected embodiments of this disclosure. Based on the embodiments of this disclosure, every other embodiment obtained by those skilled in the art without inventive effort falls within the scope of protection of this disclosure.

[0015] First, the technical background of this disclosure will be introduced: Software instrumentation is a technique that inserts additional code (i.e., "stubs" or "probes") along the critical path of program execution to collect runtime information or alter program behavior. This information is crucial for software debugging, performance analysis, coverage testing, dynamic program analysis, security monitoring, and other scenarios requiring in-depth understanding of the program's internal state and execution flow.

[0016] Currently, the main technical approaches to achieving software instrumentation include: Manual instrumentation: Developers manually add print statements, log calls, or specific monitoring functions directly into the source code. This method is highly flexible but inefficient, prone to introducing errors, and intrusive to the source code, making it difficult to apply systematically in large-scale projects.

[0017] Binary instrumentation: Modifying or inserting instructions at the level of a compiled binary executable or library. Representative tools include Pin, DynamoRIO, and Valgrind. This type of technique does not require source code, but it is usually closely related to specific CPU architectures and operating systems, and understanding and modifying low-level instructions is relatively complex, potentially leading to performance overhead and compatibility issues.

[0018] Source-to-Source Transformation: This involves parsing the source code, modifying it at the Abstract Syntax Tree (AST) level or the text level, and then generating new source code with stubs. This method can leverage the structural information of high-level languages, but it typically requires complex parsing and code generation tools and directly modifies the original codebase, potentially causing problems for version control and code maintenance.

[0019] Compiler-based instrumentation utilizes extension points or interfaces provided by the compiler during the compilation process for instrumentation. Examples include GCC's `-finstrument-functions` option or its plugin mechanism, and the rich interfaces provided by the LLVM / Clang ecosystem. The compiler possesses complete syntactic and semantic information (such as through the Abstract Syntax Tree) at compile time, enabling precise and efficient instrumentation.

[0020] In the field of compiler-assisted instrumentation, Clang, as the C / C++ / Objective-C frontend of the LLVM project, has become an ideal platform for implementing advanced code analysis and transformation tasks due to its modular design, clear library interfaces (such as LibTooling and Libclang), and powerful Clang plugin mechanism. Clang plugins allow developers to intervene at specific stages of the compilation process (such as after the AST is built), traversing and modifying the AST to achieve custom code analysis, inspection, or transformation, including automatic instrumentation.

[0021] In the field of software automatic instrumentation, especially compiler-based instrumentation, there are various solutions and tools. However, they still have certain limitations in achieving non-intrusiveness to the source code, a seamless user experience, and providing a flexible and efficient instrumentation filtering mechanism.

[0022] (1) GCC-based instrumentation function: GCC provides compiler options such as `-finstrument-functions`, which allow user-defined callback functions (such as `__cyg_profile_func_enter` and `__cyg_profile_func_exit`) to be automatically inserted at function entry and exit points. This method enables basic function-level instrumentation, but it has the following limitations: Intrusiveness to source code: Although instrumentation is done by the compiler, viewing or debugging the instrumented equivalent source code logic is usually not directly visible or requires additional disassembly and comprehension. It does not directly address the "cleanliness" of the original source code file.

[0023] Limited filtering mechanisms: GCC's native instrumentation is usually global, or requires complex code modifications (e.g., checking function names inside callback functions) or linking techniques for filtering. It lacks the ability to perform flexible and dynamic filtering at compile time based on rich context information. Users find it difficult to easily adjust the filtering strategy according to the specific project requirements.

[0024] User experience: Developers still need to be aware of the instrumentation process and may need to handle additional compilation and linking dependencies introduced by instrumentation.

[0025] (2) Other source code-level instrumentation tools: Some standalone source-to-source conversion tools (such as the instrumentation features included with some static analyzers) also attempt to perform automatic instrumentation. They typically require a complete parsing and code generation process.

[0026] Source code management issues: Similar to the above-mentioned tools that directly modify source code based on Clang plugins, these tools also face the problem of how to manage the source code after instrumentation, making it difficult to achieve complete non-intrusion on the user's source code library.

[0027] Integration and compilation process: These tools are usually run as a preprocessing step, which may make integration with the project's original compilation process (especially complex build systems based on CMake, Makefile, etc.) inconvenient.

[0028] (3) Limitations of dynamic binary instrumentation tools: Tools like Pin and DynamoRIO perform instrumentation at the binary level, naturally avoiding source code pollution. However, they also have inherent drawbacks: Information loss: At the binary level, a lot of high-level semantic information at the source code level (such as variable names, type information, macro definitions, etc.) has been lost, which limits the ability to perform fine-grained instrumentation and filtering based on this information.

[0029] Platform dependency and performance overhead: Binary instrumentation is often closely related to specific CPU architectures and operating systems, and dynamically interpreting and modifying instructions can introduce significant runtime performance overhead.

[0030] In summary, while existing automatic instrumentation techniques, especially those using Clang at the compiler level, have made progress in terms of instrumentation accuracy and automation, they still have shortcomings in one or more of the following aspects: Non-intrusive source code: It is difficult to perform instrumentation without modifying the original code files on the user's disk.

[0031] Seamless user experience: Users often need to be aware of the instrumentation process and deal with the resulting changes in source code versions or build processes.

[0032] The flexibility and dynamism of stub filtering: There is a lack of a simple, flexible and powerful mechanism that allows users to dynamically adjust stub filtering strategies based on project needs and runtime context to effectively reduce noise and data volume.

[0033] (4) Existing instrumentation schemes based on LLVM / Clang: As the frontend of LLVM, Clang's powerful AST analysis capabilities and plugin mechanism make it an ideal choice for implementing complex instrumentation logic. Currently, there are some Clang-based instrumentation practices and research: AST modification using LibTooling or Clang plugins: Many tools and research projects utilize LibTooling to analyze code independently, or use Clang plugins to traverse the AST at compile time and insert stub code. These methods enable precise source-level instrumentation. However, they typically face the following challenges: Source code pollution: Most of these tools generate new source files containing stub code after instrumentation, or directly modify the original files. This pollutes the user's source code repository, causing inconvenience for version control, code review, and collaboration. Even if generated to a new location, it increases the complexity of file management.

[0034] The static nature or complexity of stub filtering: Stub filtering logic is often hard-coded within the plugin or controlled through complex configuration files or command-line arguments. This approach lacks sufficient flexibility, making it difficult to adapt to dynamically changing filtering needs in a project, or to express complex filtering conditions (e.g., based on function call relationships, code complexity, specific code patterns, etc.). Modifying the filtering strategy usually requires recompiling the plugin or modifying complex configurations.

[0035] Limited Applications of VFS: Although Clang supports VFS, existing instrumentation tools rarely combine it with AST modifications to achieve instrumentation effects that are transparent to the user and do not modify the original disk files. In most cases, VFS is mainly used to handle header file redirection or special file mappings in the build system, rather than dynamically generating and "overwriting" the content of the instrumented source files.

[0036] Based on this, the present disclosure provides a code instrumentation method to obtain compiled target code without polluting the source code, which can improve the flexibility of instrumentation and reduce the complexity of file management.

[0037] Please see Figure 1 , Figure 1 This is a flowchart illustrating a code instrumentation method provided in an embodiment of this disclosure. Figure 1 As shown in the embodiments of this disclosure, the code instrumentation processing method includes: S101. In response to the completion of the construction of the abstract syntax tree corresponding to the source code to be instrumented, traverse the abstract syntax tree and determine at least one candidate instrumentation point in the abstract syntax tree.

[0038] S102. Call the user script to select at least one target instrumentation point from the candidate instrumentation points, and determine the probe code for each target instrumentation point.

[0039] S103. Insert probe code at each target instrumentation point to obtain instrumentation source code, store the instrumentation source code in a temporary storage location, and map the file read path of the instrumentation source code to the temporary storage location through a virtual file system; wherein, the temporary storage location is different from the storage location of the source code.

[0040] S104. In response to the source file read instruction, the instrumented source code stored in the temporary storage location is read based on the file read path to obtain the compiled target code.

[0041] The code instrumentation method provided in this disclosure filters candidate instrumentation points by calling an external user script. Without modifying the source code, it dynamically obtains at least one target instrumentation point that meets the user's instrumentation detection requirements and generates instrumentation source code, which is stored in a temporary storage location. Simultaneously, a virtual file system maps the file reading path of the instrumentation source code to the temporary storage location. After the compilation process is triggered, the instrumentation source code stored in the temporary storage location is read and compiled, so that the compilation process no longer reads the source code. The compiled target code is obtained without polluting the source code, which can improve the flexibility of instrumentation processing and reduce the complexity of file management.

[0042] The exemplary steps of the embodiments of this disclosure are described below: S101. In response to the completion of the construction of the abstract syntax tree corresponding to the source code to be instrumented, traverse the abstract syntax tree and determine at least one candidate instrumentation point in the abstract syntax tree.

[0043] In the embodiments disclosed herein, instrumentation is a technique that strategically inserts additional code (probes) into a program to monitor its behavior, collect data, or perform analysis and debugging during program runtime, so that developers can understand the current code's runtime parameters during the code compilation process and thus debug the code segment.

[0044] Instrumentation methods can include manual instrumentation and automatic instrumentation. Manual instrumentation involves developers adding print statements, logging calls, or specific monitoring functions directly to the source code. This method is highly flexible but inefficient, prone to errors, and intrusive to the source code, making it difficult to apply systematically in large-scale projects.

[0045] In an alternative implementation, the compiler in this application embodiment can be the Clang compiler. Clang, as the C / C++ / Objective-C frontend of the LLVM project, has become an ideal platform for implementing advanced code analysis and transformation tasks due to its modular design, clear library interfaces (such as LibTooling and Libclang), and powerful Clang plugin mechanism. Clang plugins allow developers to intervene at specific stages of the compilation process (such as after the AST is built), traversing and modifying the AST to achieve custom code analysis, inspection, or transformation, including automatic instrumentation.

[0046] However, Clang instrumentation generates new source files containing stub code after instrumentation, or directly modifies the original files. This pollutes the user's source code repository, causing inconvenience for version control, code review, and collaboration. Furthermore, stub filtering logic is often hard-coded within plugins or controlled through complex configuration files or command-line parameters. This approach lacks sufficient flexibility, making it difficult to adapt to dynamically changing filtering needs in projects or to express complex filtering conditions.

[0047] Based on this, the present disclosure provides a method for processing code instrumentation. By calling a user script to filter candidate instrumentation points, at least one target instrumentation point is obtained and instrumentation source code is generated. At the same time, the subsequent file reading paths of the compilation process are mapped to the location of the instrumentation source code through a virtual file system. Without polluting the source code, target code that meets the user's instrumentation requirements can be obtained, which can improve the flexibility of instrumentation processing and reduce the complexity of file management.

[0048] Here, once the user starts the compilation process, the Clang compiler is loaded, which allows the subsequent instrumentation process to start quickly.

[0049] In one alternative implementation, the Clang compiler intervenes after the abstract syntax tree (AST) is built during the compilation process of C / C++ and other source code, but before code generation. That is, after determining that the abstract syntax tree corresponding to the source code to be instrumented has been built, the Clang compiler begins to traverse the various positions of the abstract syntax tree, and then determines at least one candidate instrumentation point that can be instrumented.

[0050] In this way, operating at the AST level allows direct access to and modification of the structured representation of the code, ensuring the accuracy of instrumentation. Furthermore, the Clang compiler itself supports multiple language front-ends, and its AST structure possesses a degree of versatility. AST-based plugins are easier to extend to support new languages ​​or language features that the Clang compiler may support in the future. Additionally, AST nodes contain rich semantic information (such as type information, scope, and symbol information), which is crucial for implementing complex instrumentation logic and subsequent filtering decisions, improving the accuracy of determining the target instrumentation location.

[0051] Specifically, the step "in response to the completion of the construction of the abstract syntax tree corresponding to the source code to be instrumented, traversing the abstract syntax tree and determining at least one candidate instrumentation point in the abstract syntax tree" includes: a1: In response to the completion of the abstract syntax tree corresponding to the source code to be instrumented, automatically traverse the abstract syntax tree and identify at least one target code structure from the abstract syntax tree.

[0052] a2: Determine the location of at least one target code structure as at least one candidate instrumentation point in the abstract syntax tree.

[0053] Here, the Abstract Syntax Tree (AST) is a tree-like data structure that represents the structure of source code. An AST consists of nodes, child nodes, and hierarchical relationships. Specifically, each node represents a syntactic element in the source code, such as an expression, statement, or operator. Child nodes identify smaller components; for example, an arithmetic expression might have two byte nodes, each representing one of the two addends. The hierarchy of the AST represents the structure of the code elements; for example, a parent node might be a complex expression, and its child nodes might be the basic operators and operands that constitute that expression.

[0054] Here, the abstract syntax tree provided in this application embodiment can be a Clang abstract syntax tree corresponding to the Clang compiler.

[0055] In one alternative implementation, after determining that the abstract syntax tree corresponding to the source code to be instrumented has been constructed, the Clang compiler automatically traverses the abstract syntax tree to determine the target code structure in the abstract syntax tree, and then determines at least one candidate instrumentation point included in the abstract syntax tree.

[0056] Here, the Clang compiler can use RecursiveASTVisitor to traverse the abstract syntax tree, gaining access to all relevant code structures within a compilation unit (for example, all function definitions). This ensures that all potential instrumentation points are considered, avoiding any omissions.

[0057] Here, the target code structure includes at least one of the following: The abstract syntax tree contains function definitions, function calls, and basic blocks.

[0058] For example, function entry points, exit points, or specific statements in the sequential abstract syntax tree can be identified as candidate instrumentation points.

[0059] In this way, operating at the abstract syntax tree level allows direct access to and modification of the structured representation of the code, ensuring the accuracy of instrumentation.

[0060] Furthermore, after obtaining at least one candidate instrumentation point by traversing the syntax abstraction tree, a user script can be called to filter at least one target instrumentation point from the candidate instrumentation points based on the decision function contained in the user script. This allows for dynamic and flexible filtering of target instrumentation points that meet the user's instrumentation detection requirements, better meeting the user's debugging needs and thus improving the user's debugging experience.

[0061] S102. Call the user script to select at least one target instrumentation point from the candidate instrumentation points, and determine the probe code for each target instrumentation point.

[0062] In one alternative implementation, a script engine is integrated into the Clang compiler, which can call user scripts to filter at least one candidate instrumentation point.

[0063] For example, a specific implementation of integrating a script engine into the Clang compiler could be an embedded interface of CPython for Python, or QuickJS, etc.

[0064] In one optional implementation, the user script is a script compiled based on the user's compilation requirements. Specifically, the user script is a script compiled by the user to meet the user's monitoring requirements and contains a specific decision function. Then, based on the specific decision function, candidate instrumentation points are filtered, and for each unfiltered target instrumentation point, the corresponding probe code is determined.

[0065] Specifically, the step "invoking a user script to filter at least one target instrumentation point from the candidate instrumentation points and determining the probe code for each target instrumentation point" includes: b1: For each candidate instrumentation point, determine the context information of the candidate instrumentation point, and based on the context information and the decision function in the user script, determine whether to instrument the candidate instrumentation point.

[0066] b2: If it is determined that the candidate insertion point will be inserted, the candidate insertion point will be designated as the target insertion point, and the probe code for the target insertion point will be determined based on the context information and the insertion detection requirement information.

[0067] In one alternative implementation, for each candidate insertion point, when determining whether a candidate insertion point is a target insertion point, it is necessary to extract the context information of the current candidate insertion point.

[0068] In one optional implementation, the context information includes at least one of the following: Information associated with the candidate instrumentation point includes the function name, file name, parameter list, overall function complexity, and annotations.

[0069] For example, taking a candidate instrumentation point as a function definition or call point, the context information of the candidate instrumentation point may include the function name, the file name to which it belongs, the parameter list, the return type, the approximate complexity of the function body, and specific annotations in the source code.

[0070] In one alternative implementation, after determining the context information of the candidate instrumentation point, and after determining to call the user script, the context information of the candidate instrumentation point is passed to the decision function in the user script to determine whether to filter the current candidate instrumentation point.

[0071] Specifically, the filtering logic in the user script can include decision functions such as ignoring functions in a specific namespace or overly simple functions.

[0072] For example, there are candidate instrumentation point A and candidate instrumentation point B. The function body corresponding to candidate instrumentation point A has low complexity, while the function body corresponding to candidate instrumentation point B has high complexity. The current user script's filtering condition for candidate instrumentation points is to filter out functions that are too simple. In this case, candidate instrumentation point A will be filtered out, while candidate instrumentation point B will be retained and determined as the target instrumentation point.

[0073] In one alternative implementation, the user script's judgment result for the candidate instrumentation point can return a boolean value to indicate whether to instrument the current candidate instrumentation point to obtain the filtered target instrumentation point.

[0074] Here, the boolean value is either "True" or "False". If the boolean value returned by the user script is "True", it is determined that the current candidate instrumentation point can be instrumented, and the current candidate instrumentation point is the target instrumentation point. If the boolean value returned by the user script is "False", it is determined that the current candidate instrumentation point will not be instrumented, and the current candidate instrumentation point will be filtered out.

[0075] In one alternative implementation, after identifying at least one target instrumentation point, probe code for that target instrumentation point can be determined using a user script in conjunction with context information. For example, this can involve dynamically generating or selecting a specific probe code template, configuring probe parameters, or specifying the specific method and content of probe insertion based on context information. This allows the inserted probes to be highly adaptable to different code scenarios and monitoring needs, thereby improving the flexibility and accuracy of probe code generation.

[0076] Specifically, the step "determining the probe code for the target stake point based on the context information and stake detection requirement information" includes: c1: Based on the context information, determine the probe code template for the target insertion point.

[0077] c2: Based on the stake detection requirement information and the probe code template, obtain the probe code for the target stake point.

[0078] In one alternative implementation, for the case of determining the probe code template based on context information, the probe code template can be determined from a predefined probe code template based on the context information, or the probe code template can be directly constructed based on the context information to meet the different probe code writing needs of users, which helps to improve the flexibility and accuracy of probe code generation.

[0079] Specifically, the step "determine the probe code template for the target insertion point based on the context information" includes: d1: Based on the context information, select a probe code template for the target instrumentation point from a set of pre-set candidate probe code templates; or, d2: Based on the context information, construct a probe code template for the target insertion point.

[0080] In one alternative implementation, multiple function structures can be determined based on the code structure in the source code determined during the historical compilation process, and corresponding candidate probe code templates can be determined based on the user's historical instrumentation and probing requirements. The user script can then directly filter out the corresponding probe code template from the pre-set candidate probe templates based on the currently obtained context information.

[0081] For example, the candidate probe code template may include a template for recording function entry / exit, or a template for recording specific parameter values. If it is determined from the context information of the target instrumentation point that the function at the current target instrumentation point can generate specific parameters, and it is necessary to record the entry and exit status of the current function, then the template for recording function entry / exit and the template for recording specific parameter values ​​in the pre-generated candidate probe code template can be directly used as the probe code template. This can reduce the generation time of the probe template and thus improve the efficiency of code compilation.

[0082] In another alternative implementation, if it is determined, based on the context information of the current target instrumentation point and the instrumentation detection requirements, that there is no corresponding template among the currently pre-generated candidate probe templates, the user script can also generate the corresponding probe code template itself, or modify the pre-generated candidate probe template to obtain the corresponding probe code template. This can satisfy all the user's instrumentation requirements, thereby improving the flexibility and accuracy of code compilation.

[0083] Furthermore, after determining the probe code template for the target insertion point, the insertion detection requirement information can be passed to the user script. The user script generates probe code for the target insertion point based on the insertion detection requirement information and the probe code template. In this way, probe code that meets the insertion detection requirements can be generated for each target insertion point, thereby improving the accuracy of the insertion operation.

[0084] Specifically, the step "based on the stake detection requirement information and the probe code template, obtain the probe code for the target stake point" includes: e1: Based on the stake detection requirement information and the probe code template, generate probe code for the target stake point; and / or, e2: Modify the probe code template based on the stake detection requirement information to generate probe code for the target stake point.

[0085] In one optional implementation, the instrumentation detection requirement information provided to the probe code template may be the variable name to be recorded, the log level, a specific identifier, etc. If the current probe code template can meet the above instrumentation detection requirements, probe code for the target instrumentation point can be generated directly based on the instrumentation detection requirement information and the probe code template.

[0086] In another alternative implementation, if it is determined that there is a difference between the probe code template and the current stake detection requirements, the probe code template can be modified according to the stake detection requirements to meet the current stake detection requirements, thereby generating probe code for the target stake point.

[0087] For example, the current probe code template is a template for recording a specific parameter value A. Although the current stake probing requirement is also to record a specific parameter value, it is necessary to record a specific parameter value B. Therefore, the probe code template can be modified according to the stake probing requirement information to record a specific parameter value A, and then probe code for the target stake point can be generated.

[0088] In this way, compared to simple configuration files (such as JSON, XML, or regular expression-based lists), executable scripts allow users to implement arbitrarily complex decision logic. Users can write conditional statements, loops, call external libraries (if the script engine supports them), combine multiple conditions, etc., to precisely match their filtering needs, and dynamically select or construct the most suitable probe code based on detailed context, improving the accuracy and flexibility of probe code generation.

[0089] In one alternative implementation, if the user changes the location of the instrumentation point or the instrumentation detection requirements, the decision function in the user script can be directly modified. Without changing the overall architecture of the Clang compiler, the target instrumentation point can be updated quickly, thereby quickly determining the target instrumentation point and improving code compilation efficiency.

[0090] Specifically, the processing method further includes: f1: In response to adjustments in user compilation requirements, determine the updated user script, and select at least one update instrumentation point from the candidate instrumentation points based on the updated user script.

[0091] In one alternative implementation, if the user's compilation requirements, instrumentation detection requirements, or filtering conditions for instrumentation points change, the user script can be directly adjusted to determine the updated user script. Then, after the Clang compiler calls the user script, it determines the updated instrumentation point from the candidate instrumentation points based on the updated user script, completes the update process, and flexibly and dynamically selects the corresponding target instrumentation point according to the user's needs.

[0092] In this way, since both the instrumentation filtering logic and probe customization logic reside in external scripts, users can modify the script content at any time to adjust the filtering strategy and probe behavior without recompiling the Clang plugin itself. This greatly improves the flexibility, accuracy, and ease of use of the instrumentation mechanism, enabling users to quickly iterate and optimize the instrumentation scope and probe functionality, effectively reducing noisy data and unnecessary performance overhead, and obtaining more targeted runtime information. At the same time, it maintains the stability of the Clang plugin's core functionality, delegating the volatile filtering and probe customization requirements to external user scripts, which aligns with good software design principles and enhances the system's maintainability and scalability.

[0093] Furthermore, after identifying at least one target instrumentation point in the abstract syntax tree and the probe code for each instrumentation point, probe code is inserted at each target instrumentation point to obtain the instrumentation source code, which is then stored in a temporary storage location.

[0094] S103. Insert probe code at each target instrumentation point to obtain instrumentation source code, store the instrumentation source code in a temporary storage location, and map the file read path of the instrumentation source code to the temporary storage location through a virtual file system; wherein, the temporary storage location is different from the storage location of the source code.

[0095] Here, the temporary storage location is different from the storage location of the source code. That is, after obtaining the instrumented source code, the original source code file on the disk is not directly overwritten. Instead, the instrumented source code is directly stored in the temporary storage location. In this way, the original source code can be kept as is, avoiding problems such as version control chaos and code merging difficulties caused by instrumentation.

[0096] Specifically, the step "store the instrumentation source code in a temporary storage location" includes: g1: Store the instrumentation source code in a memory buffer; or... g2: Write the instrumented source code into a temporary file managed by the compilation system.

[0097] In one alternative implementation, after obtaining the instrumentation source code, the instrumentation source code can be stored in a memory buffer or written to a temporary file managed by the compilation system. This can avoid polluting the source code and thus preventing problems such as version control chaos and code merging difficulties caused by instrumentation.

[0098] In one alternative implementation, to ensure that users can access the temporary storage location of the currently stored instrumented source code without modifying the commands for the specified source files in the build script during subsequent compilation processes, the access path of the subsequent compilation system can be mapped to the temporary storage location through the mapping function of the virtual file system, rather than accessing the source code location, thus ensuring that the source code is not contaminated.

[0099] Furthermore, memory buffering avoids disk I / O overhead and improves compilation speed. Even when using temporary files, their management is controlled by the compilation system, making it safer and more controllable than directly modifying user files.

[0100] Specifically, the step "mapping the file read path of the instrumentation source code to the temporary storage location through a virtual file system" includes: h1: Virtual files and virtual directory structures are defined by preset type files in the virtual file system, and the file reading path of the instrumented source code is mapped to the temporary storage location.

[0101] Here, the Virtual File System (VFS) is an abstraction layer in the operating system kernel. It provides a unified file system interface for user-space programs while allowing different types of concrete file systems to coexist. When an application makes file-related system calls, the VFS first processes these calls, converting pathnames into corresponding dentry and inode names, and then finding the corresponding location based on the path. Specifically, it can use a YAML file to describe the virtual file and directory structure, redirecting access to specific paths to other real files or content in memory.

[0102] In this embodiment, a virtual file system is used to describe a virtual file and directory structure through a YAML file. This redirects access to the code compilation process to instrumented source code in a temporary storage location. When accessing files through the virtual file system, the instrumented version is automatically retrieved. The entire process is transparent to the user. Users do not need to modify commands specifying source files in the build script, nor do they need to be aware of the physical existence of the instrumented code, thus enhancing the user's seamless operation.

[0103] Furthermore, if it is necessary to read source files during the compilation process, the instrumented source code will be read through the file reading path provided by the virtual file system, thereby obtaining the compiled target code.

[0104] S104. In response to the source file read instruction, the instrumented source code stored in the temporary storage location is read based on the file read path to obtain the compiled target code.

[0105] In this way, when subsequent modules of the compiler (such as the lexical analyzer, preprocessor, and code generator) access files through the VFS, they will automatically read the instrumented source code stored in the temporary storage location containing the instrumented source code. The entire process is transparent to the user. Users do not need to modify the commands specifying source files in the build script, nor do they need to be aware of the physical existence of the instrumented code, thus improving the user's compilation experience.

[0106] The following specific example illustrates the code instrumentation process in this embodiment. Specifically, when the user starts compilation, the Clang compiler is loaded. The Clang compiler first prepares the virtual file system environment and configures the script engine. During the abstract syntax tree traversal phase, for each potential candidate instrumentation point, the Clang compiler calls the user script to make a decision. The script not only decides whether to instrument (filter) but also provides customized probe information or instructions. If the script indicates that instrumentation is needed and at least one target instrumentation point is identified, the Clang compiler generates and inserts the corresponding instrumentation code at each target instrumentation point according to the instructions of the user script, and provides the modified instrumentation source code to the subsequent compilation process through the virtual file system mechanism. Finally, the compiler generates target code based on these instrumentation source codes containing probe code.

[0107] The code instrumentation processing method provided in this disclosure, in response to the completion of the construction of the abstract syntax tree corresponding to the source code to be instrumented, traverses the abstract syntax tree to determine at least one candidate instrumentation point in the abstract syntax tree; calls a user script to filter at least one target instrumentation point from the candidate instrumentation points, and determines probe code for each target instrumentation point; inserts probe code at each target instrumentation point to obtain instrumented source code, stores the instrumented source code in a temporary storage location, and maps the file read path of the instrumented source code to the temporary storage location through a virtual file system; wherein, the temporary storage location is different from the storage location of the source code; in response to a source file read instruction, reads the instrumented source code stored in the temporary storage location based on the file read path to obtain the compiled target code. In this way, by calling an external user script to filter candidate instrumentation points, at least one target instrumentation point that meets the user's instrumentation detection requirements can be dynamically obtained without modifying the source code, and the instrumentation source code can be generated and stored in a temporary storage location. At the same time, the file reading path of the instrumentation source code is mapped to the temporary storage location through a virtual file system. After the compilation process is triggered, the instrumentation source code stored in the temporary storage location is read and compiled, so that the compilation process no longer reads the source code. The compiled target code is obtained without polluting the source code, which can improve the flexibility of instrumentation processing and reduce the complexity of file management.

[0108] Based on the same inventive concept, this disclosure also provides a code instrumentation processing device corresponding to the code instrumentation processing method. Since the principle of the device in this disclosure for solving the problem is similar to the code instrumentation processing method described above in this disclosure, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0109] Please see Figure 2 , Figure 3 , Figure 2 This is one of the structural schematic diagrams of a code instrumentation processing device provided in an embodiment of this disclosure. Figure 3 This is a second schematic diagram of a code instrumentation processing device provided in an embodiment of this disclosure. Figure 2 As shown, the processing device 200 includes: The candidate instrumentation point determination module 210 is used to traverse the abstract syntax tree and determine at least one candidate instrumentation point in the abstract syntax tree in response to the completion of the construction of the abstract syntax tree corresponding to the source code to be instrumented. The target instrumentation point filtering module 220 is used to call a user script to filter at least one target instrumentation point from the candidate instrumentation points and determine the probe code for each target instrumentation point. The instrumentation source code storage module 230 is used to insert probe code at each target instrumentation point to obtain instrumentation source code, store the instrumentation source code in a temporary storage location, and map the file reading path of the instrumentation source code to the temporary storage location through a virtual file system; wherein, the temporary storage location is different from the storage location of the source code; The code compilation module 240 is used to respond to the source file read instruction, read the instrumented source code stored in the temporary storage location based on the file read path, and obtain the compiled target code.

[0110] In an optional implementation, when the instrumentation source code storage module 230 is used to store the instrumentation source code in a temporary storage location, the instrumentation source code storage module 230 is used to: Store the instrumentation source code in a memory buffer; or... The instrumentation source code is written into a temporary file managed by the compilation system.

[0111] In one alternative implementation, such as Figure 3 As shown, when the instrumentation source code storage module 230 maps the file read path of the instrumentation source code to the temporary storage location through the virtual file system, the instrumentation source code storage module 230 is used for: The virtual file and virtual directory structure are defined by predefined file types in the virtual file system, and the file reading path of the instrumented source code is mapped to the temporary storage location.

[0112] In an optional implementation, when the target instrumentation point filtering module 220 is used to call a user script to filter at least one target instrumentation point from the candidate instrumentation points and determine the probe code for each target instrumentation point, the target instrumentation point filtering module 220 is configured to: For each candidate instrumentation point, determine the context information of the candidate instrumentation point, and based on the context information and the decision function in the user script, determine whether to instrument the candidate instrumentation point; If it is determined that a candidate insertion point will be inserted, the candidate insertion point will be designated as the target insertion point, and the probe code for the target insertion point will be determined based on the context information and the insertion detection requirement information.

[0113] In one optional implementation, the context information includes at least one of the following: Information associated with the candidate instrumentation point includes the function name, file name, parameter list, overall function complexity, and annotations.

[0114] In an optional implementation, when the target insertion point screening module 220 determines the probe code for the target insertion point based on the context information and the insertion detection requirement information, the target insertion point screening module 220 is used to: Based on the context information, a probe code template for the target insertion point is determined; Based on the stake detection requirement information and the probe code template, a probe code for the target stake point is obtained.

[0115] In an optional implementation, when the target instrumentation point filtering module 220 determines the probe code template for the target instrumentation point based on the context information, the target instrumentation point filtering module 220 is used to: Based on the context information, a probe code template for the target instrumentation point is selected from a plurality of pre-set candidate probe code templates; or, Based on the context information, a probe code template is constructed for the target insertion point.

[0116] In an optional implementation, when the target stake point screening module 220 is used to obtain the probe code for the target stake point based on the stake detection requirement information and the probe code template, the target stake point screening module 220 is used to: Based on the stake detection requirement information and the probe code template, generate probe code for the target stake point; and / or, Based on the required information for stake insertion, the probe code template is modified to generate probe code for the target stake insertion point.

[0117] In one alternative implementation, the user script is a script compiled based on the user's compilation requirements.

[0118] In one alternative implementation, such as Figure 3 As shown, the processing device 200 further includes a script update module 250, which is used for: In response to adjustments in user compilation requirements, an updated user script is determined, and at least one update instrumentation point is selected from the candidate instrumentation points based on the updated user script.

[0119] In an optional implementation, when the candidate instrumentation point determination module 210, in response to the completion of the construction of the abstract syntax tree corresponding to the source code to be instrumented, traverses the abstract syntax tree and determines at least one candidate instrumentation point in the abstract syntax tree, the candidate instrumentation point determination module 210 is configured to: In response to the completion of the abstract syntax tree corresponding to the source code to be instrumented, the abstract syntax tree is automatically traversed to identify at least one target code structure from the abstract syntax tree; The location of at least one target code structure is determined as at least one candidate instrumentation point in the abstract syntax tree.

[0120] In one alternative implementation, the target code structure includes at least one of the following: The abstract syntax tree contains function definitions, function calls, and basic blocks.

[0121] The code instrumentation processing apparatus provided in this embodiment, in response to the completion of the construction of the abstract syntax tree corresponding to the source code to be instrumented, traverses the abstract syntax tree to determine at least one candidate instrumentation point in the abstract syntax tree; calls a user script to filter at least one target instrumentation point from the candidate instrumentation points, and determines probe code for each target instrumentation point; inserts probe code at each target instrumentation point to obtain instrumented source code, stores the instrumented source code in a temporary storage location, and maps the file read path of the instrumented source code to the temporary storage location through a virtual file system; wherein, the temporary storage location is different from the storage location of the source code; in response to a source file read instruction, reads the instrumented source code stored in the temporary storage location based on the file read path to obtain the compiled target code. In this way, by calling an external user script to filter candidate instrumentation points, at least one target instrumentation point that meets the user's instrumentation detection requirements can be dynamically obtained without modifying the source code, and the instrumentation source code can be generated and stored in a temporary storage location. At the same time, the file reading path of the instrumentation source code is mapped to the temporary storage location through a virtual file system. After the compilation process is triggered, the instrumentation source code stored in the temporary storage location is read and compiled, so that the compilation process no longer reads the source code. The compiled target code is obtained without polluting the source code, which can improve the flexibility of instrumentation processing and reduce the complexity of file management.

[0122] Please see Figure 4 , Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Figure 4 As shown, the electronic device 400 includes a processor 410, a memory 420, and a bus 430.

[0123] The memory 420 stores machine-readable instructions executable by the processor 410. When the electronic device 400 is running, the processor 410 communicates with the memory 420 via the bus 430, causing the processor 410 to execute the following instructions during operation: In response to the completion of the abstract syntax tree corresponding to the source code to be instrumented, the abstract syntax tree is traversed to determine at least one candidate instrumentation point in the abstract syntax tree. Invoke the user script to filter at least one target instrumentation point from the candidate instrumentation points, and determine the probe code for each target instrumentation point; Probe code is inserted at each target instrumentation point to obtain instrumentation source code, which is then stored in a temporary storage location. A virtual file system is used to map the file read path of the instrumentation source code to this temporary storage location; wherein, the temporary storage location is different from the storage location of the source code. In response to the source file read instruction, the instrumented source code stored in the temporary storage location is read based on the file read path to obtain the compiled target code.

[0124] In one optional implementation, the instruction executed by processor 410, which includes storing the instrumentation source code in a temporary storage location, includes: Store the instrumentation source code in a memory buffer; or... The instrumentation source code is written into a temporary file managed by the compilation system.

[0125] In an optional implementation, the instructions executed by the processor 410, wherein mapping the file read path of the instrumented source code to the temporary storage location via the virtual file system, includes: The virtual file and virtual directory structure are defined by predefined file types in the virtual file system, and the file reading path of the instrumented source code is mapped to the temporary storage location.

[0126] In one optional implementation, the instructions executed by the processor 410, including calling a user script to filter at least one target instrumentation point from the candidate instrumentation points and determining probe code for each target instrumentation point, include: For each candidate instrumentation point, determine the context information of the candidate instrumentation point, and based on the context information and the decision function in the user script, determine whether to instrument the candidate instrumentation point; If it is determined that a candidate insertion point will be inserted, the candidate insertion point will be designated as the target insertion point, and the probe code for the target insertion point will be determined based on the context information and the insertion detection requirement information.

[0127] In one optional implementation, the context information includes at least one of the following: Information associated with the candidate instrumentation point includes the function name, file name, parameter list, overall function complexity, and annotations.

[0128] In one optional implementation, the instructions executed by the processor 410, wherein determining the probe code for the target insertion point based on the context information and the insertion probe requirement information, includes: Based on the context information, a probe code template for the target insertion point is determined; Based on the stake detection requirement information and the probe code template, a probe code for the target stake point is obtained.

[0129] In one optional implementation, the instructions executed by the processor 410, wherein determining the probe code template for the target instrumentation point based on the context information, includes: Based on the context information, a probe code template for the target instrumentation point is selected from a plurality of pre-set candidate probe code templates; or, Based on the context information, a probe code template is constructed for the target insertion point.

[0130] In one optional implementation, the instructions executed by the processor 410, wherein obtaining the probe code for the target insertion point based on the insertion probe requirement information and the probe code template, includes: Based on the stake detection requirement information and the probe code template, generate probe code for the target stake point; and / or, Based on the required information for stake insertion, the probe code template is modified to generate probe code for the target stake insertion point.

[0131] In one optional implementation, the user script is a script compiled based on the user's compilation requirements.

[0132] In one optional implementation, the instructions executed by the processor 410 further include: In response to adjustments in user compilation requirements, an updated user script is determined, and at least one update instrumentation point is selected from the candidate instrumentation points based on the updated user script.

[0133] In one optional implementation, the instructions executed by the processor 410, in response to the completion of the construction of the abstract syntax tree corresponding to the source code to be instrumented, traversing the abstract syntax tree and determining at least one candidate instrumentation point in the abstract syntax tree, include: In response to the completion of the abstract syntax tree corresponding to the source code to be instrumented, the abstract syntax tree is automatically traversed to identify at least one target code structure from the abstract syntax tree; The location of at least one target code structure is determined as at least one candidate instrumentation point in the abstract syntax tree.

[0134] In one optional implementation, the target code structure includes at least one of the following: The abstract syntax tree contains function definitions, function calls, and basic blocks.

[0135] By calling an external user script to filter candidate instrumentation points without modifying the source code, at least one target instrumentation point that meets the user's instrumentation detection requirements is dynamically obtained, and the instrumentation source code is generated and stored in a temporary storage location at the target storage location. Simultaneously, a virtual file system maps the file read path of the instrumentation source code to the temporary storage location. Furthermore, the virtual file system maps the subsequent file read paths of the compilation process to the target storage location where the instrumentation source code stored in the temporary storage location is read after the compilation process is triggered. This eliminates the need for the compilation process to read the source code again, obtaining the compiled target code without polluting the source code. This improves the flexibility of instrumentation processing and reduces the complexity of file management. Moreover, operating at the AST level allows direct access to and modification of the structured representation of the code, ensuring the accuracy of instrumentation. Additionally, the compiler itself supports multiple language front-ends, and its AST structure has a certain degree of universality. AST-based plugins are easier to extend to support new languages ​​or language features that the compiler may support in the future. Meanwhile, AST nodes contain rich semantic information, which is crucial for implementing complex instrumentation logic and subsequent filtering decisions, improving the accuracy of determining the target instrumentation location. Furthermore, the compiler can use RecursiveASTVisitor to traverse the abstract syntax tree, accessing all relevant code structures within the compilation unit. This ensures that all potential instrumentation points are considered, avoiding omissions. After obtaining at least one candidate instrumentation point through traversing the abstract syntax tree, a user script can be invoked to filter at least one target instrumentation point from the candidate points based on the decision function contained in the user script. This allows for dynamic and flexible selection of target instrumentation points that meet the user's instrumentation detection requirements, better aligning with debugging needs and improving the user's debugging experience. Finally, after determining at least one target instrumentation point, probe code for the target instrumentation point can be determined using the user script in conjunction with context information. For example, this could involve dynamically generating or selecting a specific probe code template, configuring probe parameters, or specifying the specific method and content of inserting the probe based on context information.This allows the inserted probes to be highly adaptable to different code scenarios and monitoring needs, thereby improving the flexibility and accuracy of probe code generation. Furthermore, if, based on the context information of the current target instrumentation point and the instrumentation detection requirements, it is determined that a corresponding template does not exist among the currently generated candidate probe templates, the user script can automatically generate the corresponding probe code template or modify the pre-generated candidate probe template to obtain the corresponding probe code template. This satisfies all user instrumentation needs, thereby improving the flexibility and accuracy of code compilation. Additionally, if the user changes the location of the instrumentation point or the instrumentation detection requirements, they can directly modify the decision function in the user script to quickly update the target instrumentation point without changing the overall compiler architecture, thus rapidly determining the target instrumentation point and improving code compilation efficiency. Moreover, since the instrumentation point filtering logic and probe customization logic are both located in an external script, users can modify the script content at any time to adjust the filtering strategy and probe behavior without recompiling the plugin itself. This significantly improves the flexibility, accuracy, and ease of use of the instrumentation mechanism, enabling users to quickly iterate and optimize the instrumentation scope and probe functionality, effectively reducing noisy data and unnecessary performance overhead, and obtaining more targeted runtime information. At the same time, it maintains the stability of the plugin's core functionality, delegating volatile filtering and probe customization requirements to external user scripts, which aligns with good software design principles and enhances the system's maintainability and scalability. Furthermore, after obtaining the instrumentation source code, instead of directly overwriting the original source code files on disk, the instrumentation source code is stored in a temporary storage location. This preserves the original source code and avoids issues such as version control chaos and code merging difficulties introduced by instrumentation.

[0136] This disclosure also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the following instructions: In response to the completion of the abstract syntax tree corresponding to the source code to be instrumented, the abstract syntax tree is traversed to determine at least one candidate instrumentation point in the abstract syntax tree. Invoke the user script to filter at least one target instrumentation point from the candidate instrumentation points, and determine the probe code for each target instrumentation point; Probe code is inserted at each target instrumentation point to obtain instrumentation source code, which is then stored in a temporary storage location. A virtual file system is used to map the file read path of the instrumentation source code to this temporary storage location; wherein, the temporary storage location is different from the storage location of the source code. In response to the source file read instruction, the instrumented source code stored in the temporary storage location is read based on the file read path to obtain the compiled target code.

[0137] In one optional implementation, the instruction executed by the computer-readable storage medium, wherein storing the instrumentation source code in a temporary storage location, includes: Store the instrumentation source code in a memory buffer; or... The instrumentation source code is written into a temporary file managed by the compilation system.

[0138] In one optional implementation, the instructions executed by the computer-readable storage medium, wherein mapping the file read path of the instrumentation source code to the temporary storage location via a virtual file system, includes: The virtual file and virtual directory structure are defined by the preset type files in the virtual file system, and the file reading path of the instrumented source code is mapped to the temporary storage location.

[0139] In one optional implementation, the instructions executable by the computer-readable storage medium, wherein calling a user script to filter at least one target instrumentation point from the candidate instrumentation points and determining probe code for each target instrumentation point, includes: For each candidate instrumentation point, determine the context information of the candidate instrumentation point, and based on the context information and the decision function in the user script, determine whether to instrument the candidate instrumentation point; If it is determined that a candidate insertion point will be inserted, the candidate insertion point will be designated as the target insertion point, and the probe code for the target insertion point will be determined based on the context information and the insertion detection requirement information.

[0140] In one optional implementation, the context information includes at least one of the following: Information associated with the candidate instrumentation point includes the function name, file name, parameter list, overall function complexity, and annotations.

[0141] In one optional implementation, the instructions executable by the computer-readable storage medium, wherein determining the probe code for the target insertion point based on the context information and the insertion probe requirement information, includes: Based on the context information, a probe code template for the target insertion point is determined; Based on the stake detection requirement information and the probe code template, a probe code for the target stake point is obtained.

[0142] In one optional implementation, the instructions executable by the computer-readable storage medium, wherein determining the probe code template for the target insertion point based on the context information, includes: Based on the context information, a probe code template for the target instrumentation point is selected from a plurality of pre-set candidate probe code templates; or, Based on the context information, a probe code template is constructed for the target insertion point.

[0143] In one optional implementation, the instructions executable by the computer-readable storage medium, wherein obtaining probe code for the target insertion point based on the insertion probe requirement information and the probe code template, includes: Based on the stake detection requirement information and the probe code template, generate probe code for the target stake point; and / or, Based on the required information for stake insertion, the probe code template is modified to generate probe code for the target stake insertion point.

[0144] In one optional implementation, the user script is a script compiled based on the user's compilation requirements.

[0145] In one optional implementation, the instructions executed by the computer-readable storage medium further include: In response to adjustments in user compilation requirements, an updated user script is determined, and at least one update instrumentation point is selected from the candidate instrumentation points based on the updated user script.

[0146] In one optional implementation, the instructions executed by the computer-readable storage medium, in response to the completion of the construction of the abstract syntax tree corresponding to the source code to be instrumented, traversing the abstract syntax tree and determining at least one candidate instrumentation point in the abstract syntax tree, include: In response to the completion of the abstract syntax tree corresponding to the source code to be instrumented, the abstract syntax tree is automatically traversed to identify at least one target code structure from the abstract syntax tree; The location of at least one target code structure is determined as at least one candidate instrumentation point in the abstract syntax tree.

[0147] In one optional implementation, the target code structure includes at least one of the following: The abstract syntax tree contains function definitions, function calls, and basic blocks.

[0148] By calling an external user script to filter candidate instrumentation points without modifying the source code, at least one target instrumentation point that meets the user's instrumentation detection requirements is dynamically obtained, and the instrumentation source code is generated and stored in a temporary storage location. Simultaneously, a virtual file system maps the file read path of the instrumentation source code to the temporary storage location. After the compilation process is triggered, the instrumentation source code stored in the temporary storage location is read and compiled, eliminating the need to read the source code during compilation. This yields the compiled target code without polluting the source code, improving the flexibility of instrumentation processing and reducing the complexity of file management. Furthermore, operating at the AST level allows direct access to and modification of the structured representation of the code, ensuring the accuracy of instrumentation. The compiler itself supports multiple language front-ends, and its AST structure has a certain degree of universality. AST-based plugins are easier to extend to support new languages ​​or language features that the compiler may support in the future. Additionally, AST nodes contain rich semantic information, which is crucial for implementing complex instrumentation logic and subsequent filtering decisions, improving the accuracy of determining the target instrumentation location. Moreover, the compiler can use RecursiveASTVisitor to traverse the abstract syntax tree, accessing all relevant code structures within the compilation unit. This ensures that all potential instrumentation points are considered, avoiding omissions. Furthermore, after obtaining at least one candidate instrumentation point by traversing the syntax tree, a user script can be invoked to filter at least one target instrumentation point from the candidate points based on the decision function contained in the user script. This allows for dynamic and flexible filtering of target instrumentation points that meet the user's instrumentation detection needs, better aligning with the user's debugging requirements and thus improving the user's debugging experience. Additionally, after identifying at least one target instrumentation point, the probe code for the target instrumentation point can be determined by combining the user script with context information. For example, this could involve dynamically generating or selecting a specific probe code template, configuring probe parameters, or specifying the specific method and content for inserting the probe based on context information.This allows the inserted probes to be highly adaptable to different code scenarios and monitoring needs, thereby improving the flexibility and accuracy of probe code generation. Furthermore, if, based on the context information of the current target instrumentation point and the instrumentation detection requirements, it is determined that a corresponding template does not exist among the currently generated candidate probe templates, the user script can automatically generate the corresponding probe code template or modify the pre-generated candidate probe template to obtain the corresponding probe code template. This satisfies all user instrumentation needs, thereby improving the flexibility and accuracy of code compilation. Additionally, if the user changes the location of the instrumentation point or the instrumentation detection requirements, they can directly modify the decision function in the user script to quickly update the target instrumentation point without changing the overall compiler architecture, thus rapidly determining the target instrumentation point and improving code compilation efficiency. Moreover, since the instrumentation point filtering logic and probe customization logic are both located in an external script, users can modify the script content at any time to adjust the filtering strategy and probe behavior without recompiling the plugin itself. This significantly improves the flexibility, accuracy, and ease of use of the instrumentation mechanism, enabling users to quickly iterate and optimize the instrumentation scope and probe functionality, effectively reducing noisy data and unnecessary performance overhead, and obtaining more targeted runtime information. At the same time, it maintains the stability of the plugin's core functionality, delegating volatile filtering and probe customization requirements to external user scripts, which aligns with good software design principles and enhances the system's maintainability and scalability. Furthermore, after obtaining the instrumentation source code, instead of directly overwriting the original source code files on disk, the instrumentation source code is stored in a temporary storage location. This preserves the original source code and avoids issues such as version control chaos and code merging difficulties introduced by instrumentation.

[0149] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0150] In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the shown or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0151] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0152] In addition, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0153] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0154] Finally, it should be noted that the above-described embodiments are merely specific implementations of this disclosure, used to illustrate the technical solutions of this disclosure, and not to limit it. The protection scope of this disclosure is not limited thereto. Although this disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this disclosure; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this disclosure, and should all be covered within the protection scope of this disclosure. Therefore, the protection scope of this disclosure should be determined by the protection scope of the claims.

Claims

1. A method for code instrumentation, characterized in that, Applied to the compiler; the processing method includes: In response to the completion of the abstract syntax tree corresponding to the source code to be instrumented, the abstract syntax tree is traversed to determine at least one candidate instrumentation point in the abstract syntax tree. Invoke the user script to filter at least one target instrumentation point from the candidate instrumentation points, and determine the probe code for each target instrumentation point; Probe code is inserted at each target instrumentation point to obtain instrumentation source code, which is then stored in a temporary storage location. A virtual file system is used to map the file read path of the instrumentation source code to this temporary storage location; wherein, the temporary storage location is different from the storage location of the source code. In response to the source file read instruction, the instrumented source code stored in the temporary storage location is read based on the file read path to obtain the compiled target code.

2. The processing method according to claim 1, characterized in that, The step of storing the instrumentation source code in a temporary storage location includes: Store the instrumentation source code in a memory buffer; or... The instrumentation source code is written into a temporary file managed by the compilation system.

3. The processing method according to claim 1, characterized in that, The step of mapping the file read path of the instrumented source code to the temporary storage location through a virtual file system includes: The virtual file and virtual directory structure are defined by predefined file types in the virtual file system, and the file reading path of the instrumented source code is mapped to the temporary storage location.

4. The processing method according to claim 1, characterized in that, The step of invoking the user script to filter at least one target instrumentation point from the candidate instrumentation points and determining the probe code for each target instrumentation point includes: For each candidate instrumentation point, determine the context information of the candidate instrumentation point, and based on the context information and the decision function in the user script, determine whether to instrument the candidate instrumentation point; If it is determined that a candidate insertion point will be inserted, the candidate insertion point will be designated as the target insertion point, and the probe code for the target insertion point will be determined based on the context information and the insertion detection requirement information.

5. The processing method according to claim 4, characterized in that, The context information includes at least one of the following: Information associated with the candidate instrumentation point includes the function name, file name, parameter list, overall function complexity, and annotations.

6. The processing method according to claim 4, characterized in that, The step of determining the probe code for the target stake point based on the context information and stake detection requirements includes: Based on the context information, a probe code template for the target insertion point is determined; Based on the stake detection requirement information and the probe code template, a probe code for the target stake point is obtained.

7. The processing method according to claim 5, characterized in that, The step of determining the probe code template for the target insertion point based on the context information includes: Based on the context information, a probe code template for the target instrumentation point is selected from a plurality of pre-set candidate probe code templates; or, Based on the context information, a probe code template is constructed for the target insertion point.

8. The processing method according to claim 5, characterized in that, The step of obtaining probe codes for the target stake point based on the stake detection requirement information and the probe code template includes: Based on the stake detection requirement information and the probe code template, generate probe code for the target stake point; and / or, Based on the required information for stake insertion, the probe code template is modified to generate probe code for the target stake insertion point.

9. The processing method according to claim 1, characterized in that, The user script is a script compiled based on the user's compilation requirements.

10. The processing method according to claim 1, characterized in that, The processing method further includes: In response to adjustments in user compilation requirements, an updated user script is determined, and at least one update instrumentation point is selected from the candidate instrumentation points based on the updated user script.

11. The processing method according to claim 1, characterized in that, In response to the completion of the abstract syntax tree corresponding to the source code to be instrumented, the abstract syntax tree is traversed to determine at least one candidate instrumentation point in the abstract syntax tree, including: In response to the completion of the abstract syntax tree corresponding to the source code to be instrumented, the abstract syntax tree is automatically traversed to identify at least one target code structure from the abstract syntax tree; The location of at least one target code structure is determined as at least one candidate instrumentation point in the abstract syntax tree.

12. The processing method according to claim 10, characterized in that, The target code structure includes at least one of the following: The abstract syntax tree contains function definitions, function calls, and basic blocks.

13. A code instrumentation processing device, characterized in that, Applied to a compiler; the processing device includes: The candidate instrumentation point determination module is used to traverse the abstract syntax tree and determine at least one candidate instrumentation point in the abstract syntax tree in response to the completion of the construction of the abstract syntax tree corresponding to the source code to be instrumented. The target instrumentation point filtering module is used to call a user script to filter at least one target instrumentation point from the candidate instrumentation points and determine the probe code for each target instrumentation point. An instrumentation source code storage module is used to insert probe code at each target instrumentation point to obtain instrumentation source code, store the instrumentation source code in a temporary storage location, and map the file read path of the instrumentation source code to the temporary storage location through a virtual file system; wherein, the temporary storage location is different from the storage location of the source code; The code compilation module is used to respond to the source file read instruction by reading the instrumented source code stored in the temporary storage location based on the file read path, and obtain the compiled target code.

14. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the memory via the bus, and the processor executes the machine-readable instructions to perform the steps of the code instrumentation processing method as described in any one of claims 1 to 12.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the code instrumentation processing method according to any one of claims 1 to 12.

Images