Dynamic library loading method and device, equipment and storage medium

Abstract

This application discloses a method, apparatus, device, and storage medium for loading a dynamic library, belonging to the field of computer programs. The method includes: generating assembly language intermediate-level code corresponding to a first function in the dynamic library based on the interface signature of the first function; compiling and linking the source code, linking the calls to the first function in the source code to the assembly language intermediate-level code, obtaining an executable file of the source code; executing the assembly language intermediate-level code when the executable file calls the first function; the assembly language intermediate-level code is used to dynamically load the dynamic library and execute the first function; wherein, the assembly language intermediate-level code is used to cache the parameter context of the function call before dynamically loading the dynamic library and restore the parameter context before executing the first function. This method can improve the generation efficiency of intermediate-level code and reduce the maintenance cost of intermediate-level code.

Description

Technical Field

[0001] This application relates to the field of computer programs, and in particular to a method, apparatus, device, and storage medium for loading dynamic libraries. Background Technology

[0002] Dynamic libraries, as a core component of software engineering, have become a standard technique for code reuse, module decoupling, and incremental updates. Dynamic libraries allow programs to load the necessary library code into memory at runtime, enabling functional expansion, reducing application startup size, and optimizing memory usage. To further improve startup performance and resource utilization efficiency, lazy loading technology has emerged. Lazy loading delays the loading of dynamic libraries or specific functions within them until their first invocation, rather than completing the entire loading process at program startup.

[0003] To implement lazy loading of dynamic libraries in a C / C++ environment, intermediate code is introduced. During the compilation phase, direct calls to dynamic library functions in the source code are linked to a hand-written C / C++ intermediate function. When this intermediate function is first called at runtime, it dynamically loads the dynamic library, obtains the address of the actual function, and then forwards the call. In this way, the direct dependency on the dynamic library during compilation is eliminated, achieving the goal of lazy loading.

[0004] However, because the C / C++ language itself cannot directly manipulate the underlying function call mechanism, each function requiring lazy loading must correspond to an independent intermediate function. This intermediate function must fully declare and maintain a parameter list identical to the original function. When dynamic library updates cause changes to the interface signature of a function (such as parameter types, order, or number), developers must manually locate and modify the corresponding intermediate code. This modification process is not only tedious and error-prone, but also results in high maintenance costs. Summary of the Invention

[0005] This application provides a method, apparatus, device, and storage medium for loading dynamic libraries, which can improve the generation efficiency of intermediate layer code and reduce the maintenance cost of intermediate layer code. The technical solution is as follows: According to one aspect of this application, a method for loading a dynamic library is provided, the method comprising: Based on the interface signature of the first function in the dynamic library, generate the assembly language intermediate layer code corresponding to the first function; The source code is compiled and linked, and the calls to the first function in the source code are linked to the assembly language intermediate layer code to obtain the executable file of the source code; When the executable file calls the first function, the assembly language intermediate layer code is executed; the assembly language intermediate layer code is used to dynamically load the dynamic library and execute the first function. The assembly language intermediate layer code is used to cache the parameter context of function calls before dynamically loading the dynamic library, and to restore the parameter context before executing the first function.

[0006] According to another aspect of this application, a dynamic library loading device is provided, the device comprising: The generation module is used to generate the assembly language intermediate layer code corresponding to the first function based on the interface signature of the first function in the dynamic library. The compilation module is used to compile and link the source code, linking the calls to the first function in the source code to the assembly language intermediate layer code, so as to obtain the executable file of the source code; The runtime module is used to execute the assembly language intermediate layer code when the executable file calls the first function; the assembly language intermediate layer code is used to dynamically load the dynamic library and execute the first function. The assembly language intermediate layer code is used to cache the parameter context of function calls before dynamically loading the dynamic library, and to restore the parameter context before executing the first function.

[0007] According to another aspect of this application, a computer device is provided, the computer device including a processor and a memory, the memory storing at least one instruction, at least one program, code set or instruction set, the at least one instruction, the at least one program, the code set or instruction set being loaded and executed by the processor to implement the dynamic library loading method as described above.

[0008] According to another aspect of this application, a computer-readable storage medium is provided, wherein at least one instruction, at least one program, code set, or instruction set is stored therein, wherein the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by a processor to implement the dynamic library loading method described above.

[0009] According to another aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the dynamic library loading method provided in various alternative implementations of the above aspects.

[0010] The beneficial effects of the technical solution provided in this application include at least the following: No manual writing or maintenance of intermediate layer code is required; assembly language intermediate layer code is automatically generated based on the interface signature. Since assembly language can directly manipulate the processor's registers and stack memory, the generated intermediate layer code is universal and does not require declaration or maintenance of function parameter lists. When parameter context caching is needed, the assembly language intermediate layer code only needs to follow the fixed calling conventions of the CPU (Central Processing Unit) architecture, reading and saving the parameter context from the agreed register set (e.g., X0-X7) and / or the agreed location on the call stack; during execution recovery, the parameter context is written back to its original location in the same way. The assembly language intermediate layer code can operate directly at the binary interface level agreed upon by the underlying hardware, free from the semantic constraints of high-level languages ​​(e.g., C). When the processor makes a function call, the function call parameters are passed through a fixed set of registers (e.g., X0 in the ARM64 architecture). The parameters (X7) are passed along with specific offsets in the stack memory, and the calling rules are predetermined by the hardware architecture. Therefore, the assembly language intermediate layer code does not need to know the number, type, or name of the parameters (i.e., the parameter list). It only needs to read all existing data from the corresponding register set and stack offset as a parameter context for caching according to the calling convention specified by the hardware, and write the cached data back to its original location according to the same rules before calling the actual function. This method relies only on physical location rather than the parameter list, allowing the same intermediate layer code logic to be applied to functions with arbitrarily different signatures, thus eliminating the arduous work of manually adapting and maintaining parameter lists for each function. This allows the same set of intermediate layer code logic to adapt to a massive number of functions with different interface signatures. When the interface of a function in the dynamic library changes, only the generation step needs to be run again according to the new interface signature to obtain the new assembly language intermediate layer code. This eliminates the arduous maintenance work of locating, modifying, and verifying parameters due to changes in the parameter list, achieving efficient lazy loading while reducing development and maintenance costs. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram of the structure of a computer system provided in an exemplary embodiment of this application; Figure 2 This is a flowchart of a dynamic library loading method provided in an exemplary embodiment of this application; Figure 3This is a flowchart of a dynamic library loading method provided in an exemplary embodiment of this application; Figure 4 This is a schematic diagram of a dynamic library loading method provided in an exemplary embodiment of this application; Figure 5 This is a schematic diagram of a dynamic library loading method provided in an exemplary embodiment of this application; Figure 6 This is a schematic diagram of a dynamic library loading method provided in an exemplary embodiment of this application; Figure 7 This is a schematic diagram of a dynamic library loading method provided in an exemplary embodiment of this application; Figure 8 This is a schematic diagram of the structure of a dynamic library loading device provided in an exemplary embodiment of this application; Figure 9 This is a schematic diagram of the structure of a computer device provided in an exemplary embodiment of this application.

[0013] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0015] First, a brief introduction to the terms used in the embodiments of this application will be given.

[0016] A dynamic library is a codebase that is loaded into memory only at runtime. Dynamic libraries allow multiple programs to share the same library code. On Windows, they are typically .dll (Dynamic Link Library) files, while on Linux / macOS they are .so (Shared Object) and .dylib (Dynamic Library) files, respectively. Unlike static libraries, updating a dynamic library does not require recompiling the main program.

[0017] Lazy loading is an optimization technique that postpones the loading of resources (such as dynamic libraries, images, and functions) until they are first needed, rather than loading them all at program startup. This helps reduce program startup time and initial memory usage.

[0018] Linker: A tool used in the source code compilation process. It is responsible for merging multiple object files generated by compilation and the required library files (such as dynamic libraries), resolving the mutual references between them, and finally generating an executable file or another library file.

[0019] Symbol resolution is a core step in the linking process. It refers to the process by which the linker matches and binds the symbols (such as function names and variable names) referenced in the program with their actual memory addresses defined in the library or object file.

[0020] Dynamic linking is a linking method where the program links with dynamic libraries at runtime (rather than compile time). Dynamic linking allows libraries to be updated independently after the program is released, but it also requires that the corresponding dynamic libraries exist in the system at runtime.

[0021] Lazy binding is an optimization technique in dynamic linking. It delays the symbolic resolution of function addresses in a dynamic library until the function is first actually called by the program, rather than resolving all function addresses when the dynamic library is loaded at program startup, thus further speeding up startup.

[0022] Dynamic loading refers to the process by which a program explicitly loads a dynamic library into memory during runtime using specific APIs (such as dlopen or LoadLibrary) and obtains pointers to its internal functions. Dynamic loading provides more flexible library management capabilities than regular dynamic linking.

[0023] An interface is a set of functions, methods, or services that a library exposes to the outside world. It defines how external code interacts with the library and serves as the entry point for accessing the library's functionality.

[0024] An interface signature is a precise description of an interface (especially a function), typically including the function name, the number of parameters, the types and order of the parameters, and the type of the return value. The interface signature fully defines the format required to call the function.

[0025] Mach-O is an executable file format used on macOS and iOS operating systems, including executable files, object code, dynamic libraries, etc. Mach-O is equivalent to the PE format on Windows and the ELF format on Linux.

[0026] Intermediate layer code: This refers to a layer of code inserted between the calling code (e.g., source code) and the actual dynamic library function. Intermediate layer code is responsible for intercepting calls, managing the loading timing of the dynamic library, and transparently forwarding calls; it is the vehicle for implementing lazy loading.

[0027] Figure 1 A schematic diagram of a computer device provided in an exemplary embodiment of this application is shown. The dynamic library loading method shown in the embodiment of this application can be applied to a computer device 101.

[0028] For example, the dynamic library loading method shown in this application embodiment can be applied to a computer device 101 running a dynamic library loader 102. The computer device may include a terminal or a server. For example, the terminal may be a mobile phone, tablet computer, laptop computer, desktop computer, all-in-one computer, IoT device, smart robot workstation, television, set-top box, smart glasses, smartwatch, digital camera, MP4 playback device, MP5 playback device, learning machine, e-reader, e-book reader, electronic dictionary, in-vehicle device, virtual reality (VR) playback device, or augmented reality (AR) playback device, etc. The server may be a single server, a server cluster consisting of multiple servers, or a cloud computing service center.

[0029] Computer device 101 includes a first memory and a first processor. The first memory stores a loader for a dynamic library; the loader for the dynamic library is invoked and executed by the first processor to implement the dynamic library loading method provided in this application. The first memory may include, but is not limited to, the following: Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), and Electrically Erasable Programmable Read-Only Memory (EEPROM).

[0030] The first processor can consist of one or more integrated circuit chips. Optionally, the first processor can be a general-purpose processor, such as a central processing unit (CPU) or a network processor (NP). Optionally, the first processor can implement the dynamic library loading method provided in this application by running programs or code.

[0031] Figure 2 This is a flowchart illustrating a dynamic library loading method provided in an exemplary embodiment of this application. This method can be used for, for example... Figure 1 The computer device shown. The method includes the following steps.

[0032] Step 210: Generate the assembly language intermediate layer code corresponding to the first function based on the interface signature of the first function in the dynamic library.

[0033] A dynamic library is a shared code library that is loaded into memory only at runtime. A dynamic library provides at least one function; this embodiment uses only the first function as an example. When other functions in the dynamic library are called, the loading and function calls of the dynamic library can also be implemented using the method provided in this embodiment.

[0034] Dynamic libraries can be shared by multiple programs; for example, both the first source code and the second source code can call the first function in the first dynamic library. It's important to note that if the functions in the dynamic library remain unchanged, the assembly language intermediate code only needs to be generated once and does not need to be regenerated before each source code compilation. For example, using the method in step 210 to generate assembly language intermediate code for the functions in the first dynamic library, we obtain the first assembly language intermediate code file for the first dynamic library; then, when the first source code and the second source code are compiled, the first assembly language intermediate code file can be directly applied. If the functions in the dynamic library are modified, the assembly language intermediate code for that function needs to be regenerated.

[0035] Step 210 can also be implemented as follows: based on the interface signatures corresponding to at least one function in the dynamic library, generate assembly language intermediate layer code corresponding to at least one function, and obtain the assembly language intermediate layer code file of the dynamic library; at least one function includes the first function.

[0036] If at least one function in the dynamic library is modified (i.e., the function's interface signature is changed), the assembly language intermediate code corresponding to at least one function is regenerated based on the interface signature of each function in the dynamic library, thus obtaining the assembly language intermediate code file of the dynamic library.

[0037] In this way, a corresponding assembly language intermediate code file can be generated for each dynamic library. For example, a first assembly language intermediate code file is generated for the first dynamic library, and a second assembly language intermediate code file is generated for the second dynamic library. When the source code calls a function in the first dynamic library, it can be compiled and linked using the first assembly language intermediate code file; when the source code calls a function in both the first and second dynamic libraries, it can be compiled and linked using both the first and second assembly language intermediate code files.

[0038] The first function can refer to any function in a dynamic library. For example, a dynamic library named DemoFramework.framework might contain a function for audio processing: voidAudioProcessor::encode(const char data, int length, int quality).

[0039] The interface signature of the first function is a specification description exposed to the outside world, defining how to call the first function. The interface signature includes at least one of the following: the function's symbolic name (including name decoration), the number of parameters, the order and data types of the parameters, and the function's return type. For example, for the AudioProcessor::encode function mentioned above, its interface signature can be described as: symbolic name _ZN15AudioProcessor6encodeEPKcii, containing three parameters of type const char. , int, int, with a return type of void.

[0040] Assembly language intermediate code refers to a layer of forwarding code written in assembly language that sits between the caller's source code and the actual functions of the dynamic library. Because assembly language directly addresses processor hardware, it can bypass the abstraction limitations of high-level languages ​​and directly read, save, and restore operations on the CPU's general-purpose registers, floating-point / vector registers, and stack memory. At runtime, the assembly language intermediate code intercepts calls to the first function, temporarily stores all call parameter contexts, triggers the loading of the dynamic library and function address resolution as needed, and finally restores the context and transparently jumps to the execution of the first function.

[0041] For example, a simplified ARM64 architecture assembly language intermediate layer code corresponding to the AudioProcessor::encode function could be: .global _ZN15AudioProcessor6encodeEPKcii _ZN15AudioProcessor6encodeEPKcii: / / 1. Save the current state (FP, LR) stp x29, x30, [sp, #-16]! mov x29, sp / / 2. Check if the function address is already bound. adrp x8, _lazy_ptr_ZN15AudioProcessor6encodeEPKcii@PAGE ldr x8, [x8, _lazy_ptr_ZN15AudioProcessor6encodeEPKcii@PAGEOFF] cbz x8, _load_and_bind / / 3. Cache parameters (x0, x1, x2 registers) stp x0, x1, [sp, #-16]! str x2, [sp, #-8] / / 4. Restore parameters ldr x2, [sp, #8] ldp x0, x1, [sp], #16 / / 5. Jump to the actual function br x8 _load_and_bind: / / Dynamic loading and binding logic... For example, the assembly language intermediate layer code is generated based on the interface signature of a function (e.g., the first function) and a generic template.

[0042] A general template is a set of instruction frameworks that are strongly related to the hardware architecture and cover the complete lazy loading process. A general template may include at least one of the following: framework source information and entry point declaration code, stack frame management code, function memory address binding status check and jump code, parameter context management code, and dynamic loading and calling code.

[0043] The framework source information and entry declaration code include: definition code segment, alignment instructions, declaration of global function symbols (placeholders are used to replace the symbol names corresponding to the first function signature) and function entry labels, and includes debugging information instructions.

[0044] Stack frame management code is used to create and establish stack frames for assembly language intermediate layer code, allocate local storage areas within the stack frame, save data in registers as needed, and, after a function call returns, deallocate the allocated storage areas, restore the frame pointer and return address, and finally return to the caller.

[0045] The dynamic address binding status check and jump code is used to read the pointer variable that stores the memory address of the first function. If the pointer variable is 0, the lazy loading process is triggered; if it is not 0, the function call process is triggered.

[0046] The parameter context management code saves the parameter context, which follows specific hardware calling conventions and is passed by the caller during a function call, before the dynamic library is loaded. It then restores this parameter context to its original passing location before the first function is actually called. Optionally, the parameter context management code employs two strategies depending on whether the number of parameters exceeds the threshold for direct register passing: for a small number of parameters, it pushes the parameter context from the registers onto the stack frame of the assembly language intermediate code using a preset instruction sequence, and then pops it back in reverse order; for a large number of parameters, in addition to saving the parameter context from the registers, it must also handle the parameter context passed through the caller's stack frame, copying it to its own stack frame. Finally, before the call, it must not only restore the register parameters but also reposition the parameters on the stack back to their correct positions in the reconstructed caller's stack frame. This process involves binary data movement based on hardware rules, without relying on or parsing any high-level language-level parameter type information, thus achieving universal and transparent parameter forwarding for functions with any interface signature.

[0047] Dynamic loading of calling code is used to load dynamic libraries, perform symbol resolution, and bind memory addresses when the memory address of the first function is not bound.

[0048] The process of generating intermediate layer code in assembly language can be as follows: First, parse the interface signature of the first function (to determine the calling convention and the number of parameters). Then, according to the calling convention (e.g., ARM64's AAPCS specifies that the first 8 integer parameters are X0-X7 and floating-point parameters are Q0-Q7), accurately calculate the list of registers to be operated on and their push / pop order, and instantiate the operation instructions into the corresponding registers in the template, saving and restoring the reserved bits. At the same time, replace the symbol placeholders (such as function names and pointer names) in the general template according to the symbol names in the interface signature.

[0049] For example, the first function void AudioProcessor::encode(const char The interface signature can include the following information: (data, int length, int quality). Mangled Symbol Name: _ZN15AudioProcessor6encodeEPKcii Calling Convention: ARM64 AAPCS (Procedure Call Standard for the ARM 64-bit Architecture) Parameter Info: Number of parameters: 3 Parameter types and passing methods: const char (Pointer) -> Passed via general-purpose register X0 int (32-bit integer, expanded to 64 bits in 64-bit calls) -> passed via general-purpose register X1 int (same as above) -> passed via general-purpose register X2 Return type: void (no return value) General templates may include: .global {MANGLED_SYMBOL_NAME} {MANGLED_SYMBOL_NAME}: / / Function Prologue: Saves the current state of the function. stp x29, x30, [sp, #-16]! / / Save FP and LR mov x29, sp / / Set the new frame pointer / / Address binding status check adrp x8, {LAZY_PTR_SYMBOL}@PAGE ldr x8, [x8, {LAZY_PTR_SYMBOL}@PAGEOFF] cbz x8, {LOAD_AND_BIND_LABEL} / / If the pointer is 0, jump to the loading logic / / Parameter cache instruction area (filled in according to signature) {PARAMETER_SAVE_INSTRUCTIONS} / / Parameter restoration instruction area (filled in according to signature, in reverse order) {PARAMETER_RESTORE_INSTRUCTIONS} / / Jump to the actual function br x8 {LOAD_AND_BIND_LABEL}: / / Dynamically load and call code / / Prepare parameters and call the loader (library name, symbol name, etc. need to be filled in) / / ... loader call logic... / / After loading is complete, you should be redirected back to the address after the cache / restore parameters, or the check process should be re-executed. Based on the above interface signature and general template, perform the following fill operation: 1) Replace {MANGLED_SYMBOL_NAME} with _ZN15AudioProcessor6encodeEPKcii.

[0050] 2) Generate and populate {LAZY_PTR_SYMBOL} as _lazy_ptr_ZN15AudioProcessor6encodeEPKcii according to the rules.

[0051] 3) Fill {LOAD_AND_BIND_LABEL} with a local tag, such as L_load_bind.

[0052] 4) Generate and populate parameter context management instructions: The signature analysis revealed that there are three integer / pointer parameters, using registers X0, X1, and X2.

[0053] Generate {PARAMETER_SAVE_INSTRUCTIONS}: The tool calculates the stack offset and generates the corresponding save instruction. It might generate: stp x0, x1, [sp, #-16]! / / Save X0, X1; then generate: str x2, [sp, #-8] / / Save X2.

[0054] Generate {PARAMETER_RESTORE_INSTRUCTIONS}: The tool generates the reversed restore instructions. First, it generates: ldr x2, [sp, #8] / / Restore X2; then it generates: ldp x0, x1, [sp], #16 / / Restore X0, X1 and adjust SP.

[0055] After filling in the information, the final assembly language intermediate layer code will be: .global _ZN15AudioProcessor6encodeEPKcii _ZN15AudioProcessor6encodeEPKcii: / / Function Preface stp x29, x30, [sp, #-16]! mov x29, sp / / Address binding status check adrp x8, _lazy_ptr_ZN15AudioProcessor6encodeEPKcii@PAGE ldr x8, [x8, _lazy_ptr_ZN15AudioProcessor6encodeEPKcii@PAGEOFF] cbz x8, L_load_bind / / Parameter cache instruction area (already filled in according to signature) stp x0, x1, [sp, #-16]! str x2, [sp, #-8] / / Parameter restoration command area (already filled in according to signature) ldr x2, [sp, #8] ldp x0, x1, [sp], #16 / / Jump to the actual function br x8 L_load_bind: / / Dynamically load calling code Step 220: Compile and link the source code, linking the calls to the first function in the source code to the assembly language intermediate layer code to obtain the executable file of the source code.

[0056] Source code refers to a collection of text files written in a high-level programming language (such as C, C++, Objective-C, Swift, etc.) that define program logic and functionality. Source code can include, but is not limited to, the following file types: C language source files (.c files) for implementing basic functions, C++ source files (.cpp or .cc files) for implementing object-oriented or complex logic, Objective-C source files (.m files) for macOS / iOS platform-specific development, and Swift source files (.swift files) for Apple ecosystem development. Source code files contain call statements to the first function in a dynamic library; these calls are redirected during the compilation and linking phase to the intermediate assembly language code generated for the first function.

[0057] Compilation and linking is the process of converting source code into an executable file that a computer can directly execute. It includes both the compilation and linking processes. The compiler independently translates source code files (such as .c and .cpp files) into object files (.o files) containing machine instructions and symbol tables. The linker takes all the compiled object files and required library files (static libraries or assembly language intermediate code files) as input, performs symbol resolution to find the actual definition locations of all undefined symbols (such as the first function), performs address relocation, corrects all references to the correct memory addresses, and finally generates the executable file.

[0058] In other words, compilation is the process of translating human-readable high-level language source code (such as C / C++ files) into computer-executable low-level machine code (i.e., object files). During this process, the compiler performs a series of operations on the source code, including lexical analysis, syntax analysis, semantic checking, and optimization, ultimately generating an object file containing machine instructions, data, and a symbol table (recording function names, variable names, etc.). For example, the compiler might compile a call to the first function in the source code into a jump instruction to a specific symbol, but at this point, the specific address of that symbol is not yet determined.

[0059] The linking process is the next stage after compilation. The linker's task is to combine multiple independently compiled object files and necessary library files into a complete executable file. The linker performs two tasks: first, symbol resolution, which finds the specific addresses of all undefined symbols in the object files (such as calls to the first function) in the object file or library where they are defined; second, relocation, which modifies all references to that symbol in the object files based on the resolved addresses, making them point to the correct memory locations.

[0060] For example, in step 220, the linker no longer directly resolves and links calls to the first function in the source code to the original function address in the dynamic library. Instead, the linker is directed to the assembly language intermediate code file. The linker treats the assembly language intermediate code as the definition of the first function and performs symbol resolution, thereby relocating the call points in the source code to the entry address of the assembly language intermediate code. In the final executable file, all calls to the first function point to the corresponding assembly language intermediate code, rather than the original dynamic library, so that the program does not need to bind to the original dynamic library at startup, laying the foundation for lazy loading at runtime.

[0061] During the linking process, calls to the first function in the source code are linked to the assembly language intermediate code. For example, a pre-generated assembly language intermediate code file for the first function is added as one of the linker's input files, participating in the linking process along with the object file (.o file) compiled from the source code. When processing the symbol table, the linker finds a global definition of the first function symbol in the assembly language intermediate code file, resolves that symbol to an address pointing to the entry point of the assembly language intermediate code, and performs corresponding address relocation on all call references to that symbol in the source code object file. Ultimately, all call instructions to the first function in the generated executable file have jump target addresses pointing to the corresponding assembly language intermediate code, rather than the first function in the original dynamic library, thus completing the interception and forwarding of the call.

[0062] Step 230: When the executable file calls the first function, the assembly language intermediate layer code is executed; the assembly language intermediate layer code is used to dynamically load the dynamic library and execute the first function.

[0063] The assembly language intermediate layer code is used to cache the parameter context of function calls before dynamically loading dynamic libraries and restore the parameter context before executing the first function.

[0064] When the program execution flow reaches a function call point linked to the assembly language intermediate code, the CPU will jump directly to and begin executing the assembly language intermediate code. The assembly language intermediate code first establishes its own stack frame, then checks the pointer variable specifically used to store the actual memory address of the first function. If this pointer variable is null or 0 (indicating it is not bound), the code safely caches all current call parameters into its own stack frame, then calls the runtime loading function. This function receives the dynamic library name and function symbol name as parameters, loads the dynamic library into memory, obtains the memory address of the first function, and fills it back into the pointer variable. Afterward, the assembly language intermediate code precisely restores the previously cached parameters and finally jumps to the newly obtained actual function address through this pointer. If the pointer already contains a valid memory address, the loading step is skipped, and parameter restoration and jump are performed directly.

[0065] In summary, the method provided in this embodiment eliminates the need for manual writing and maintenance of intermediate layer code, automatically generating assembly language intermediate layer code based on the interface signature. Since assembly language can directly manipulate the processor's registers and stack memory, the generated intermediate layer code is universal and does not require declaration or maintenance of function parameter lists. When parameter context caching is required, the assembly language intermediate layer code only needs to follow the fixed calling conventions of the CPU (Central Processing Unit) architecture, reading and saving the parameter context from the agreed register set (e.g., X0-X7) and / or the agreed location on the call stack; during execution recovery, the parameter context is written back to its original location in the same way. The assembly language intermediate layer code can operate directly at the binary interface level agreed upon by the underlying hardware, free from the semantic constraints of high-level languages ​​(e.g., C). When the processor makes a function call, the function call parameters are passed through a fixed set of registers (e.g., X0 in the ARM64 architecture). The parameters (X7) are passed along with specific offsets in the stack memory, and the calling rules are predetermined by the hardware architecture. Therefore, the assembly language intermediate layer code does not need to know the number, type, or name of the parameters (i.e., the parameter list). It only needs to read all existing data from the corresponding register set and stack offset as a parameter context for caching according to the calling convention specified by the hardware, and write the cached data back to its original location according to the same rules before calling the actual function. This method relies only on physical location rather than the parameter list, allowing the same intermediate layer code logic to be applied to functions with arbitrarily different signatures, thus eliminating the arduous work of manually adapting and maintaining parameter lists for each function. This allows the same set of intermediate layer code logic to adapt to a massive number of functions with different interface signatures. When the interface of a function in the dynamic library changes, only the generation step needs to be run again according to the new interface signature to obtain the new assembly language intermediate layer code. This eliminates the arduous maintenance work of locating, modifying, and verifying parameters due to changes in the parameter list, achieving efficient lazy loading while reducing development and maintenance costs.

[0066] For example, an embodiment of automatically generating corresponding assembly language intermediate layer code based on interface signature is given.

[0067] Figure 3 This is a flowchart illustrating a dynamic library loading method provided in an exemplary embodiment of this application. This method can be used for, for example... Figure 1 The computer equipment shown. Based on Figure 2 In the illustrated embodiment, step 210 includes steps 211 and 212.

[0068] Step 211: Determine the target assembly code template from at least two candidate assembly code templates based on the parameter information in the interface signature of the first function.

[0069] For example, the interface signature includes parameter information of the first function. The parameter information includes at least one of the following: number of parameters, parameter type, and parameter order.

[0070] For example, different assembly code templates (or "generic templates") can be set for different types of dynamic library functions based on the interface signature. The calling convention determines the register order for parameter passing and the stack frame management rules, thus requiring different assembly code templates for different conventions (such as ARM64 AAPCS and x64 System V). The parameter type (integer, floating-point, vector) determines whether general-purpose registers or floating-point / vector registers need to be saved and restored, requiring the template to differentiate in terms of register operation instruction sets. Whether the number of parameters exceeds the register passing threshold determines whether additional instructions are needed to handle parameters on the stack, thus distinguishing between simple and complex parameter context management logic. The return value type (such as returning a large structure via a hidden pointer) affects the pre-call preparation and post-call cleanup steps, requiring a dedicated template to handle this special post-call state. Therefore, by pre-designing corresponding, optimized instruction sequence assembly code templates for these different hardware interaction modes, the generation tool can select the most suitable template for instantiation based on the specific mode revealed by the interface signature, thereby efficiently and correctly generating generic intermediate layer code capable of handling arbitrary calling conventions.

[0071] In one alternative embodiment, different assembly code templates can be set according to the number of parameters in the parameter information of the interface signature. At least two candidate assembly code templates are included, including a first assembly code template and a second assembly code template.

[0072] The first assembly code template is used to cache the parameter context of function calls in registers before dynamically loading the dynamic library, and restores the parameter context to registers before executing the first function.

[0073] If the number of parameters in the parameter information is not greater than the number threshold, the first type of assembly code template is determined as the target assembly code template; the number threshold is determined based on the maximum number of parameters passed from the register.

[0074] The second assembly code template is used to cache the parameter context of function calls in registers and stack memory before dynamically loading dynamic libraries, and restore the parameter context to registers and stack memory before executing the first function.

[0075] If the number of parameters in the parameter information exceeds the threshold, the second assembly template will be selected as the target assembly code template.

[0076] Step 212: Fill the function information of the first function and the dynamic library information of the dynamic library into the target assembly code template to obtain the assembly language intermediate layer code corresponding to the first function.

[0077] Step 220: Compile and link the source code, linking the calls to the first function in the source code to the assembly language intermediate layer code to obtain the executable file of the source code.

[0078] For example, such as Figure 4 As shown, the source code files include: .c files (C language), .cpp files (C++ language), .m files (Objective-C language), and .swift files (Swift language). The source code files are processed uniformly by the compiler to generate corresponding object files (.o files). In the subsequent linking stage, the .o object files are input into the linker along with the static library. Simultaneously, the linker also receives an assembly intermediate layer interface file (.s file) automatically generated using the method provided in this application embodiment for lazy loading. The assembly intermediate layer interface file includes assembly language intermediate layer code corresponding to at least one function in the dynamic library. The linker uses the assembly intermediate layer interface file to link calls to dynamic library functions in the object file, instead of directly linking the dynamic library. The linker parses the symbols in the .s assembly intermediate layer interface file, redirecting calls to dynamic library functions in the source code to the assembly language intermediate layer code, thus ultimately generating an executable file. By using the generated .s assembly intermediate layer interface file to replace the original dynamic library in the linking process, the generated executable file can achieve on-demand loading (lazy loading) of the dynamic library at runtime through the assembly language intermediate layer code within it, instead of static binding at startup.

[0079] Step 230: When the executable file calls the first function, the assembly language intermediate layer code is executed; the assembly language intermediate layer code is used to dynamically load the dynamic library and execute the first function.

[0080] For example, such as Figure 5 As shown, the assembly language intermediate layer code is executed to determine the memory address binding status of the first function and to determine whether the interface of the first function is linked to 401.

[0081] If the memory address of the first function is not bound, load the dynamic library 402, obtain the memory address of the first function and bind it 403, and jump to the memory address of the first function to execute the first function 404.

[0082] If the memory address of the first function is already bound, read the memory address of the first function and jump to it, then execute the first function and get a 404 error.

[0083] 1. If the number of parameters of the first function is not greater than the number threshold, the parameter context of the first function is cached in the register.

[0084] Then (1) save the parameter context of the first function cached in the register to the stack frame of the assembly language intermediate code; the stack frame of the assembly language intermediate code is the storage area allocated for the assembly language intermediate code in the stack memory when the assembly language intermediate code is running.

[0085] (2) Load the dynamic library, obtain the memory address of the first function and bind it.

[0086] (3) Load the parameter context saved in the stack frame of the assembly language intermediate layer code back into the register.

[0087] (4) Jump to the memory address of the first function and execute the first function.

[0088] For example, such as Figure 6 As shown, in one optional embodiment, the method may include the following steps: Step 501: Call the intermediate layer interface: The execution flow of the executable file jumps to the entry point of the assembly language intermediate layer code. The processor state and the original parameter passing registers (X0-X7, Q0-Q7) context enter the execution environment of the assembly language intermediate layer code. At this time, the values ​​in all the passed parameters (the registers represented by X0-X7 and Q0-Q7 in the figure) are the parameter context to be passed.

[0089] Step 502: Interface Push onto Stack: The intermediate assembly language code first performs stack frame allocation, pushing its own stack frame pointer ( Figure 6 The stack pointer (SP, or stack pointer) moves towards lower memory addresses, creating a dedicated stack storage area (the stack frame of the intermediate assembly language code). Key context information, such as the current frame pointer (FP) and the link register (LR), is pushed onto the stack as data for storage.

[0090] Step 503: Cache parameters: The assembly language intermediate layer code sequentially saves the values ​​in the current parameter register group (X0-X7 and Q0-Q7) to its stack frame one by one.

[0091] Step 503: Binding the Original Interface: The assembly language intermediate layer code checks the target address binding status of the first function. If it is not bound, the dynamic loading mechanism is triggered to load the dynamic library, obtain the real memory address of the first function, and record and bind it to a specific data storage location.

[0092] Step 504: Restoring Parameters: Before calling the actual first function, the assembly language intermediate layer code pops the previously cached parameter context (i.e., X0-X7 and Q0-Q7) from its own stack frame one by one in reverse order and loads them back precisely into the corresponding original parameter registers (X0-X7, Q0-Q7), thereby completely restoring the processor parameter context state at the time of the call.

[0093] Step 505: Call the original interface: The processor jumps to the memory address of the first function bound in step 504 and executes the original logic of the first function. At this point, the lazy loading call is complete.

[0094] Step 506: Popping from the stack: After the first function finishes execution and returns, the assembly language intermediate layer code reclaims its stack frame space, restores the stack pointer, and completes the cleanup.

[0095] Taking the arm64 architecture as an example, when the number of parameters is less than or equal to 8, the implementation of the assembly language intermediate layer code can be as follows.

[0096] Part 1: Code Structure and Function Entry Points .section __TEXT, __text / / Defines the "section" to which the following code belongs. __TEXT is the section name, and __text indicates that the section contains executable machine instructions.

[0097] .align 4 / / Specifies the alignment of the following code in memory. "4" means aligned by 2. 4 =16-byte alignment is the basic alignment requirement for ARM64 instructions.

[0098] `.global __ZN9TestClass4testEv` / / Declares the symbol `__ZN9TestClass4testEv` as a global symbol, allowing the linker to see and call it from other object files. This symbol is the name-manualized form of the C++ function `TestClass::test()`.

[0099] __ZN9TestClass4testEv: / / label, defines the specific memory location of the previously declared global symbol __ZN9TestClass4testEv, that is, the function entry point.

[0100] .cfi_startproc / / Debugging information directive, call frame information: Starts a procedure. Used to generate metadata needed by the debugger during stack backtracking.

[0101] Part Two: Function Prologue (Pushing the interface onto the stack and saving its own context) `stp x29, x30, [sp, #-16]!` / / This creates and maintains the assembly language intermediate code's own stack frame. `stp` stores a pair of register instructions; `x29` is the frame pointer register; `x30` is the link register, storing the return address. `[sp,#-16]!` is the addressing mode: first, the value of the stack pointer `sp` is subtracted by 16 bytes (`#-16`), then the values ​​of `x29` and `x30` are stored in the new memory address pointed to by `sp`, and `sp` is updated to this new address. The old frame pointer (FP) and return address are pushed onto the stack frame of the assembly language intermediate code (saving the context), while the stack pointer is moved to allocate space.

[0102] `mov x29, sp` / / Copies the value of the current stack pointer `sp` to the frame pointer `x29`. From this point on, `x29` points to the bottom of the current function's stack frame.

[0103] sub sp, sp, #32 / / Decrease the stack pointer sp by 32 bytes to allocate 32 bytes of stack space for temporary data storage later.

[0104] stp x19, x20, [sp, #0] / / Stores the values ​​of general-purpose registers x19 and x20 at an offset of sp+0.

[0105] str x8, [sp, #16] / / str is a instruction to store a single register. It stores the value of register x8 at an offset of sp+16.

[0106] Part 3: Address Checking and Binding (Determining if a dynamic library needs to be loaded) `adrp x19, _data__ZN9TestClass4testEv@PAGE` / / `adrp` is used to calculate the base address of the memory page containing a symbol. It calculates the page address of the symbol `_data__ZN9TestClass4testEv` (which points to the original function's address) and stores it in `x19`.

[0107] `ldr x20, [x19, _data__ZN9TestClass4testEv@PAGEOFF]` / / `ldr` is a load instruction from memory to register. It calculates the full address of the symbol by adding the page address stored in `x19` to the symbol's page offset (`@PAGEOFF`), and then loads 8 bytes of data (a pointer to the actual function) from that address into the `x20` register.

[0108] mov x19, #0 / / Move the immediate value 0 to register x19.

[0109] subs x19, x19, x20 / / subs is a subtraction instruction with flags. It calculates the value of x19(0) minus x20, and the result affects the status flags.

[0110] `cset w8, ne` / / `cset` is a conditional set instruction. If the result of the previous instruction is not equal (ne), then the w8 register is set to 1; otherwise, it is set to 0. That is, it checks whether the address stored in `_data__ZN9TestClass4testEv` is 0 (unbound).

[0111] `tbnz w8, #0, LBB0_2` / / `tbnz` is a jump instruction that checks if the test bit is not zero. It tests bit 0 of `w8`. If it is not zero (i.e., `w8 != 0`), it jumps to the label `LBB0_2`. If it is zero (indicating that the instruction is bound and a valid address is stored), it continues to the next instruction.

[0112] LBB0_1: / / is a label that marks the beginning of a code block for dynamically loaded libraries.

[0113] Part Four: Dynamic Library Loading and Caching Parameters stp x0, x1, [sp, #-16]! stp x2, x3, [sp, #-16]! stp x4, x5, [sp, #-16]! stp x6, x7, [sp, #-16]! stp q0, q1, [sp, #-32]! stp q2, q3, [sp, #-32]! stp q4, q5, [sp, #-32]! stp q6, q7, [sp, #-32]! / / Safely save all passed parameters (in registers) onto the stack, then call the load logic. The above series of instructions pushes the values ​​of parameter registers x0-x7 (general-purpose registers) and q0-q7 (floating-point / vector registers) onto the stack in sequence. For example, stp x0, x1, [sp, #-16]! first shifts sp and then stores the value.

[0114] adrp x0, DemoFramework.framework.str@PAGE add x0, x0, DemoFramework.framework.str@PAGEOFF adrp x1, _data_DemoFramework.framework@PAGE add x1, x1, _data_DemoFramework.framework@PAGEOFF adrp x2, __ZN9TestClass4testEv.str@PAGE add x2, x2, __ZN9TestClass4testEv.str@PAGEOFF adrp x3, _data__ZN9TestClass4testEv@PAGE add x3, x3, _data__ZN9TestClass4testEv@PAGEOFF / / Load strings and data addresses into x0-x3 using adrp and add: Prepare four parameters for calling _load_lazy_framework: frame name string address, frame address pointer, symbol name string address, and symbol address pointer.

[0115] `bl _load_lazy_framework` / / `bl` is a linked jump instruction used to call a function. Calling `_load_lazy_framework` loads the framework, finds the actual address of the symbol `_ZN9TestClass4testEv`, and writes it to the memory location pointed to by `_data__ZN9TestClass4testEv`.

[0116] Part 5: Parameter Restoration ldp q6, q7, [sp], #32 ldp q4, q5, [sp], #32 ldp q2, q3, [sp], #32 ldp q0, q1, [sp], #32 ldp x6, x7, [sp], #16 ldp x4, x5, [sp], #16 ldp x2, x3, [sp], #16 ldp x0, x1, [sp], #16 / / In the reverse order of pushing onto the stack, pop and load the values ​​of q6-q0 and x7-x0 previously saved on the stack back into their respective registers. [sp], #32 indicates that data is loaded into the register from the current sp address, and then sp is incremented by 32 bytes (parameters are popped from the stack).

[0117] b LBB0_2 / / Unconditional jump to LBB0_2.

[0118] Part 6: Final Jump and Function Closure (Interface Popping from Stack) LBB0_2: / / label.

[0119] ldr x8, [sp, #16] ldp x19, x20, [sp, #0] / / Restore the previously saved values ​​of registers x8, x19, and x20.

[0120] adrp x20, _data__ZN9TestClass4testEv@PAGE ldr x20, [x20, _data__ZN9TestClass4testEv@PAGEOFF] / / Reload the latest, already bound function address stored in _data__ZN9TestClass4testEv into x20.

[0121] `blr x20` / / `blr` is a linked jump instruction to a register. It jumps to the address stored in register `x20` (i.e., the actual address of the original function) for execution, and stores the return address in `x30`. In other words, it calls the original interface.

[0122] ldp x19, x20, [sp, #0] / / Restore x19, x20.

[0123] add sp, sp, #32 / / Reclaim the allocated 32 bytes of stack space.

[0124] `ldp x29, x30, [sp], #16` / / Pops the saved old frame pointer (x29) and return address (x30) from the stack, restoring the stack pointer to its state before the function begins. This is the final step in popping the interface from the stack.

[0125] Ret / / Returns from the current function to the caller (the code that calls the assembly language intermediate interface).

[0126] .cfi_endproc / / Paired with .cfi_startproc, indicating the end of the process.

[0127] Part 7: Data Segment Definition .comm _data_DemoFramework.framework,8,3 .comm _data__ZN9TestClass4testEv,8,3 / / .comm declares a common symbol allocated at link time. Here, two 8-byte spaces are declared for storing pointer data.

[0128] .section __TEXT,__cstring,cstring_literals / / Defines a new section specifically for storing read-only string constants.

[0129] DemoFramework.framework.str: .asciz "DemoFramework.framework" / / Defines a string label and the actual null-terminated (.asciz) string content. Provides the library name for dynamically loaded functions.

[0130] __ZN9TestClass4testEv.str: .asciz "_ZN9TestClass4testEv" / / Defines another string to provide the target symbol name for the dynamic loader.

[0131] 2. If the number of parameters of the first function is greater than the number threshold, the parameter context of the first function is cached in the register and the caller's stack frame.

[0132] Then (1) save the first part of the parameter context of the first function cached in the caller's stack frame to the first storage area of ​​the stack frame of the assembly language intermediate code. Save the second part of the parameter context of the first function cached in the register to the second storage area of ​​the stack frame of the assembly language intermediate code.

[0133] (2) Load the dynamic library, obtain the memory address of the first function and bind it.

[0134] (3) Load the second part of the parameter context stored in the second storage area back into the register; load the first part of the parameter context stored in the first storage area back into the caller stack frame.

[0135] (4) Jump to the memory address of the first function and execute the first function.

[0136] For example, such as Figure 7 As shown, in one optional embodiment, the method may include the following steps: Step 601: Invoking the intermediate layer interface: The execution flow of the executable file jumps from the caller to the intermediate layer code entry point. At this time, the first part of the parameter context (i.e., the first 8 parameters) has been loaded into the registers (X0-X7, Q0-Q7) as agreed, while the second part of the parameter context (the part exceeding the register capacity) has been pre-placed in a specific area of ​​the caller's stack frame. The invocation mechanism automatically pushes the return address onto the caller's stack frame.

[0137] Step 602: Passing parameters in a cache (first part of the parameter context): The assembly language intermediate layer code first processes the stack-passed parameters. It copies the first part of the parameter context (i.e., the extra parameter data block) temporarily stored in the caller's stack frame to the first storage area in its own stack frame (i.e., the stack frame of the assembly language intermediate layer code) for temporary storage.

[0138] Step 603: Interface Push: The assembly language intermediate layer code establishes and protects its own execution context, saving the frame pointer and return address as push data to the starting area of ​​its own stack frame.

[0139] Step 604: Cache parameters (second part of the parameter context): The assembly language intermediate layer code saves the second part of the parameter context (i.e., the first 8 parameters) carried in the register one by one to the second storage area in its own stack frame immediately after the pushed data for temporary storage.

[0140] Step 605: Binding the original interface: The assembly language intermediate layer code checks the target function address binding status. If not bound, the dynamic library is loaded, the memory address of the first function is obtained, and the binding is completed.

[0141] Step 606: Restoring Parameters (Second Part Parameter Context): Before actually calling the first function in the dynamic library, the assembly language intermediate layer code first restores the register parameter context temporarily stored in the second storage area to the corresponding original registers (X0-X7, Q0-Q7).

[0142] Step 607: Restore parameters (first part of the parameter context) and copy parameter data: The assembly language intermediate layer code writes the stack parameter context (i.e., the extra parameter block, the first part of the parameter context) temporarily stored in the first storage area back to the original parameter area or its equivalent location in the caller's stack frame, so as to reconstruct a complete stack parameter layout that conforms to the original calling convention.

[0143] Step 608: Call the original interface: After restoring all parameters and reconstructing the context, the processor jumps to the memory address of the bound first function and executes it. At this time, the first 8 parameters are passed through registers, and additional parameters are passed through the reconstructed caller stack frame.

[0144] Step 609: Popping from the stack: After the first function returns, the assembly language intermediate layer code reclaims its own stack frame, restores the stack pointer, and completes the cleanup.

[0145] Taking the arm64 architecture as an example, when the number of parameters is greater than 8, the implementation of the assembly language intermediate layer code can be as follows.

[0146] Part 1: Code Structure and Function Entry Points (The code logic is the same as the code with parameters less than or equal to 8, so it will not be repeated here). .section __TEXT,__text .align 4 .global __ZN9TestClass4testEv __ZN9TestClass4testEv: .cfi_startproc Part Two: Function Prologue (Pushing the interface onto the stack and saving its own context) sub sp, sp, #32 / / Compared to assembly language intermediate code with ≤8 parameters, 32 bytes of space are allocated before stp x29, x30. A region is pre-allocated at the bottom of the current (assembly language intermediate) stack frame to store or back up additional parameters passed through the caller's stack frame (i.e., the 9th and subsequent parameters).

[0147] stp x29, x30, [sp, #-16]! / / After the previous step, the stack pointer sp has been moved down by 32 bytes, and then pushed onto the stack. x29 (FP) and x30 (LR) are saved to the new location sp-16, and then sp is updated to -16. This completes the preservation of the current context.

[0148] mov x29, sp / / Set the new stack pointer position to the frame pointer.

[0149] sub sp, sp, #32 / / Allocate another 32 bytes of space. This is used to store the stack space for registers x19, x20, x8, and subsequent cached register parameters (x0-x7, q0-q7). At this point, the stack frame has expanded. The upper half (closer to the caller) is used to manage additional parameters, and the lower half (closer to the new sp) is used for register parameters and the runtime context.

[0150] stp x19, x20, [sp, #0] str x8, [sp, #16] Part 3: Address Checking and Binding (Parts 3 to 5 have the same code logic as for parameters less than or equal to 8, except that the operation is performed in a lower sp region) adrp x19, _data__ZN9TestClass4testEv@PAGE ldr x20, [x19, _data__ZN9TestClass4testEv@PAGEOFF] mov x19, #0 subs x19, x19, x20 cset w8, ne tbnz w8, #0, LBB0_2 LBB0_1: Part Four: Dynamic Library Loading and Caching Parameters stp x0, x1, [sp, #-16]! stp x2, x3, [sp, #-16]! stp x4, x5, [sp, #-16]! stp x6, x7, [sp, #-16]! stp q0, q1, [sp, #-32]! stp q2, q3, [sp, #-32]! stp q4, q5, [sp, #-32]! stp q6, q7, [sp, #-32]! adrp x0, DemoFramework.framework.str@PAGE add x0, x0, DemoFramework.framework.str@PAGEOFF adrp x1, _data_DemoFramework.framework@PAGE add x1, x1, _data_DemoFramework.framework@PAGEOFF adrp x2, __ZN9TestClass4testEv.str@PAGE add x2, x2, __ZN9TestClass4testEv.str@PAGEOFF adrp x3, _data__ZN9TestClass4testEv@PAGE add x3, x3, _data__ZN9TestClass4testEv@PAGEOFF bl _load_lazy_framework Part 5: Parameter Restoration ldp q6, q7, [sp], #32 ldp q4, q5, [sp], #32 ldp q2, q3, [sp], #32 ldp q0, q1, [sp], #32 ldp x6, x7, [sp], #16 ldp x4, x5, [sp], #16 ldp x2, x3, [sp], #16 ldp x0, x1, [sp], #16 b LBB0_2 Part 6: Handling Extra Parameters on the Stack and Executing the Call LBB0_2: / / Rendezvous point, ready for final call.

[0151] `ldr x8, [sp, #16]` / / Restores x8, x19, and x20 from the bottom region of its own stack frame. The old values ​​of x19 and x20 are now restored and can be reused. Start processing the extra stack parameters.

[0152] `ldp x19, x20, [sp, #48]` / / `[sp, #48]`: At this point, `sp` points to the bottom of the second memory area. `sp+48` points to a reserved 32-byte area (located at the top of the entire stack frame) containing the extra parameters (first part of the parameter context) from the caller's stack frame that should have been backed up in the cached parameter passing step. A pair of data (e.g., two 64-bit parameters) is loaded from there into `x19` and `x20`.

[0153] `stp x19, x20, [sp, #-32]` / / Stores a pair of data from `x19` and `x20` at location `sp-32`, which is a specific location in the parameter area on the stack when the original function was called (the top of the reconstructed caller stack frame). `[sp, #-32]` does not change `sp`; it only writes the data. This corresponds to copying the parameter data and loading the first part of the parameter context saved in the first storage area back into the caller stack frame.

[0154] ldp x19, x20, [sp, #64] stp x19, x20, [sp, #-16] / / Repeat similar operations if there are more parameters on the stack. Load the next pair of data from sp+64 (another location in the backup area) and store it in sp-16 (a lower location in the reconstructed stack frame).

[0155] `ldp x19, x20, [sp, #0]` / / Loads data from sp+0, which is the actual old x19 and x20 values ​​that need to be restored. This instruction restores them, preparing them for subsequent calls.

[0156] adrp x20, _data__ZN9TestClass4testEv@PAGE ldr x20, [x20, _data__ZN9TestClass4testEv@PAGEOFF] / / Loads the address of the already bound real function into x20.

[0157] blr x20 / / Jump to and call the actual original function TestClass::test(). At this point, the first 8 parameters have been stored in registers x0-x7 and q0-q7 as agreed, and positions sp-16, sp-32, etc. have also been correctly set, storing the 9th, 10th, and other additional parameters, so the original function can be accessed normally.

[0158] Part 7: Function Cleanup (Interface Popping from Stack) ldp x19, x20, [sp, #0] / / Restore x19, x20 from the bottom of the stack frame.

[0159] add sp, sp, #32 / / Reclaim the 32 bytes allocated for register parameters and runtime context (lower half).

[0160] ldp x29, x30, [sp], #16 / / Pop and restore x29 (FP) and x30 (LR) (i.e., the old frame pointer and return address), while shifting sp up by 16 bytes.

[0161] add sp, sp, #32 / / Reclaim the 32 bytes of space reserved at the beginning for processing parameters on the stack (upper half). At this point, the entire stack pointer is restored to the position it was at when the function was called.

[0162] Ret / / Function return value.

[0163] .cfi_endproc Part 8: Data Segment Definition (The code logic is the same as for parameters less than or equal to 8, so it will not be repeated here) .comm _data_DemoFramework.framework,8,3 .comm _data__ZN9TestClass4testEv,8,3 .section __TEXT,__cstring,cstring_literals DemoFramework.framework.str: .asciz "DemoFramework.framework" __ZN9TestClass4testEv.str: .asciz "_ZN9TestClass4testEv" In summary, the method provided in this embodiment eliminates the need for manual writing and maintenance of intermediate layer code, automatically generating assembly language intermediate layer code based on the interface signature. Since assembly language can directly manipulate the processor's registers and stack memory, the generated intermediate layer code is universal and does not require declaration or maintenance of function parameter lists. When parameter context caching is required, the assembly language intermediate layer code only needs to follow the fixed calling conventions of the CPU (Central Processing Unit) architecture, reading and saving the parameter context from the agreed register set (e.g., X0-X7) and / or the agreed location on the call stack; during execution recovery, the parameter context is written back to its original location in the same way. The assembly language intermediate layer code can operate directly at the binary interface level agreed upon by the underlying hardware, free from the semantic constraints of high-level languages ​​(e.g., C). When the processor makes a function call, the function call parameters are passed through a fixed set of registers (e.g., X0 in the ARM64 architecture). The parameters (X7) are passed along with specific offsets in the stack memory, and the calling rules are predetermined by the hardware architecture. Therefore, the assembly language intermediate layer code does not need to know the number, type, or name of the parameters (i.e., the parameter list). It only needs to read all existing data from the corresponding register set and stack offset as a parameter context for caching according to the calling convention specified by the hardware, and write the cached data back to its original location according to the same rules before calling the actual function. This method relies only on physical location rather than the parameter list, allowing the same intermediate layer code logic to be applied to functions with arbitrarily different signatures, thus eliminating the arduous work of manually adapting and maintaining parameter lists for each function. This allows the same set of intermediate layer code logic to adapt to a massive number of functions with different interface signatures. When the interface of a function in the dynamic library changes, only the generation step needs to be run again according to the new interface signature to obtain the new assembly language intermediate layer code. This eliminates the arduous maintenance work of locating, modifying, and verifying parameters due to changes in the parameter list, achieving efficient lazy loading while reducing development and maintenance costs.

[0164] It should be noted that this application may display prompt interfaces, pop-ups, or output voice prompts before and during the collection of user data. These prompt interfaces, pop-ups, or voice prompts are used to inform the user that their data is being collected. This ensures that the application only begins the steps for collecting user data after receiving confirmation from the user regarding the prompt interface or pop-up; otherwise (i.e., without user confirmation), the steps for collecting user data end, meaning no user data is collected. In other words, all user data collected in this application is collected with the user's consent and authorization, and the collection, use, and processing of related user data must comply with the relevant laws, regulations, and standards of the relevant countries and regions.

[0165] It should be noted that the order of the method steps provided in the embodiments of this application can be appropriately adjusted, and the steps can also be added or removed as appropriate. The steps in the above embodiments can also be arbitrarily combined to obtain new embodiments. Any variations that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the protection scope of this application, and therefore will not be elaborated further.

[0166] Figure 8 This is a schematic diagram of a dynamic library loading device provided in an exemplary embodiment of this application. The device includes: The generation module 1001 is used to generate the assembly language intermediate layer code corresponding to the first function based on the interface signature of the first function in the dynamic library. The compilation module 1002 is used to compile and link the source code, linking the call to the first function in the source code to the assembly language intermediate layer code, so as to obtain the executable file of the source code; The execution module 1003 is used to execute the assembly language intermediate layer code when the executable file calls the first function; the assembly language intermediate layer code is used to dynamically load the dynamic library and execute the first function. The assembly language intermediate layer code is used to cache the parameter context of function calls before dynamically loading the dynamic library, and to restore the parameter context before executing the first function.

[0167] In one optional embodiment, the interface signature includes parameter information of the first function; The generation module 1001 is used to determine the target assembly code template from at least two candidate assembly code templates based on the parameter information in the interface signature of the first function. The generation module 1001 is used to fill the function information of the first function and the dynamic library information of the dynamic library into the target assembly code template to obtain the assembly language intermediate layer code corresponding to the first function.

[0168] In one optional embodiment, the at least two candidate assembly code templates include a first assembly code template and a second assembly code template; The generation module 1001 is used to determine the first assembly code template as the target assembly code template when the number of parameters in the parameter information is not greater than a number threshold; the number threshold is determined based on the maximum number of parameters passed by the register. The generation module 1001 is used to determine the second type of assembly code template as the target assembly code template when the number of parameters in the parameter information is greater than the number threshold.

[0169] In an optional embodiment, the first assembly code template is used to cache the parameter context of a function call in a register before dynamically loading the dynamic library, and restore the parameter context to the register before executing the first function; The second assembly code template is used to cache the parameter context of function calls in registers and stack memory before dynamically loading the dynamic library, and restore the parameter context to the registers and stack memory before executing the first function.

[0170] In an optional embodiment, the running module 1003 is used to execute the assembly language intermediate layer code to determine the memory address binding status of the first function; The running module 1003 is used to load the dynamic library, obtain and bind the memory address of the first function, and jump to the memory address of the first function to execute the first function when the memory address of the first function is not bound.

[0171] In an optional embodiment, the running module 1003 is used to execute the assembly language intermediate layer code to determine the memory address binding status of the first function; The running module 1003 is used to read the memory address of the first function and jump to execute the first function when the memory address of the first function has been bound.

[0172] In an optional embodiment, the number of parameters of the first function is not greater than a number threshold, and the parameter context of the first function is cached in a register; The execution module 1003 is used to save the parameter context of the first function cached in the register to the stack frame of the assembly language intermediate layer code; the stack frame of the assembly language intermediate layer code is a storage area allocated for the assembly language intermediate layer code in the stack memory when the assembly language intermediate layer code is running. The running module 1003 is used to load the parameter context saved in the stack frame of the assembly language intermediate layer code back into the register.

[0173] In an optional embodiment, the number of parameters of the first function is greater than a number threshold, and the parameter context of the first function is cached in registers and the caller stack frame; The running module 1003 is used to save the first part of the parameter context of the first function cached in the caller stack frame to the first storage area of ​​the stack frame of the assembly language intermediate layer code; The running module 1003 is used to save the second part of the parameter context of the first function cached in the register to the second storage area of ​​the stack frame of the assembly language intermediate layer code; The running module 1003 is used to load the second part of the parameter context stored in the second storage area back into the register; The running module 1003 is used to load the first part of the parameter context stored in the first storage area back into the caller stack frame.

[0174] It should be noted that the dynamic library loading device provided in the above embodiments is only an example of the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the dynamic library loading device and the dynamic library loading method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0175] Embodiments of this application also provide a computer device, comprising: a processor and a memory, wherein the memory stores at least one instruction, at least one program, code set, or instruction set, and the at least one instruction, at least one program, code set, or instruction set is loaded and executed by the processor to implement the dynamic library loading method provided in the above-described method embodiments. This computer device can be implemented as a terminal device.

[0176] For example, Figure 9 This is a schematic diagram of the structure of a computer device provided in an exemplary embodiment of this application.

[0177] Typically, computer device 1700 includes a processor 1701 and a memory 1702.

[0178] Processor 1701 may include one or more processing cores, such as a quad-core processor, an octa-core processor, etc. Processor 1701 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). Processor 1701 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 1701 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 1701 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0179] Memory 1702 may include one or more computer-readable storage media, which may be non-transitory. Memory 1702 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in memory 1702 is used to store at least one instruction, which is executed by processor 1701 to implement the dynamic library loading method provided in the method embodiments of this application.

[0180] In some embodiments, the computer device 1700 may also optionally include a peripheral device interface 1703 and at least one peripheral device. The processor 1701, memory 1702, and peripheral device interface 1703 can be connected via a bus or signal line. Each peripheral device can be connected to the peripheral device interface 1703 via a bus, signal line, or circuit board. Specifically, the peripheral device includes at least one of the following: a radio frequency circuit 1704, a display screen 1705, a camera assembly 1706, an audio circuit 1707, and a power supply 1708.

[0181] Peripheral device interface 1703 can be used to connect at least one I / O (Input / Output) related peripheral device to processor 1701 and memory 1702. In some embodiments, processor 1701, memory 1702 and peripheral device interface 1703 are integrated on the same chip or circuit board; in some other embodiments, any one or two of processor 1701, memory 1702 and peripheral device interface 1703 can be implemented on separate chips or circuit boards, which is not limited in this application embodiment.

[0182] The radio frequency (RF) circuit 1704 is used to receive and transmit RF (Radio Frequency) signals, also known as electromagnetic signals. The RF circuit 1704 communicates with communication networks and other communication devices via electromagnetic signals. The RF circuit 1704 converts electrical signals into electromagnetic signals for transmission, or converts received electromagnetic signals back into electrical signals. Optionally, the RF circuit 1704 includes: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a user identity module card, etc. The RF circuit 1704 can communicate with other computer devices via at least one wireless communication protocol. This wireless communication protocol includes, but is not limited to: the World Wide Web, metropolitan area networks, intranets, various generations of mobile communication networks (2G, 3G, 4G, and 5G), wireless local area networks, and / or WiFi (Wireless Fidelity) networks. In some embodiments, the RF circuit 1704 may also include circuitry related to NFC (Near Field Communication), which is not limited in this application.

[0183] Display screen 1705 is used to display a UI (User Interface). This UI may include graphics, text, icons, videos, and any combination thereof. When display screen 1705 is a touch display screen, it also has the ability to collect touch signals on or above its surface. These touch signals can be input as control signals to processor 1701 for processing. In this case, display screen 1705 can also be used to provide virtual buttons and / or a virtual keyboard, also known as soft buttons and / or a soft keyboard. In some embodiments, there may be one display screen 1705, which is located on the front panel of computer device 1700; in other embodiments, there may be at least two display screens 1705, respectively located on different surfaces of computer device 1700 or in a folded design; in still other embodiments, display screen 1705 may be a flexible display screen, located on a curved or folded surface of computer device 1700. Furthermore, display screen 1705 may also be configured as a non-rectangular, irregular shape, i.e., a non-rectangular screen. The display screen 1705 can be made of materials such as LCD (Liquid Crystal Display) and OLED (Organic Light-Emitting Diode).

[0184] The camera assembly 1706 is used to acquire images or videos. Optionally, the camera assembly 1706 includes a front-facing camera and a rear-facing camera. Typically, the front-facing camera is located on the front panel of the computer device 1700, and the rear-facing camera is located on the back of the computer device. In some embodiments, there are at least two rear-facing cameras, which are any one of a main camera, a depth-sensing camera, a wide-angle camera, and a telephoto camera, to achieve background blurring by fusion of the main camera and the depth-sensing camera, panoramic shooting by fusion of the main camera and the wide-angle camera, VR (Virtual Reality) shooting, or other fusion shooting functions. In some embodiments, the camera assembly 1706 may also include a flash. The flash can be a single-color temperature flash or a dual-color temperature flash. A dual-color temperature flash refers to a combination of a warm light flash and a cool light flash, which can be used for light compensation at different color temperatures.

[0185] The audio circuit 1707 may include a microphone and a speaker. The microphone is used to collect sound waves from the user and the environment, converting them into electrical signals that are input to the processor 1701 for processing, or to the radio frequency circuit 1704 for voice communication. For stereo sound acquisition or noise reduction purposes, multiple microphones may be used, positioned at different locations within the computer device 1700. The microphone may also be an array microphone or an omnidirectional microphone. The speaker is used to convert electrical signals from the processor 1701 or the radio frequency circuit 1704 into sound waves. The speaker may be a conventional diaphragm speaker or a piezoelectric ceramic speaker. When the speaker is a piezoelectric ceramic speaker, it can convert electrical signals not only into audible sound waves but also into inaudible sound waves for purposes such as distance measurement. In some embodiments, the audio circuit 1707 may also include a headphone jack.

[0186] Power supply 1708 is used to supply power to the various components in computer device 1700. Power supply 1708 can be AC ​​power, DC power, a disposable battery, or a rechargeable battery. When power supply 1708 includes a rechargeable battery, the rechargeable battery can be a wired rechargeable battery or a wireless rechargeable battery. A wired rechargeable battery is a battery that is charged via a wired line, and a wireless rechargeable battery is a battery that is charged via a wireless coil. The rechargeable battery can also be used to support fast charging technology.

[0187] In some embodiments, the computer device 1700 further includes one or more sensors 1709. The one or more sensors 1709 include, but are not limited to, an accelerometer 1710, a gyroscope 1711, a pressure sensor 1712, an optical sensor 1713, and a proximity sensor 1714.

[0188] Accelerometer 1710 can detect the magnitude of acceleration along the three coordinate axes of a coordinate system established by computer device 1700. For example, accelerometer 1710 can be used to detect the components of gravitational acceleration along the three coordinate axes. Processor 1701 can control touchscreen display 1705 to display the user interface in landscape or portrait view based on the gravitational acceleration signal acquired by accelerometer 1710. Accelerometer 1710 can also be used for games or for acquiring user motion data.

[0189] The gyroscope sensor 1711 can detect the orientation and rotation angle of the computer device 1700. The gyroscope sensor 1711 can work in conjunction with the accelerometer sensor 1710 to acquire 3D motion data from the user on the computer device 1700. Based on the data acquired by the gyroscope sensor 1711, the processor 1701 can perform the following functions: motion sensing (e.g., changing the UI based on the user's tilt), image stabilization during shooting, game control, and inertial navigation.

[0190] Pressure sensor 1712 can be disposed on the side bezel of computer device 1700 and / or on the lower layer of touch display screen 1705. When pressure sensor 1712 is disposed on the side bezel of computer device 1700, it can detect the user's grip signal on computer device 1700, and processor 1701 can perform left / right hand recognition or quick operation based on the grip signal collected by pressure sensor 1712. When pressure sensor 1712 is disposed on the lower layer of touch display screen 1705, processor 1701 can control operable controls on the UI interface based on the user's pressure operation on touch display screen 1705. Operable controls include at least one of button controls, scroll bar controls, icon controls, and menu controls.

[0191] Optical sensor 1713 is used to collect ambient light intensity. In one embodiment, processor 1701 can control the display brightness of touch display screen 1705 based on the ambient light intensity collected by optical sensor 1713. Specifically, when the ambient light intensity is high, the display brightness of touch display screen 1705 is increased; when the ambient light intensity is low, the display brightness of touch display screen 1705 is decreased. In another embodiment, processor 1701 can also dynamically adjust the shooting parameters of camera assembly 1706 based on the ambient light intensity collected by optical sensor 1713.

[0192] The proximity sensor 1714, also known as a distance sensor, is typically located on the front panel of the computer device 1700. The proximity sensor 1714 is used to detect the distance between the user and the front of the computer device 1700. In one embodiment, when the proximity sensor 1714 detects that the distance between the user and the front of the computer device 1700 is gradually decreasing, the processor 1701 controls the touch display screen 1705 to switch from a screen-on state to a screen-off state; when the proximity sensor 1714 detects that the distance between the user and the front of the computer device 1700 is gradually increasing, the processor 1701 controls the touch display screen 1705 to switch from a screen-off state to a screen-on state.

[0193] Those skilled in the art will understand that Figure 9 The structure shown does not constitute a limitation on the computer device 1700, and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0194] This application also provides a computer-readable storage medium storing at least one instruction, at least one program, code set, or instruction set. When the at least one instruction, at least one program, code set, or instruction set is loaded and executed by the processor of a computer device, the dynamic library loading method provided in the above-described method embodiments is implemented.

[0195] This application also provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the dynamic library loading method provided in the above-described method embodiments.

[0196] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0197] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent switching, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for loading a dynamic library, characterized in that, The method includes: Based on the interface signature of the first function in the dynamic library, generate the assembly language intermediate layer code corresponding to the first function; The source code is compiled and linked, and the calls to the first function in the source code are linked to the assembly language intermediate layer code to obtain the executable file of the source code; When the executable file calls the first function, the assembly language intermediate layer code is executed; the assembly language intermediate layer code is used to dynamically load the dynamic library and execute the first function. The assembly language intermediate layer code is used to cache the parameter context of function calls before dynamically loading the dynamic library, and to restore the parameter context before executing the first function.

2. The method according to claim 1, characterized in that, The interface signature includes the parameter information of the first function; The step of generating the assembly language intermediate layer code corresponding to the first function based on the interface signature of the first function in the dynamic library includes: Based on the parameter information in the interface signature of the first function, a target assembly code template is determined from at least two candidate assembly code templates; The function information of the first function and the dynamic library information of the dynamic library are filled into the target assembly code template to obtain the assembly language intermediate layer code corresponding to the first function.

3. The method according to claim 2, characterized in that, The at least two candidate assembly code templates include a first assembly code template and a second assembly code template; The step of determining the target assembly code template from at least two candidate assembly code templates based on the parameter information in the interface signature includes: If the number of parameters in the parameter information is not greater than a number threshold, the first assembly code template is determined as the target assembly code template; the number threshold is determined based on the maximum number of parameters passed by registers. If the number of parameters in the parameter information is greater than the number threshold, the second assembly code template will be determined as the target assembly code template.

4. The method according to claim 3, characterized in that, The first type of assembly code template is used to cache the parameter context of the function call in the register before dynamically loading the dynamic library, and restore the parameter context to the register before executing the first function; The second assembly code template is used to cache the parameter context of function calls in registers and stack memory before dynamically loading the dynamic library, and restore the parameter context to the registers and stack memory before executing the first function.

5. The method according to any one of claims 1 to 4, characterized in that, The execution of the assembly language intermediate layer code includes: Execute the assembly language intermediate layer code to determine the memory address binding status of the first function; If the memory address of the first function is not bound, the dynamic library is loaded, the memory address of the first function is obtained and bound, and the execution of the first function is performed at the memory address of the first function.

6. The method according to any one of claims 1 to 4, characterized in that, The execution of the assembly language intermediate layer code includes: Execute the assembly language intermediate layer code to determine the memory address binding status of the first function; If the memory address of the first function is already bound, read the memory address of the first function and jump to execute the first function.

7. The method according to claim 5, characterized in that, The number of parameters of the first function is no greater than a threshold, and the parameter context of the first function is cached in a register; Before loading the dynamic library, the process includes: The parameter context of the first function cached in the register is saved to the stack frame of the assembly language intermediate layer code; the stack frame of the assembly language intermediate layer code is a storage area allocated for the assembly language intermediate layer code in the stack memory when the assembly language intermediate layer code is running. Before jumping to the memory address of the first function to execute the first function, the method further includes: The parameter context saved in the stack frame of the assembly language intermediate layer code is loaded back into the register.

8. The method according to claim 5, characterized in that, The number of parameters of the first function is greater than the number threshold, and the parameter context of the first function is cached in registers and the caller stack frame; Before loading the dynamic library, the process includes: Save the first part of the parameter context of the first function cached in the caller's stack frame to the first storage area of ​​the stack frame of the assembly language intermediate layer code; The second part of the parameter context of the first function cached in the register is saved to the second storage area of ​​the stack frame of the assembly language intermediate layer code; Before jumping to the memory address of the first function to execute the first function, the method further includes: Load the second part of the parameter context stored in the second storage area back into the register; Load the first part of the parameter context stored in the first storage area back into the caller stack frame.

9. A dynamic library loading device, characterized in that, The device includes: The generation module is used to generate the assembly language intermediate layer code corresponding to the first function based on the interface signature of the first function in the dynamic library. The compilation module is used to compile and link the source code, linking the calls to the first function in the source code to the assembly language intermediate layer code, so as to obtain the executable file of the source code; The runtime module is used to execute the assembly language intermediate layer code when the executable file calls the first function; the assembly language intermediate layer code is used to dynamically load the dynamic library and execute the first function. The assembly language intermediate layer code is used to cache the parameter context of function calls before dynamically loading the dynamic library, and to restore the parameter context before executing the first function.

10. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing at least one program, which is loaded and executed by the processor to implement the dynamic library loading method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The readable storage medium stores at least one program segment, which is loaded and executed by a processor to implement the dynamic library loading method as described in any one of claims 1 to 8.

12. A computer program product, characterized in that, The computer program product includes computer instructions stored in a computer-readable storage medium, a processor of a computer device reading the computer instructions from the computer-readable storage medium, and the processor executing the computer instructions to cause the computer device to perform the dynamic library loading method as described in any one of claims 1 to 8.

Images