Dynamic symbol analyzing and loading method based on stub function

Abstract

The invention discloses a stub function-based dynamic symbol analysis and loading method, which comprises the following steps of: 1, pre-compiling a source code file by a cloud server to generate an intermediate file, and establishing a mapping relationship between a function symbol and the intermediate file; 2, the operation end requests an executable file containing a target symbol according to needs, and the cloud end retrieves and compiles according to the mapping relation to generate a corresponding target file; step 3, the running end receives and loads the target file to a memory, program execution is started, and an agent analysis mechanism is set for the undefined symbols; 4, triggering dynamic loading based on a proxy analysis mechanism, and analyzing and executing unanalyzed symbols; based on the LLVM ORC technology, the pre-loading overhead of the operation end is effectively reduced, the calculation and storage burden is reduced, and the on-demand analysis capability and the execution flexibility of the module are enhanced.

Description

Technical Field

[0001] The present invention belongs to the technical field of network security, and specifically relates to a dynamic symbol parsing and loading method based on stub functions. Background Art

[0002] Existing dynamic code loading and symbol parsing technologies mainly include the runtime symbol parsing method based on LLVM ORC and traditional dynamic linking technologies. However, these methods still have limitations in terms of parsing efficiency and resource consumption.

[0003] In the LLVM ORC framework, symbol parsing adopts a lazy mechanism, which postpones the parsing until the symbol is first called. However, this mechanism still depends on the parsing strategy in the symbol lookup phase. When a symbol is referenced, the runtime will parse the symbol and all its dependencies through the LazyReexports mechanism and only allow the call after the parsing is completed. Although this process reduces the overhead of symbol initialization, it cannot completely avoid pre-parsing behavior, resulting in the need to pre-parse some symbols in advance when the program starts or a module is loaded, thus bringing additional computational and storage overheads. For large-scale modular applications, it is difficult to completely avoid resource waste with this pre-parsing mechanism.

[0004] Traditional dynamic linking technologies (such as dlopen() and dlsym()) achieve a certain degree of lazy parsing by loading shared libraries on demand, but still have the following problems:

[0005] 1. dlopen() needs to load the entire shared library and cannot achieve more fine-grained symbol-level on-demand loading;

[0006] 2. dlsym() depends on global symbol table lookup when parsing symbols, which may introduce additional parsing overheads;

[0007] 3. This technology depends on the access to shared libraries in the local file system and is difficult to apply to distributed or remote computing environments.

[0008] Existing research mainly focuses on optimizing the execution efficiency of symbol parsing and dynamic linking, but there are still deficiencies in fine-grained dynamic loading at the symbol level and it is difficult to effectively solve the problems of pre-parsing and resource consumption. Summary of the Invention

[0009] To overcome the deficiencies of the above-mentioned existing technologies, the purpose of the present invention is to provide a dynamic symbol parsing and loading method based on stub functions, which overcomes the problem of excessive resource consumption caused by pre-parsing in the existing technology and reduces the dependence on local storage.

[0010] To achieve the above purpose, the technical solution adopted by the present invention is:

[0011] A dynamic symbol parsing and loading method based on stub functions, characterized by including the following steps:

[0012] Step 1, the cloud server pre-compiles the source code file, generates an intermediate file, and establishes a mapping relationship table between function symbols and the intermediate file;

[0013] The specific implementation of Step 1 is as follows:

[0014] Step 1.1, the cloud server pre-compiles the source code: the cloud server compiles each.c file in the source code into a.bc file for storage;

[0015] Step 1.2, extract the corresponding relationship between the function symbols and the intermediate file storage addresses included in the.bc file, and establish a mapping relationship table;

[0016] Step 2, the running end requests the executable file containing the target function as needed, and the cloud server retrieves and compiles it to generate the corresponding target file according to the mapping relationship table in Step 1;

[0017] The specific implementation of Step 2 is as follows:

[0018] Step 2.1, the running end requests the target file corresponding to the missing symbol. After receiving the request, the cloud server retrieves the corresponding intermediate file according to the mapping relationship table;

[0019] Step 2.2, the cloud server uses address-independent compilation to generate the target file from the retrieved intermediate file and sends it to the running end;

[0020] Step 3, the running end receives and loads the target file in Step 2 into the memory, starts the program execution, and sets up a proxy resolution mechanism for undefined symbols;

[0021] The specific implementation of Step 3 is as follows:

[0022] Step 3.1, after receiving the target file, the running end parses and loads it into the memory;

[0023] Step 3.2, symbol table integration: for the defined symbols in the target file, directly integrate them into the global symbol table; for the undefined external symbols, set up a proxy resolution mechanism;

[0024] Step 3.3, start or continue to execute the target file;

[0025] Step 4, trigger dynamic loading based on the proxy resolution mechanism, and the running end parses and executes the undefined symbols;

[0026] The specific implementation of Step 4 is as follows:

[0027] Step 4.1, when an undefined symbol is encountered during the program execution, trigger the proxy parsing mechanism to request the corresponding target file;

[0028] Step 4.2, after the running end receives the target file, repeat the operations in Step 3 and modify the address of the undefined symbol;

[0029] Step 4.3, continue to execute the program. If an undefined symbol is still encountered subsequently, repeat this step until all symbol parsing is completed.

[0030] The specific content of the said Step 1.2 is as follows:

[0031] Step 1.2-1, open and read the Bitcode file, use the llvm::parseBitcodeFile method to parse the read Bitcode file, and convert it into an LLVM Moudle object;

[0032] Step 1.2-2, traverse all functions in the module, check each function, and only record those functions that contain function bodies;

[0033] Step 1.2-3, for each function that contains a function body, extract the name and establish a mapping relationship table between the name and the corresponding Bitcode file path.

[0034] Table 1 Mapping Relationship Table

[0035]

[0036] Preferably, the process of establishing the mapping relationship table in the said Step 1.2-3 is specifically as follows:

[0037] First, traverse all functions in the LLVM module. Each LLVM module object contains multiple functions. Obtain the set of functions through the getFunctionList() method. For each function, determine whether it is valid, that is, whether it is a defined function rather than just a declared function. It can be known whether a function is defined by checking the isDeclaration() method of the Function object. If the return value is false, the function is a valid function;

[0038] After confirming the effectiveness of the function, extract the name of the function and use a container of type std::unordered_map<std::string, std::string> to store the mapping relationship between the function name and the corresponding Bitcode file path. The key of the mapping is the name of the function, and the value is the path of the Bitcode file where the function is located. When storing the mapping relationship, it is necessary to check whether the current function name already exists in the mapping table. If the same name already exists, you can choose to skip it or record a warning; if not, insert the new mapping into the mapping relationship table. By this method, a mapping can be established between each valid function name and its corresponding Bitcode file path, providing a convenient lookup mechanism for subsequent symbol resolution and module loading.

[0039] Preferably, step 2.2 is specifically as follows:

[0040] Step 2.2-1, retrieve through the mapping table, open the Bitcode file at the specified path and parse it into an LLVM Moudle object;

[0041] Step 2.2-2, obtain the default target triple of the target platform, and find the corresponding target machine. Create a target machine according to the target platform and set the position-independent compilation option;

[0042] Step 2.2-3, use the set target machine and compilation options, execute the compilation process and generate the target file, and send the generated target file to the running end.

[0043] Preferably, the target triple, target machine, and position-independent compilation in step 2.2-2 are specifically as follows:

[0044] Target triple: It is an identifier in string format used to describe the hardware architecture, operating system, and its environment of the target platform. It usually consists of three parts: platform architecture, operating system, and execution environment. When LLVM processes code generation, it will determine the appropriate target architecture, operating system, and toolchain according to the target triple for proper code optimization and target-specific generation;

[0045] Target machine: It is the core object used by LLVM to execute code generation. It encapsulates the machine architecture, ABI, and target platform characteristics related to a specific target platform;

[0046] Position-independent compilation: It means that the generated code can be executed at any position in memory without relying on a fixed memory address, allowing the operating system to map it to any memory address when loading the program, independent of the hard-coded addresses in the code.

[0047] Preferably, step 3.2 is specifically as follows:

[0048] Step 3.2-1: Traverse all symbols in the target file, extract symbol information, and distinguish defined symbols from undefined symbols;

[0049] Step 3.2-2: For defined symbols, map the symbol address and symbol name to JITSymbolFlags::Exported, add the defined symbols to the symbol table to ensure that the defined symbols can be used normally;

[0050] Step 3.2-3: Create different trampoline functions to implement the symbol dynamic resolution logic as proxy resolution functions for symbols;

[0051] Step 3.2-4: For undefined symbols, set their respective different proxy resolution functions.

[0052] Preferably, the process of creating different trampoline functions in Step 3.2-3 is specifically as follows:

[0053] Define different trampoline functions for each undefined symbol, where the symbol dynamic resolution logic is implemented. After successfully loading and parsing the corresponding target file through a network request, obtain the correct address of the symbol, and modify the proxy resolution entry address set for the symbol to the correct address. This stub function will be called when an undefined symbol is encountered during execution to implement the filling operation for undefined symbols, ensuring that the symbol can be correctly resolved and loaded into memory during runtime.

[0054] Preferably, Step 4.1 is specifically as follows:

[0055] Step 4.1-1: When the running end encounters an undefined symbol during operation, trigger the stub function, which defines the specific symbol dynamic resolution logic, and use a network request to obtain the target file containing the symbol from the compilation end;

[0056] Step 4.1-2: The compilation end searches for the corresponding intermediate file according to the symbol name, compiles it into a target file, and returns it to the running end.

[0057] Preferably, Step 4.2 is specifically as follows:

[0058] Step 4.2-1: After the target file is received by the running end, repeat the operations in Step 3 to complete the resolution of defined symbols and set the proxy resolution mechanism for undefined symbols;

[0059] Step 4.2-2: The running end modifies the previously set proxy resolution entry of the symbol to point to the correct symbol address.

[0060] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0061] The existing dynamic symbol resolution and loading methods are mainly divided into two categories, namely the runtime symbol resolution method represented by LLVM ORC and the dynamic linking method represented by dlopen() and dlsym(). The present invention is significantly different from the above methods.

[0062] The runtime symbol resolution method only delays symbol resolution to the symbol lookup stage and involves cascaded resolution of dependencies, still having unnecessary pre-resolution overhead. The optimization scheme proposed by the present invention triggers resolution only when the symbol is actually called, avoiding the additional overhead brought by pre-resolution and further enhancing the flexibility and running efficiency of execution.

[0063] Compared with the limitation of the dynamic linking method that the entire shared library needs to be pre-loaded and fine-grained symbol-level dynamic loading cannot be achieved, the method of the present invention performs resolution based on the symbol level. The running end only loads and resolves the symbols actually required by the current execution path, thereby reducing the occupation of storage and computing resources and improving the module loading efficiency, which is applicable to environments with limited computing and storage resources.

[0064] The present invention also combines a cloud collaboration mechanism. When the running end encounters an unresolved symbol, it can dynamically request a remote target file and load it immediately to achieve remote dynamic loading. This method effectively reduces the dependence on local storage, enables the running end to complete symbol resolution and execution with less resource consumption, and at the same time enhances the flexibility and scalability of the system.

[0065] The present invention proposes a dynamic symbol resolution and loading method based on stub functions. By setting a proxy resolution entry at the running end, resolution is triggered only when the symbol is truly called, avoiding the pre-resolution overhead in the LLVM ORC mechanism. Compared with dynamic linking technology, this method achieves finer-grained symbol-level dynamic resolution and reduces the occupation of storage and computing resources. In addition, this method combines a cloud collaboration mechanism, and the running end can dynamically request and load remote target files during execution, eliminating the dependence on local storage, so that symbol resolution and execution can be completed even in resource-constrained environments. Brief Description of the Drawings

[0066] Figure 1 is the flowchart of the compilation end of the dynamic symbol resolution and loading method based on stub functions of the present invention.

[0067] Figure 2 is the schematic diagram of the mapping table construction of the dynamic symbol resolution and loading method based on stub functions of the present invention.

[0068] Figure 3 is the flowchart of the running end of the dynamic symbol resolution and loading method based on stub functions of the present invention.

[0069] Figure 4 It is a schematic diagram of dynamic symbol parsing for the method of dynamic symbol parsing and loading based on stub functions in the present invention.

[0070] Figure 5 It is the overall structure diagram of the method of dynamic symbol parsing and loading based on stub functions in the present invention. Detailed implementation manners

[0071] Next, the technical solutions of the present invention will be further described in detail in conjunction with the accompanying drawings and embodiments.

[0072] The following will disclose multiple embodiments of the present invention in the form of diagrams. For the sake of clarity, many physical details will be described together in the following narrative. However, it should be understood that these physical details are not used to limit the present invention. That is to say, in some embodiments of the present invention, these physical details are unnecessary. In addition, for the purpose of simplifying the diagrams, some conventional structures and components will be shown in a simple schematic manner in the diagrams.

[0073] In addition, the technical solutions between various embodiments can be combined with each other, but it must be based on the premise that those of ordinary skill in the art can implement them. When the combination of technical solutions results in contradictions or cannot be implemented, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection required by the present invention.

[0074] A method of dynamic symbol parsing and loading based on stub functions includes the following steps:

[0075] Step 1, the cloud server pre-compiles the source code file, generates an intermediate file, and establishes a mapping relationship table between function symbols and the intermediate file;

[0076] The specific implementation of the said Step 1 is as follows:

[0077] Step 1.1, the cloud server pre-compiles the source code: the cloud server compiles each.c file in the source code into a.bc file for storage;

[0078] Step 1.2, extract the corresponding relationship between the function symbols contained in the.bc file and the storage address of the file (intermediate file), and establish a mapping relationship table;

[0079] Step 2, the running end requests the executable file containing the target function as needed, and the cloud server retrieves and compiles to generate the corresponding target file according to the mapping relationship table in Step 1;

[0080] The specific implementation of the said Step 2 is as follows:

[0081] Step 2.1, the running end requests the target file corresponding to the missing symbol. After receiving the request, the cloud server retrieves the corresponding intermediate file according to the mapping relation table;

[0082] Step 2.2, the cloud server generates the target file by using address-independent compilation for the retrieved intermediate file and sends it to the running end;

[0083] Step 3, the running end receives and loads the target file of Step 2 into the memory, starts the program execution, and sets up a proxy resolution mechanism for undefined symbols;

[0084] The specific implementation of the said Step 3 is as follows:

[0085] Step 3.1, after receiving the target file, the running end parses and loads it into the memory;

[0086] Step 3.2, symbol table integration: for the defined symbols in the target file, directly integrate them into the global symbol table; for the undefined external symbols, set up a proxy resolution mechanism;

[0087] Step 3.3, start or continue to execute the target file;

[0088] Step 4, trigger dynamic loading based on the proxy resolution mechanism, and the running end parses and executes the undefined symbols;

[0089] The specific implementation of the said Step 4 is as follows:

[0090] Step 4.1, when an undefined symbol is encountered during the program execution, trigger the proxy resolution mechanism and request the corresponding target file;

[0091] Step 4.2, after receiving the target file, the running end repeats the operations in Step 3 and modifies the addresses of the undefined symbols;

[0092] Step 4.3, continue to execute the program. If undefined symbols are still encountered subsequently, repeat this step until all symbols are resolved.

[0093] 2. According to the dynamic symbol resolution and loading method based on stub functions described in Claim 1, it is characterized in that: the specific implementation of the said Step 1.2 is as follows:

[0094] Step 1.2-1, open and read the Bitcode file, use the llvm::parseBitcodeFile method to parse the read Bitcode file, and convert it into an LLVM Moudle object;

[0095] Step 1.2-2, traverse all functions in the module, check each function, and only record those functions that contain function bodies;

[0096] Step 1.2-3: For each function containing a function body, extract the name and establish a mapping table between the name and the corresponding Bitcode file path.

[0097] Table 1 Mapping Table

[0098]

[0099] Preferably, the process of establishing the mapping table in Step 1.2-3 is specifically as follows:

[0100] First, traverse all functions in the LLVM module. Each LLVM module object contains multiple functions. Obtain the set of functions through the getFunctionList() method. For each function, determine whether it is valid, that is, whether it is a defined function rather than just a declared function. It can be known whether the function is defined by checking the isDeclaration() method of the Function object. If the return value is false, the function is a valid function.

[0101] After confirming that the function is valid, extract the name of the function. Use a container of type std::unordered_map<std::string,std::string> to store the mapping between the function name and the corresponding Bitcode file path. The key of the mapping is the name of the function, and the value is the path of the Bitcode file where the function is located. When storing the mapping relationship, it is necessary to check whether the current function name already exists in the mapping table. If the same name already exists, you can choose to skip it or record a warning; if it does not exist, insert the new mapping into the mapping table. Through this method, a mapping can be established between each valid function name and its corresponding Bitcode file path, providing a convenient lookup mechanism for subsequent symbol resolution and module loading.

[0102] Preferably, Step 2.2 is specifically as follows:

[0103] Step 2.2-1: Through the mapping table retrieval, open the Bitcode file at the specified path and parse it into an LLVM Moudle object.

[0104] Step 2.2-2: Obtain the default target triple of the target platform and find the corresponding target machine. Create a target machine according to the target platform and set the position-independent compilation options.

[0105] Step 2.2-3: Use the set target machine and compilation options to execute the compilation process and generate the target file, and send the generated target file to the running end.

[0106] Preferably, the target triple, target machine, and position-independent compilation in step 2.2-2 are specifically as follows:

[0107] Target triple: It is an identifier in string format used to describe the hardware architecture, operating system, and its environment of the target platform. It usually consists of three parts: platform architecture, operating system, and execution environment. When LLVM processes code generation, it determines the appropriate target architecture, operating system, and toolchain based on the target triple for proper code optimization and target-specific generation;

[0108] Target machine: It is the core object used by LLVM to perform code generation. It encapsulates the machine architecture, ABI, and target platform characteristics related to a specific target platform;

[0109] Position-independent compilation: It means that the generated code can be executed at any location in memory without relying on a fixed memory address, allowing the operating system to map it to any memory address when loading the program, which is independent of the hard-coded addresses in the code.

[0110] Preferably, step 3.2 is specifically as follows:

[0111] Step 3.2-1: Traverse all symbols in the target file, extract symbol information, and distinguish defined symbols and undefined symbols;

[0112] Step 3.2-2: For defined symbols, map the symbol address and symbol name to JITSymbolFlags::Exported, and add the defined symbols to the symbol table to ensure that the defined symbols can be used normally;

[0113] Step 3.2-3: Create different trampoline functions to implement the symbol dynamic resolution logic as proxy resolution functions for symbols;

[0114] Step 3.2-4: For undefined symbols, set their respective different proxy resolution functions.

[0115] Preferably, the process of creating different trampoline functions in step 3.2-3 is specifically as follows:

[0116] The proxy resolution mechanism is used to dynamically load unresolved symbols during execution, which usually occurs when the definition of a symbol is not in the current object file but in other object files. To achieve this, different trampoline functions are defined for each undefined symbol, where the dynamic resolution logic of the symbol is implemented. The corresponding object file is obtained through a network request. After successful loading and parsing, the correct address of the symbol is obtained, and the proxy resolution entry address set for the symbol is modified to the correct address. This stub function will be called when an undefined symbol is encountered during execution, implementing the filling operation for the undefined symbol to ensure that the symbol can be correctly resolved and loaded into memory at runtime.

[0117] Preferably, step 4.1 is specifically as follows:

[0118] Step 4.1-1, when the running end encounters an undefined symbol during operation, it triggers the stub function, which defines the specific dynamic resolution logic of the symbol, and uses a network request to obtain the object file containing the symbol from the compilation end;

[0119] Step 4.1-2, the compilation end searches for the corresponding intermediate file according to the symbol name, compiles it into an object file, and returns it to the running end.

[0120] Preferably, step 4.2 is specifically as follows:

[0121] Step 4.2-1, after the object file is received by the running end, repeat the operations in step 3 to complete the resolution of the defined symbols and set the proxy resolution mechanism for the undefined symbols;

[0122] Step 4.2-2, the running end modifies the previously set proxy resolution entry of the symbol to make it point to the correct symbol address.

[0123] As Figures 1-5 shown, to verify the effectiveness of the dynamic symbol resolution and loading method based on the stub function proposed by the present invention, in this embodiment, the compilation end is first built and the initialization operation is completed, and a relationship mapping table between the target symbols and the corresponding object files is established. Then, the running end is built, the symbols are processed to achieve the direct loading of the defined symbols, and the undefined symbols are processed through the proxy resolution mechanism. In addition, the running end also supports cloud-end on-demand interaction, and can dynamically request and load the missing object files according to the requirements. Finally, the dynamic loading of the program is achieved through this process.

[0124] 1) Building of the compilation end

[0125] Figure 1 Shows the complete flowchart of the compilation end. According to the descriptions of step 1.1 and step 1.2, the compilation end mainly performs two important operations, namely initialization and establishment of the relationship mapping table. Figure 2Shows the complete process of building a relationship mapping table at the compilation end.

[0126] Initialization operation: When starting up, the compilation end first initializes the relevant compilation environment, including setting the target platform information, obtaining the target triple, creating the target machine, etc. This operation ensures that subsequent target file generation and symbol resolution can be carried out in the correct environment.

[0127] Establishment of the relationship mapping table: The compilation end analyzes all symbols in the program, extracts each symbol and its corresponding target file, and establishes a mapping relationship table between the symbols and the target files. This mapping table can help the running end quickly find and load the corresponding target file according to the symbol name.

[0128] 2) Setup of the running end

[0129] Figure 3 Shows the complete flowchart of the running end. According to the descriptions in Step 3 and Step 4, the running end mainly performs two important operations, namely symbol management and processing, and cloud-end on-demand interaction. Figure 4 Shows the complete process of symbol management and processing at the running end.

[0130] Symbol management and processing: The running end first scans the program to be executed and checks the symbols used therein. Depending on whether the symbol is defined or not, it is divided into two processing processes:

[0131] ① Direct loading of defined symbols: For defined symbols, the running end directly loads the corresponding target file and performs symbol resolution. This part of the symbols does not require additional dynamic resolution.

[0132] ② Delayed resolution of undefined symbols: When an undefined symbol is encountered, the running end triggers a symbol stub function. At this time, the running end requests the relevant target file from the cloud through the cloud-end interaction module and performs symbol resolution.

[0133] Cloud-end on-demand interaction: The running end can dynamically request missing target files as needed and obtain the target files through the compilation service of the cloud. After receiving the target files, the running end will resolve and load the relevant symbols to ensure the smooth execution of the program.

[0134] Figure 5 Shows the overall structure diagram of the dynamic symbol resolution and loading method based on the stub function, and overall introduces the interaction process between the compilation end and the running end and the operations performed by each.

[0135] The above are only embodiments of the present invention and are not intended to limit the present invention. For those skilled in the art, the present invention can have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included within the scope of the claims of the present invention.

Claims

1. A dynamic symbol parsing and loading method based on a stub function, characterized in that, It includes the following steps: Step 1, the cloud server pre-compiles the source code file to generate an intermediate file and establishes a mapping relationship table between function symbols and the intermediate file; The specific approach of the said Step 1 is: Step 1.1, the cloud server pre-compiles the source code: the cloud server compiles each.c file in the source code into a.bc file for storage; Step 1.2, extract the corresponding relationship between the function symbols and the intermediate file storage address included in the.bc file and establish a mapping relationship table; Step 2, the running end requests the executable file containing the target function as needed, and the cloud server retrieves and compiles to generate the corresponding target file according to the mapping relationship table in Step 1; The specific approach of the said Step 2 is: Step 2.1, the running end requests the target file corresponding to the missing symbol. After the cloud server receives the request, it retrieves the corresponding intermediate file according to the mapping relationship table; Step 2.2, the cloud server uses address-independent compilation to generate a target file from the retrieved intermediate file and sends it to the running end; Step 3, the running end receives and loads the target file in Step 2 into memory, starts the program execution, and sets up a proxy resolution mechanism for undefined symbols; The specific approach of the said Step 3 is: Step 3.1, after the running end receives the target file, it parses and loads it into memory; Step 3.2, symbol table integration: for the symbols defined in the target file, directly integrate them into the global symbol table; for the undefined external symbols, set up a proxy resolution mechanism; Step 3.3, start or continue to execute the target file; Step 4, trigger dynamic loading based on the proxy resolution mechanism, and the running end parses and executes the undefined symbols; The specific approach of the said Step 4 is: Step 4.1, when an undefined symbol is encountered during the program execution, trigger the proxy resolution mechanism and request the corresponding target file; Step 4.2, after the running end receives the target file, repeat the operations in Step 3 and modify the address of the undefined symbol; Step 4.3, continue to execute the program. If an undefined symbol is still encountered later, repeat this step until all symbols are resolved.

2. The dynamic symbol parsing and loading method based on a pile function according to claim 1, characterized in that: The said Step 1.2 is specifically: Step 1.2-1, open and read the Bitcode file, use the llvm::parseBitcodeFile method to parse the read Bitcode file, and convert it into an LLVM Moudle object; Step 1.2-2, traverse all functions in the module, check each function, and only record those functions that contain function bodies; Step 1.2-3, for each function that contains a function body, extract the name and establish a mapping relationship table between the name and the corresponding Bitcode file path.

3. A dynamic symbol parsing and loading method based on a pile function according to claim 1, characterized in that: The said Step 2.2 is specifically: Step 2.2-1, through the mapping table retrieval, open the Bitcode file at the specified path and parse it into an LLVM Moudle object; Step 2.2-2, obtain the default target triple of the target platform, find the corresponding target machine, create a target machine according to the target platform, and set the address-independent compilation option; Step 2.2-3: Use the configured target machine and compilation options to execute the compilation process and generate the target file, and send the generated target file to the running end.

4. A dynamic symbol parsing and loading method based on a pile function according to claim 1, characterized in that: The specific content of Step 3.2 is as follows: Step 3.2-1: Traverse all symbols in the target file, extract symbol information, and distinguish defined symbols from undefined symbols; Step 3.2-2: For defined symbols, map the symbol address and symbol name to JITSymbolFlags::Exported, and add the defined symbols to the symbol table to ensure that the defined symbols can be used normally; Step 3.2-3: Create different trampoline functions to implement the symbol dynamic resolution logic as the proxy resolution function for the symbols; Step 3.2-4: For undefined symbols, set their respective proxy resolution functions.

5. A dynamic symbol parsing and loading method based on a pile function according to claim 1, characterized in that The specific content of Step 4.1 is as follows: Step 4.1-1: When the running end encounters an undefined symbol during operation, it triggers a stub function that defines the specific symbol dynamic resolution logic, and uses a network request to obtain the target file containing the symbol from the compilation end; Step 4.1-2: The compilation end searches for the corresponding intermediate file according to the symbol name, compiles it into a target file, and returns it to the running end.

6. A dynamic symbol parsing and loading method based on a pile function according to claim 1, characterized in that The specific content of Step 4.2 is as follows: Step 4.2-1: After the target file is received by the running end, repeat the operations in Step 3 to complete the resolution of defined symbols and set the proxy resolution mechanism for undefined symbols; Step 4.2-2: The running end modifies the previously set proxy resolution entry of the symbol to make it point to the correct symbol address.

7. A dynamic symbol parsing and loading method based on a pile function according to claim 2, characterized in that, The process of establishing the mapping relationship table in Step 1.2-3 is specifically as follows: First, traverse all functions in the LLVM module. Each LLVM module object contains multiple functions. Obtain the set of functions through the getFunctionList() method. For each function, determine whether it is valid, that is, whether it is a defined function rather than just a declared function. It can be known whether the function is defined by checking the isDeclaration() method of the Function object. If the return value is false, the function is a valid function; After confirming that the function is valid, extract the name of the function. Use a container of type std::unordered_map<std::string,std::string> to store the mapping relationship between the function name and the corresponding Bitcode file path. The key of the mapping is the function name, and the value is the path of the Bitcode file where the function is located. When storing the mapping relationship, it is necessary to check whether the current function name already exists in the mapping table. If the same name already exists, you can choose to skip it or record a warning; if not, insert the new mapping into the mapping relationship table. Through this method, the mapping between each valid function name and its corresponding Bitcode file path can be established, providing a convenient search mechanism for subsequent symbol resolution and module loading.

8. A dynamic symbol parsing and loading method based on a pile function according to claim 3, characterized in that The target triple, target machine, and position-independent compilation in Step 2.2-2 are specifically as follows: Target triple: It is an identifier in string format used to describe the hardware architecture, operating system, and its environment of the target platform. It usually consists of three parts: platform architecture, operating system, and execution environment. When LLVM processes code generation, it determines the appropriate target architecture, operating system, and toolchain based on the target triple for proper code optimization and target-specific generation; Target machine: It is the core object used by LLVM for code generation. It encapsulates the machine architecture, ABI, and target platform characteristics related to a specific target platform; Position-independent compilation: It means that the generated code can be executed at any location in memory without relying on a fixed memory address, allowing the operating system to map it to any memory address when loading the program, independent of the hard-coded addresses in the code.

9. A dynamic symbol parsing and loading method based on a pile function according to claim 4, characterized in that The process of creating different trampoline functions in step 3.2 - 3 is specifically as follows: Define different trampoline functions for each undefined symbol, where the symbol dynamic resolution logic is implemented. After obtaining the corresponding target file through a network request, successfully loading and parsing it, the correct address of the symbol is obtained, and the proxy resolution entry address set by the symbol is modified to the correct address. This stub function will be called when an undefined symbol is encountered during execution to implement the filling operation for undefined symbols, ensuring that the symbol can be correctly resolved and loaded into memory during runtime.

Images