LLVM opaque pointer-oriented multi-type static derivation method

Abstract

The invention discloses an LLVM opaque pointer-oriented multi-type static derivation method, which comprises the following steps of: obtaining a source code of a to-be-analyzed program, and recovering type source information of an IR variable from the source code; by utilizing a type access path technology and a plurality of types of alias rules, type propagation derivation is carried out based on type source information of an IR variable, so that multi-type static derivation is realized; wherein the type alias rule comprises an address taking rule, a field access rule, a type conversion rule, a function calling rule, a storage rule, a loading rule, a copying rule, a binary operation rule and a control flow merging rule. According to the method, by recovering the type information of the opaque pointer in the LLVM IR and supporting multi-type design, an efficient static type analysis method is realized, and all types which the pointer variable possibly points to can be accurately inferred, so that more reliable type information support is provided for subsequent program analysis and security check.

Description

Technical Field

[0001] The present invention relates to the technical field of program analysis, and in particular, to a multi-type static inference method for LLVM opaque pointers. Background Art

[0002] With the increasing complexity of software systems, program analysis and security checks play an increasingly important role in software development. As a widely used compiler infrastructure, the Intermediate Representation (IR) of LLVM provides an important basis for program analysis. However, although the opaque pointer feature introduced in LLVM 15 simplifies the representation form of IR, it also brings new challenges to program analysis. Opaque pointers unify pointer representations by removing all pointing type information. Although this design reduces the complexity of IR, it also causes a serious loss of type information, making it difficult to directly apply traditional type analysis methods.

[0003] In existing technical solutions, type inference methods are mainly designed for assembly binary code and dynamic languages, and these methods have obvious limitations when dealing with LLVM IR. Especially when encountering general pointer types (such as void*), existing tools often stop the inference process and cannot obtain more specific type information. In addition, most existing analysis tools adopt a single type design and cannot effectively handle the scenario where a pointer variable may point to multiple different types. This limitation often leads to the loss or inaccuracy of type information when analyzing actual programs.

[0004] In terms of large-scale program analysis, existing technical solutions face more severe challenges. Traditional pointer analysis methods (such as Andersen analysis) often encounter performance bottlenecks when dealing with large programs, resulting in difficult analysis processes. For example, when analyzing the Linux kernel, about 50% of the variables cannot be analyzed within a reasonable time. This scalability problem severely restricts the application of static analysis tools in large projects. At the same time, existing tools lack special support for the LLVM opaque pointer feature and cannot adapt to the new IR representation form.

[0005] Therefore, there is an urgent need for a new technical solution in the field of software development and analysis, which should be able to: (1) accurately restore the type information in LLVM IR, especially in the case of using opaque pointers; (2) support scenarios where pointer variables have multiple possible types and provide more complete type analysis capabilities; (3) maintain compatibility with existing static analysis tools to facilitate the integration of the tool chain; (4) have the ability to analyze large-scale programs, especially to maintain good performance when analyzing large open-source infrastructures (such as the Linux kernel). Solving these requirements is of great significance for improving the accuracy and practicality of program analysis. Summary of the Invention

[0006] In view of the deficiencies of the prior art, the purpose of the embodiments of the present application is to provide a multi-type static derivation method for LLVM opaque pointers.

[0007] According to the first aspect of the embodiments of the present application, a multi-type static derivation method for LLVM opaque pointers is provided, including:

[0008] Obtain the source code of the program to be analyzed, and restore the type source information of IR variables from the source code;

[0009] Utilize the type access path technology and several type alias rules to perform type propagation derivation based on the type source information of IR variables, thereby realizing multi-type static derivation, where the type alias rules include the address-taking rule, the field access rule, the type conversion rule, the function call rule, the storage rule, the loading rule, the copying rule, the binary operation rule, and the control flow merging rule.

[0010] Further, restoring the type source information of IR variables from the source code includes:

[0011] Use the type definitions in the C language source code stored in the debug information of LLVM IR as the type definitions of the structures;

[0012] Restore the type information of global variables and local variables in the stack by adding one level of pointer hierarchy;

[0013] Based on the allocation interface of heap objects, interpret heap data as pointers to specific types, thereby analyzing the type information of heap objects;

[0014] Adopt the declared types of function parameters as the types of function parameters;

[0015] Match the corresponding variables in the source code through the function or scope and naming method where the IR variable is located, and establish a mapping relationship between the source code variables and the IR variables, thereby obtaining the type source information of the IR variables.

[0016] Further, by using the type access path technology and several type alias rules, type propagation deduction is performed based on the type source information of IR variables, including:

[0017] Construct and maintain a type alias set for each IR variable;

[0018] Using the type access path technology, track the type propagation of structure fields based on the structure type and field index;

[0019] Using the type alias rules, perform type propagation of IR variables based on the type source information of IR variables and the type alias set.

[0020] Further, the type of an IR variable is defined to consist of two parts: (τ, η), where τ ∈ T represents the base non-pointer type, and η is a non-negative integer representing the pointer indirection level. If the variable is a non-pointer type, then η is 0;

[0021] In the type alias rules, tar is used to represent a mapping relationship that associates a unique intermediate representation variable with its valid type alias set. Each type in the set corresponding to variable p is represented by (τ, η) ∈ tar(p);

[0022] The type alias rules are as follows:

[0023] (1) Address-taking rule

[0024] When pointer p initially points to object o, obtain the type (τ, η) of o from the type source information, and update the type alias set tar(p) of the pointer by increasing one level of pointer hierarchy (τ, η + 1);

[0025] (2) Field access rule

[0026] When it is necessary to obtain the address of the i-th field from the structure object stored in pointer q and store it in p, deduce the type τ of the i-th field from the type source information f , and set it as the type of the variable p storing the field address by adding one level of pointer to the field type, where q is a pointer to a memory object with a base type of τ q and its pointer indirection level η q is always 1;

[0027] (3) Type conversion rule

[0028] For the case where a variable q with a type alias set tar(q) is converted to another type of IR variable p, use the type information in the conversion instruction to obtain the target type (τ p , η p) Add it to the set tar(q) of source operands and merge it with the set of type aliases of p;

[0029] (4) Function call rule

[0030] When processing a call to a function q with n arguments r1,..., r n and a return value p, organize these types into a function type, where tar(p) represents the set of type aliases of the return value, and tar(r1),..., tar(r n ) represent the sets of arguments in order. These type information are integrated into the set of type aliases of function q;

[0031] (5) Storage rule

[0032] When storing variable q to pointer p, pass the set of type aliases of q to the set of p and keep the base type unchanged but increase one level of pointer hierarchy, where Δ(p) is the adjustment for pointer analysis;

[0033] (6) Loading rule

[0034] When loading a value from pointer q to p, update the set of p with the set of type aliases of q;

[0035] (7) Copy rule

[0036] For the assignment operation between variables, copy all elements in the set of type aliases of the source variable q to the set of the target variable p;

[0037] (8) Binary operation rule

[0038] For the variable r calculated from operands p and q, set its set of type aliases to the union of the sets of the two operands;

[0039] (9) Control flow merge rule

[0040] For a phi node with multiple input values, take the union of the sets of type aliases of all input operands as the type propagation result.

[0041] According to the second aspect of the embodiments of the present application, there is provided a multi-type static derivation device for LLVM opaque pointers, including:

[0042] A type source information acquisition module, configured to acquire the source code of the program to be analyzed and restore the type source information of IR variables from the source code;

[0043] The type propagation module is used to perform type propagation inference based on the type source information of IR variables using type access path technology and several type alias rules, thereby realizing multi-type static inference. The type alias rules include address taking rules, field access rules, type conversion rules, function call rules, storage rules, loading rules, copying rules, binary operation rules, and control flow merging rules.

[0044] According to a third aspect of an embodiment of the present application, a computer program product is provided, comprising a computer program / instruction, which implements the method described in the first aspect when executed by a processor.

[0045] According to a fourth aspect of the embodiments of the present application, there is provided an electronic device, including:

[0046] one or more processors;

[0047] a memory for storing one or more programs;

[0048] When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in the first aspect.

[0049] According to a fifth aspect of an embodiment of the present application, a computer-readable storage medium is provided, on which computer instructions are stored. When the instructions are executed by a processor, the steps of the method described in the first aspect are implemented.

[0050] This paper proposes an out-of-band type source recovery method, which for the first time achieves reliable type information recovery from source code to IR. It breaks through the limitations of traditional single-type design and innovatively supports scenarios where variables have multiple possible types. It pioneers an alias rule inference mechanism based on type access paths, formalizing type propagation in IR instructions. It designs nine type alias rules to implement a complete type inference system. It adopts a field-sensitive and flow-insensitive analysis method to balance analysis accuracy and performance. Therefore, the beneficial effects of this invention are:

[0051] 1) It effectively solves the problem of type information loss caused by LLVM opaque pointers and significantly improves the accuracy of type inference.

[0052] 2) It enables efficient analysis of large-scale programs, and is particularly suitable for open source infrastructure such as the Linux kernel.

[0053] 3) Through standardized interface design, it can be easily integrated into existing program analysis tools.

[0054] 4) It provides a more reliable type information foundation for program security analysis and improves the accuracy of static analysis tools.

[0055] Therefore, the present invention has good prospects for popularization and application.

[0056] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit this application. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] The accompanying drawings herein are incorporated into the specification and constitute a part of this specification, showing embodiments consistent with this application, and are used together with the specification to explain the principles of this application.

[0058] Figure 1 is a multi-type static derivation method for LLVM opaque pointers shown according to an exemplary embodiment.

[0059] Figure 2 A block diagram of a multi-type static derivation device for LLVM opaque pointers shown according to an exemplary embodiment.

[0060] Figure 3 is a schematic diagram of an electronic device shown according to an exemplary embodiment. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0061] Here, the exemplary embodiments will be described in detail, and the examples are shown in the accompanying drawings. When the following description refers to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application.

[0062] The terms used in this application are only for the purpose of describing specific embodiments and are not intended to limit this application. The singular forms of "a", "the" and "said" used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0063] It should be understood that although the terms first, second, third, etc. may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of this application, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "when" or "while" or "in response to determining".

[0064] Figure 1 is a flowchart of a multi-type static derivation method for LLVM opaque pointers shown according to an exemplary embodiment, asFigure 1 As shown, this method is applied to a terminal and includes the following steps:

[0065] Step S1: Obtain the source code of the program to be analyzed, and recover the type source information of IR variables from the source code;

[0066] This step first ensures that the structure type has an accurate definition, including pointer fields with specific types, and then recovers the type information of declared variables. By collecting reliable type information from the source code and IR, a basis for type recovery is established, providing a reliable starting point for subsequent type inference. This step includes the following specific sub-steps:

[0067] Step S11: Use the type definitions in the C language source code stored in the debug information of LLVM IR as the type definitions of the structures;

[0068] Specifically, this sub-step directly uses the type definitions in the C language source code stored in the debug information of LLVM IR, without relying on the converted definitions in the IR type system. Since the type definitions of the source code are independent of the LLVM IR syntax, they can be conveniently collected. Even if opaque pointers cause all fields of the structure definition in the IR to lose the pointed-to type, this step can still recover this type information, ensuring the integrity and accuracy of the structure type.

[0069] Step S12: Recover the type information of global variables and local variables on the stack by adding one level of pointer hierarchy;

[0070] Specifically, this sub-step processes IR variables related to allocated memory. For global variables and local variables on the stack, it is necessary to handle the characteristic that they have one more level of pointer indirection in the IR than in the source code. For example, an int type in the source code becomes i32* in the IR, and int* becomes i32**. It also processes local variables that are directly demoted to IR variables without being allocated on the stack memory, establishing a mapping relationship between these variables and the source code.

[0071] Step S13: Based on the allocation interface of heap objects, interpret heap data as pointers to specific types, so as to analyze the type information of heap objects;

[0072] Specifically, this sub-step obtains type information by analyzing the allocation interfaces of heap objects (such as malloc). These interfaces use parameters to specify the size of the allocation type and return the address of the allocated heap object. By analyzing these allocation interfaces, IR variables can be interpreted as pointers to specific types, where the pointed-to type is the type of the allocated memory.

[0073] Step S14: Adopt the declared type of function parameters as the type of function parameters;

[0074] Specifically, this sub-step establishes a reliable type source based on the type information of function parameters. Although in theory, it is necessary to trace the allocated memory through pointer analysis to recover all pointer types, considering the complexity of large-scale programs, this step uses the declared types of function parameters as the reliable type source. Practice has shown that the reliability of this assumption is very high, and the parameters of more than 90% of the call instructions are consistent with the parameter types declared in the function.

[0075] Step S15: Match the variables in the corresponding source code through the function or scope and naming method of the IR variable, and establish a mapping relationship between the source code variable and the IR variable, so as to obtain the type source information of the IR variable;

[0076] Specifically, this sub-step matches the variables in the corresponding source code through the function or scope and naming method of the IR variable, and establishes a one-to-one mapping relationship between the source code variable and the IR variable. Through this mapping, the type information in the source code can be used to recover the type of the IR variable. This mapping relationship is particularly important for the definition locations of global variables, local objects, and heap objects, because all the pointed memory objects are created at the declared IR variables, and these mappings can cover all the required starting points to help the subsequent type propagation analysis.

[0077] Step S2: Use the type access path technology and several type alias rules to perform type propagation deduction based on the type source information of the IR variable, so as to achieve multi-type static deduction;

[0078] This step infers the types of more variables and fills the type alias set by tracing the complex propagation starting from the reliable type source. Based on the multi-type design, the type flow in the LLVM IR instruction is formalized into a set of type alias rules, and an independent type alias set is maintained for the IR variable, so that the previous type analysis can query types from these sets without modifying the IR. This step specifically designs the type organization for the opaque pointer IR, including the following specific sub-steps:

[0079] Step S21: Build and maintain the type alias set for each IR variable;

[0080] This sub-step establishes and maintains an independent type alias set for each IR variable, where the type alias is defined as follows: for a variable, if its type is A in a certain context and its type is B in another context, then A and B are called type aliases of each other.

[0081] By establishing a type lattice system, opaque pointers, void*, and concrete type pointers are organized into a hierarchical relationship (ptr <: void* <: type*), while handling the correspondence between integer types and C language types. Different from traditional methods, this step allows variables to be bound to multiple types simultaneously and continues to infer until a concrete pointer type is obtained, rather than stopping the inference when a general pointer type is obtained.

[0082] Step S22: Utilize the type access path technology to trace the type propagation of structure fields based on the structure type and field index;

[0083] This sub-step introduces the concept of type access paths for precisely and efficiently resolving the concrete types of general pointers. When the data flow is disconnected between multiple entry points, they are reconnected by analyzing the types on the access path (i.e., the structure type and field index). This cross-procedure analysis continues until a concrete type is identified from a memory allocation point or a variable with an inferred type. This method has better scalability compared to traditional Andersen analysis and can effectively handle the analysis requirements of large-scale programs.

[0084] Step S23: Based on the type source information of IR variables and the type alias set, perform type propagation of IR variables using type alias rules;

[0085] This application defines nine core type alias rules, including AddrOf (handling address-taking operations), Field (handling structure field access), Cast (handling type conversions), Load / Store (handling memory operations), Call (handling function calls), Binary (handling binary operations), and Phi (handling control flow merging), etc. These rules are implemented in a field-sensitive, flow-insensitive, and context-insensitive manner, ensuring the scalability of the analysis through one-time loop unrolling and stable calculation of the type alias set. For each rule, the way of type propagation and the update strategy of the type alias set are precisely defined, ensuring the accuracy and integrity of type derivation.

[0086] The type alias rules of the present invention are specifically implemented as follows:

[0087] In this rule, the type of an IR variable is defined to consist of two parts: (τ, η). Where τ ∈ T represents the base non-pointer type, and η is a non-negative integer representing the pointer indirection level. If the variable is of non-pointer type, then η is 0.

[0088] The rule uses tar to represent a mapping relationship that associates a unique intermediate representation variable with its valid type alias set. In the rule description, traversing each type in the set corresponding to variable p is represented by (τ, η) ∈ tar(p).

[0089] 1. Address-taking Rule

[0090] When the pointer p initially points to the object o, the present invention first obtains the type (τ, η) of o from the type source, and then updates the type alias set tar(p) of the pointer by adding one level of pointer hierarchy (τ, η + 1). This rule ensures the correct correspondence between the pointer type and the type of the object it points to.

[0091] 2. Field Access Rule

[0092] When it is necessary to obtain the address of the i-th field from the structure object stored in the pointer q and store it in p, the present invention first derives the type τ of the i-th field from the type source (i.e., the structure definition in the source code). f . By adding one level of pointer to the field type, it is set as the type of the variable p that stores the field address. To avoid false alarms, the present invention stipulates that q must be a pointer to a memory object whose base type is τ q , and its pointer indirection level η q is always 1.

[0093] 3. Type Conversion Rule

[0094] For the case where a variable q with a type alias set tar(q) is converted to an IR variable p of another type, the present invention uses the type information in the conversion instruction to obtain the target type (τ p , η p ), adds it to the set tar(q) of the source operand, and merges it with the type alias set of p. This ensures that the type set contains all possible memory types.

[0095] 4. Function Call Rule

[0096] When dealing with the call of a function q with n arguments r1,..., r n and a return value p, the present invention organizes these types into a function type. Among them, tar(p) represents the type alias set of the return value, and tar(r1),..., tar(r n ) represent the set of arguments in order, and these type information are finally integrated into the type alias set of the function q.

[0097] 5. Storage Rule

[0098] When storing variable q into pointer p, the present invention passes the set of type aliases of q to the set of p while keeping the base type unchanged but increasing one level of pointer hierarchy. Additionally, it includes an adjustment Δ(p) for pointer analysis.

[0099] 6. Loading Rule

[0100] When loading a value from pointer q into p, the present invention updates the set of p using the set of type aliases of q, keeping the basic non-pointer type unchanged but reducing one level of pointer hierarchy. Additional pointer analysis adjustments are made through Δ(p) when necessary.

[0101] 7. Copy Rule

[0102] For the assignment operation between variables, the present invention copies all elements in the set of type aliases of the source variable q to the set of the target variable p.

[0103] 8. Binary Operation Rule

[0104] For variable r calculated from operands p and q, the present invention sets its set of type aliases as the union of the sets of the two operands to ensure that no possible types are missed.

[0105] 9. Control Flow Merging Rule

[0106] For phi nodes with multiple input values, the present invention takes the union of the sets of type aliases of all input operands as the result.

[0107] In summary, the present application proposes a multi-type static inference method for LLVM opaque pointers. By combining out-of-band type source recovery and alias inference technology based on type access paths, it effectively solves the problem of type information loss caused by LLVM opaque pointers. This method first recovers reliable type information from the source code, including the types of structure definitions, global variables, local variables, heap data, and function parameters; then performs type alias inference based on type access paths, and realizes type propagation and inference through nine carefully designed type alias rules. The present invention breaks through the limitations of traditional type analysis methods, supports scenarios where variables have multiple possible types, and ensures the accuracy and scalability of the analysis through field-sensitive and flow-insensitive analysis methods. This method is particularly suitable for the analysis of large-scale programs and can provide more reliable type information support for program security analysis.

[0108] Corresponding to the embodiment of the multi-type static inference method for LLVM opaque pointers described above, the present application also provides an embodiment of a multi-type static inference device for LLVM opaque pointers.

[0109] Figure 2 It is a block diagram of a multi-type static derivation device for LLVM opaque pointers shown according to an exemplary embodiment. Referring to Figure 2 , the device may include:

[0110] A type source information acquisition module 21, configured to acquire the source code of the program to be analyzed, and recover the type source information of IR variables from the source code;

[0111] A type propagation module 22, configured to perform type propagation derivation based on the type source information of IR variables by using the type access path technology and several type alias rules, so as to implement multi-type static derivation, where the type alias rules include the address-taking rule, the field access rule, the type conversion rule, the function call rule, the storage rule, the loading rule, the copying rule, the binary operation rule, and the control flow merging rule.

[0112] Regarding the device in the above embodiment, the specific manners in which each module performs operations have been described in detail in the embodiment of the method related thereto, and will not be elaborated herein.

[0113] For the device embodiment, since it basically corresponds to the method embodiment, the relevant parts can be referred to the partial description of the method embodiment. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of the present application. Those of ordinary skill in the art can understand and implement it without creative efforts.

[0114] Correspondingly, the present application also provides a computer program product, including a computer program / instructions, which when executed by a processor, implement the multi-type static derivation method for LLVM opaque pointers as described above.

[0115] Correspondingly, the present application also provides an electronic device, including: one or more processors; a memory, configured to store one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors implement the multi-type static derivation method for LLVM opaque pointers as described above. As Figure 3 shown, it is a hardware structure diagram of any device with data processing capabilities where the multi-type static derivation device for LLVM opaque pointers provided by the embodiment of the present invention is located. Except for Figure 3In addition to the processor, memory, and network interface shown, any device with data processing capabilities where the device in the embodiment is located may generally include other hardware according to the actual functions of the device with data processing capabilities, which will not be elaborated herein.

[0116] Correspondingly, the present application further provides a computer-readable storage medium, on which computer instructions are stored. When the instructions are executed by a processor, the multi-type static derivation method for LLVM opaque pointers as described above is implemented. The computer-readable storage medium may be an internal storage unit of any device with data processing capabilities described in any of the foregoing embodiments, such as a hard disk or memory. The computer-readable storage medium may also be an external storage device, such as a plug-in hard disk, a Smart Media Card (SMC), an SD card, a Flash Card, etc. equipped on the device. Further, the computer-readable storage medium may also include both an internal storage unit of any device with data processing capabilities and an external storage device. The computer-readable storage medium is used to store the computer program and other programs and data required by any device with data processing capabilities, and may also be used to temporarily store data that has been output or is to be output.

[0117] After considering the specification and practicing the content disclosed herein, those skilled in the art will readily conceive of other embodiments of the present application. The present application is intended to cover any variations, uses, or adaptations of the present application, which follow the general principles of the present application and include known common knowledge or conventional technical means in the technical field not disclosed in the present application.

Claims

1. A multi-type static inference method for LLVM opaque pointers, characterized in that including: Obtain the source code of the program to be analyzed, and recover the type source information of IR variables from the source code; Use type access path technology and several type alias rules to perform type propagation deduction based on the type source information of IR variables, so as to achieve multi-type static deduction, where the type alias rules include address-taking rule, field access rule, type conversion rule, function call rule, storage rule, loading rule, copy rule, binary operation rule, and control flow merging rule.

2. The method according to claim 1, characterized in that, Recover the type source information of IR variables from the source code, including: Use the type definitions in the C language source code stored in the debug information of LLVM IR as the type definitions of structures; Recover the type information of global variables and local variables on the stack by adding one level of pointer hierarchy; Based on the allocation interface of heap objects, interpret heap data as pointers to specific types, so as to analyze the type information of heap objects; Adopt the declared type of function parameters as the type of function parameters; Match the variables in the corresponding source code through the function or scope and naming method where the IR variable is located, establish the mapping relationship between the source code variables and the IR variables, so as to obtain the type source information of the IR variables.

3. The method according to claim 1, characterized in that, Use type access path technology and several type alias rules to perform type propagation deduction based on the type source information of IR variables, including: Construct and maintain the type alias set of each IR variable; Use type access path technology to track the type propagation of structure fields based on structure types and field indexes; Use type alias rules to perform type propagation of IR variables based on the type source information of IR variables and the type alias set.

4. According to the method described in claim 1, the type of the IR variable is defined to consist of two parts: (τ, η), where τ ∈ T represents the base non-pointer type, η is a non-negative integer representing the pointer indirection level, and if the variable is a non-pointer type, then η is 0; In the type alias rules, tar is used to represent a mapping relationship that associates a unique intermediate representation variable with its valid type alias set, and each type in the set corresponding to the traversed variable p is represented by (τ, η) ∈ tar(p); The type alias rules are as follows: (1) Address-taking rule When the pointer p initially points to the object o, obtain the type (τ, η) of o from the type source information, and update the type alias set tar(p) of the pointer by adding one level of pointer hierarchy (τ, η + 1); (2) Field access rules When it is necessary to obtain the address of the i-th field from the structure object stored in pointer q and store it in p, the type τ of the i-th field is deduced from the type source information. f , by adding a layer of pointer to the field type, it is set as the type of the variable p that stores the field address, where q is a pointer to a memory object with a base type of τ q , and its pointer indirection level η q is always 1; (3) Type conversion rules For the case where a variable q with a set of type aliases tar(q) is converted to another type of IR variable p, the type information in the conversion instruction is used to obtain the target type (τ p ,η p ), which is added to the set tar(q) of source operands and merged with the set of type aliases of p; (4) Function call rules When dealing with a call to a function q with n parameters r1,..., r n and a return value p, these types are organized into a function type, where tar(p) represents the set of type aliases for the return value, and tar(r1),..., tar(r n ) represent the set of parameters in order. This type information is integrated into the set of type aliases for the function q; (5) Storage rules When storing the variable q into the pointer p, pass the type alias set of q to the set of p, and keep the base type unchanged but add one level of pointer hierarchy, where Δ(p) is the adjustment for pointer analysis; (6) Loading rules When loading a value from the pointer q to p, update the set of p with the type alias set of q; (7) Replication rules For the assignment operation between variables, copy all elements in the type alias set of the source variable q to the set of the target variable p; (8) Binary operation rules For the variable r calculated by the operands p and q, set its type alias set as the union of the sets of the two operands; (9) Control flow merging rule For the phi node with multiple input values, take the union of the type alias sets of all input operands as the type propagation result.

5. A multi-type static inference device for LLVM opaque pointers, characterized in that, including: A type source information acquisition module, configured to acquire the source code of the program to be analyzed, and recover the type source information of IR variables from the source code; A type propagation module, configured to perform type propagation derivation based on the type source information of IR variables by using the type access path technology and several type alias rules, so as to implement multi-type static derivation, wherein the type alias rules include the address-taking rule, the field access rule, the type conversion rule, the function call rule, the storage rule, the loading rule, the copying rule, the binary operation rule, and the control flow merging rule.

6. A computer program product, comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by a processor, the method according to any one of claims 1-4 is implemented.

7. An electronic device, characterized in that, Comprising: One or more processors; A memory, configured to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1-4.

8. A computer-readable storage medium having computer instructions stored thereon, characterized in that, When the instruction is executed by a processor, the steps of the method according to any one of claims 1-4 are implemented.

Images