Library function calling method and device

Abstract

The invention discloses a library function calling method and device, and belongs to the field of computers. The method comprises the following steps: determining dynamic libraries on which a target application program depends during running, wherein the dynamic libraries comprise a first type of dynamic libraries needing transparent transmission and a second type of dynamic libraries not needing transparent transmission; loading the second-class dynamic library, the third-class dynamic library and the fourth-class dynamic library into a memory; in response to a function calling request of the target library function, if the function calling request is triggered by the target application program, calling the target library function from a second-class dynamic library in the memory; if the function calling request is triggered by a library function in a third-class dynamic library, a target library function is called from a fourth-class dynamic library in a memory, and the target library function comprises library functions with the same functions in the second-class dynamic library and the fourth-class dynamic library. Therefore, the second-class dynamic library of the first platform does not need to be subjected to unvarnished transmission, the packaging function does not need to be constructed, and the workload of constructing the packaging function during transplantation of the target application program is greatly reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of computers, and in particular to a library function calling method and device. BACKGROUND

[0002] With the continuous evolution of processor architecture, processors of new architectures often need to have the ability to run existing application programs to ensure the continuity of the software ecosystem and the convenience of users. As a tool for directly translating executable binary programs, a binary translator can translate an executable binary program on one processor to another processor for execution, greatly facilitating the mutual transplantation of binary programs between different processors. In order to reduce the translation overhead of the binary translator, or to ensure that the executable binary file can run normally in the case that the original version of the dynamic library it depends on is missing, the library function call of the executable binary program can be transparently transmitted to the library function of the same function on the heterogeneous processor through "library function local transparent transmission".

[0003] In related technologies, the Box86 / 64 binary translator can run an executable binary program compiled under the x86 architecture (guest platform) on the ARM architecture (host platform). When the executable binary program needs to call a library function during its running process, if the library function does not need to be locally transmitted, the library function is called in the dynamic library of the guest platform, and the Box86 / 64 binary translator performs instruction translation operation to translate the instruction of the library function in the guest platform into the corresponding instruction of the host platform, and executes the instruction. If the library function needs to be locally transmitted, the Box86 / 64 binary translator uses the "library function local transparent transmission" method to transparently transmit the calling operation of the library function to the library function of the same function on the host platform, that is, the Box86 / 64 binary translator does not perform instruction translation operation, but directly calls the library function of the same function on the host platform.

[0004] However, due to the difference in processor architecture, when the Box86 / 64 binary translator calls the library function of the same function on the host platform, it needs to perform function parameter analysis and parameter reconstruction operations through the wrapper function corresponding to the library function. When constructing the wrapper function, the source code of the library function needs to be obtained, and a lot of adaptation development work needs to be done; once the source code of the library function cannot be obtained, the wrapper function cannot be constructed, and the functions of the two library functions on the guest platform and the host platform cannot be guaranteed to be completely consistent. SUMMARY

[0005] The application provides a library function calling method and device, which can solve the problem that other dynamic libraries dependent on the dynamic library which is locally transmitted by the library function also need to be "locally transmitted by the library function", so that the wrapping function corresponding to the library function does not need to be constructed and depended on when the library function is called. The technical solution is as follows:

[0006] In a first aspect, a library function calling method is provided, which comprises:

[0007] determining a dynamic library dependent on a target application program when the target application program runs, the target application program being an application program migrated from a first platform to a second platform, the system architecture of the first platform being different from that of the second platform, the dynamic library comprising a first type of dynamic library needing to be transmitted and a second type of dynamic library not needing to be transmitted, the transmission indicating that the function of the corresponding library function in the first platform is implemented through the library function in the second platform; loading the second type of dynamic library, a third type of dynamic library and a fourth type of dynamic library into the memory, the third type of dynamic library being a dynamic library in the second platform containing the same function as the first type of dynamic library, and the fourth type of dynamic library being a dynamic library in the second platform containing the same function as the second type of dynamic library; in response to a function calling request of a target library function, if the function calling request is triggered by the target application program, calling the target library function from the second type of dynamic library in the memory; if the function calling request is triggered by the library function in the third type of dynamic library, calling the target library function from the fourth type of dynamic library in the memory; wherein the target library function comprises the library functions with the same function in the second type of dynamic library and the fourth type of dynamic library.

[0008] Among them, for the first type of dynamic library which needs to be transmitted, the dynamic binary translator does not need to perform translation operation when the target application program calls the library function therein, and directly calls the library function with the same function in the third type of dynamic library in the second platform to execute; for the second type of dynamic library which does not need to be transmitted, the dynamic binary translator needs to translate the library function in the second type of dynamic library when the target application program calls the library function therein, and execute the translated instructions.

[0009] As can be seen, the library function calling scheme provided by the application only needs to perform library function local transmission on the first type of dynamic library on the first platform, and for the second type of dynamic library on the first platform, the second type of dynamic library and the fourth type of dynamic library with the same function on the second platform are directly loaded into the memory, without the need for library function local transmission on the second type of dynamic library, and without the need for obtaining the source code of the library function to construct the wrapping function. In this way, the workload of constructing the wrapping function when the target application program is ported from one platform to another platform is greatly reduced, and it is ensured that the target application program can normally run on the second platform.

[0010] Optionally, before the function call request of the target library function, the method further comprises: obtaining an address interval in the memory corresponding to each of the second type of dynamic library, the third type of dynamic library and the fourth type of dynamic library; determining a function call relationship of a plurality of library functions included in the second type of dynamic library, the third type of dynamic library and the fourth type of dynamic library; and based on the function call relationship and the address interval in the memory corresponding to each of the dynamic library, repositioning a jump access address corresponding to each of the plurality of library functions, the jump access address indicating an address in the memory of another library function called at runtime of the corresponding library function.

[0011] Since the second type of dynamic library and the fourth type of dynamic library include library functions with the same function interface, when the target library function with the same function in the second type of dynamic library and the fourth type of dynamic library is called, the jump access address in the memory when the target library function is accessed needs to be determined based on the platform to which the caller of the target library function belongs.

[0012] Optionally, the plurality of library functions include a first library function in the target application, and the function call relationship indicates that the first library function needs to call the target library function at runtime; and the repositioning of the jump access address corresponding to each of the plurality of library functions based on the function call relationship and the address interval in the memory corresponding to each of the dynamic library comprises: determining a function access address of the target library function based on the address interval in the memory corresponding to the second type of dynamic library and an offset address of the target library function; and setting the function access address as the jump access address of the first library function calling the target library function.

[0013] Optionally, the plurality of library functions include a second library function in the third type of dynamic library, and the function call relationship indicates that the second library function needs to call the target library function; and the repositioning of the jump access address corresponding to each of the plurality of library functions based on the function call relationship and the address interval in the memory corresponding to each of the dynamic library comprises: determining a function access address of the target library function based on the address interval in the memory corresponding to the fourth type of dynamic library and an offset address of the target library function; and setting the function access address as the jump access address of the second library function calling the target library function.

[0014] Therefore, when the target library function is called in the first platform, the jump access address of the caller is repositioned to the target library function in the first platform, i.e., the target library function in the second type of dynamic library in the memory; when the target library function is called in the second platform, the jump access address of the caller is repositioned to the target library function in the second platform, i.e., the target library function in the fourth type of dynamic library in the memory. In this way, for the same platform version of the library function call, the dynamic binary translator can directly call the library function from the memory without performing the translation operation, thereby improving the library function call efficiency.

[0015] Optionally, before the function call request of the target library function is responded, the method further includes: obtaining a corresponding address interval of each dynamic library in the memory, the second type of dynamic library, the third type of dynamic library and the fourth type of dynamic library; determining a plurality of global variables included in the second type of dynamic library, the third type of dynamic library and the fourth type of dynamic library; for each global variable in the plurality of global variables, repositioning a corresponding variable access address of the global variable in the memory based on the dynamic library to which the global variable belongs and the corresponding address interval of each dynamic library in the memory.

[0016] Optionally, the repositioning of the corresponding variable access address of the global variable in the memory based on the dynamic library to which the global variable belongs and the corresponding address interval of each dynamic library in the memory includes:

[0017] If the target application program and / or the library function in the third type of dynamic library access the global variable, the variable access address of the global variable is set to the corresponding memory address of the global variable in the second type of dynamic library; or, if the target application program and / or the library function in the third type of dynamic library access the global variable, the variable access address of the global variable is set to the corresponding memory address of the global variable in the fourth type of dynamic library.

[0018] That is, since one global variable can be shared in multiple dynamic libraries, for each global variable, a unique variable access address thereof in the memory needs to be defined, so that the library function accessing the global variable accesses the global variable through the variable access address.

[0019] Optionally, loading the second type of dynamic library, the third type of dynamic library, and the fourth type of dynamic library into the memory of the second platform includes: obtaining the dynamic libraries already loaded in the memory; determining, based on the loaded dynamic libraries, whether a first dynamic library has been loaded into the memory, wherein the first dynamic library is any one of the second type of dynamic library, the third type of dynamic library, and the fourth type of dynamic library; and if the first dynamic library has not been loaded into the memory, then loading the first dynamic library into the memory.

[0020] Optionally, the loaded dynamic library includes a second dynamic library; determining whether the first dynamic library has been loaded into memory based on the loaded dynamic library includes: if the first dynamic library and the second dynamic library have the same library name, and the second dynamic library is a dynamic library of the first type, then it is determined that the first dynamic library has been loaded into memory; if the first dynamic library and the second dynamic library have the same library name, and the first dynamic library and the second dynamic library belong to the same platform, then it is determined that the first dynamic library has been loaded into memory.

[0021] Optionally, before loading the first dynamic library into the memory, the method further includes: determining the platform information of the platform to which the first dynamic library belongs; if the platform information indicates that the platform to which the first dynamic library belongs includes the first platform and / or the second platform, then the first dynamic library is determined to be a valid dynamic library, and the step of loading the first dynamic library into the memory is performed.

[0022] Therefore, this application, based on the dynamic libraries that the target application depends on at runtime, determines the second, third, and fourth types of dynamic libraries required to load when the target application runs on the second platform. Before loading these dynamic libraries into the memory of the second platform, it is necessary to filter out those not loaded into memory, and then perform a validity check on the filtered dynamic libraries. Finally, those dynamic libraries that are not loaded into memory but are determined to be valid are loaded into memory. This ensures the accuracy of dynamic library loading and improves the efficiency of loading dynamic libraries into memory.

[0023] Secondly, a library function calling apparatus is provided, which has the function of implementing the library function calling method behavior described in the first aspect above. The library function calling apparatus includes at least one module, which is used to implement the library function calling method provided in the first aspect above.

[0024] Thirdly, a computer device is provided, comprising a processor and a memory, the memory being used to store a computer program for executing the library function calling method provided in the first aspect. The processor is configured to execute the computer program stored in the memory to implement the library function calling method described in the first aspect.

[0025] Optionally, the computer device may further include a communication bus for establishing a connection between the processor and the memory.

[0026] Fourthly, a computer-readable storage medium is provided, wherein the storage medium stores instructions that, when executed on a computer, cause the computer to perform the steps of the library function call method described in the first aspect.

[0027] Fifthly, a computer program product containing instructions is provided, which, when executed on a computer, cause the computer to perform the steps of the library function call method described in the first aspect. Alternatively, a computer program is provided that, when executed on a computer, causes the computer to perform the steps of the library function call method described in the first aspect.

[0028] The technical effects achieved by the second, third, fourth, and fifth aspects mentioned above are similar to those achieved by the corresponding technical means in the first aspect, and will not be repeated here. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of a local pass-through of a library function provided in an embodiment of this application;

[0030] Figure 2 This is a schematic diagram of another library function local pass-through provided in an embodiment of this application;

[0031] Figure 3 This is a schematic diagram of local pass-through of library functions in a dynamic library in the related technology provided in the embodiments of this application;

[0032] Figure 4 This is a schematic diagram of an implementation environment provided in an embodiment of this application;

[0033] Figure 5 This is a schematic diagram of another implementation environment provided in the embodiments of this application;

[0034] Figure 6 This is a flowchart illustrating a library function calling method provided in an embodiment of this application;

[0035] Figure 7 This is a schematic diagram illustrating the loading process of a dynamic library that a target application depends on, as provided in an embodiment of this application.

[0036] Figure 8 This is a schematic diagram of a library function relocation process provided in an embodiment of this application;

[0037] Figure 9 This is a schematic diagram of a global variable relocation process provided in an embodiment of this application;

[0038] Figure 10 This is a schematic diagram of a transparent library function call flow provided in an embodiment of this application;

[0039] Figure 11 This is a schematic diagram illustrating how a dynamic linker loads a dynamic library, as provided in an embodiment of this application.

[0040] Figure 12 This is a schematic diagram illustrating another dynamic linker loading dynamic library provided in an embodiment of this application;

[0041] Figure 13 This is a schematic diagram illustrating the logic of calling library functions during application execution, provided in an embodiment of this application.

[0042] Figure 14 This is a schematic diagram of the structure of a library function calling device provided in an embodiment of this application. Detailed Implementation

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

[0044] To facilitate understanding, before explaining the library function calling methods provided in this application, the application background and implementation environment involved in the embodiments of this application will be introduced first.

[0045] First, the relevant background of the embodiments of this application will be introduced.

[0046] With the development and evolution of processor architectures, more and more processors with new architectures have emerged in the industry. While the emergence of new architectures brings opportunities for the diversified development of processors, it also brings challenges to the software ecosystem. New architecture processors face many challenges in running existing software compatiblely, including the difficulty of recompiling source code, the unavailability of source code, and compatibility issues with compilers. To solve these problems, binary translation technology provides an effective solution. By translating directly at the machine code level, it achieves cross-platform software compatibility, improving the processor's flexibility and application scope.

[0047] Binary translation is the process of converting a program from one binary format to another. Depending on the object being translated, binary translation can be divided into system-level translation and user-level translation. System-level translation translates the entire application runtime environment, including the operating system, memory management, peripheral interfaces, and system calls; while user-level translation focuses on the binary code translation of a specific user-level process, only concerned with the executable code of that particular process, without involving the entire operating system or runtime environment. Because system-level translation involves the entire application runtime environment, while user-level translation only focuses on the binary code of a specific process, user-level translation is generally more efficient. System-level translation, although more complex, is more robust in ensuring overall compatibility and runtime environment consistency. Depending on the timing of the translation, binary translation can be divided into static translation and dynamic translation. Static translation refers to the process of translating the source code or binary code of a program into target code in one go before the program is executed. This translation is "static" because it is completed before the program actually runs. Dynamic translation, on the other hand, refers to the strategy of performing just-in-time (JIT) compilation on binary code during program execution. Dynamic translation can obtain complete control flow information during program execution and optimize the code accordingly.

[0048] For user-level dynamic translation technology, a dynamic binary translator (DBT) requires versions of the application and all its dependent dynamic libraries (also known as shared libraries, a type of executable file) on the client platform when translating and executing an application. These dynamic libraries typically contain the functions and data structures required for the application to function correctly. Therefore, if one or more of the application's dependent dynamic libraries are missing on the client platform, the dynamic binary translator cannot find the necessary functions and data structures to complete the translation, thus preventing the entire application from being translated and executed by the dynamic binary translator.

[0049] For example, when some hardware manufacturers launch new network cards, graphics processing units (GPUs), or other hardware products, they usually provide drivers or middleware for the corresponding architecture of the hardware. However, these drivers or middleware often only contain kernel-mode code and do not provide user-mode drivers (i.e., user-mode dynamic libraries).

[0050] To resolve the issue of missing dynamic libraries on the customer's platform, please refer to [link / reference]. Figure 1When an application runs on a host platform, the host platform can use a dynamic binary translator to perform "local library function pass-through," redirecting calls to missing dynamic libraries to the corresponding dynamic libraries on the host platform. In other words, when an application attempts to call a library function in a missing dynamic library on the client platform, the dynamic binary translator intercepts the call and redirects it to a dynamic library with the same or similar functionality that already exists on the host platform. In this way, even if the dynamic libraries the application depends on are missing on the client platform, the application can still run on the host platform through this pass-through mechanism.

[0051] Furthermore, dynamic binary translators consume computational resources, including CPU time and memory (also known as translation overhead), in the process of converting one type of machine code (i.e., compiled target code) into another type of machine code (e.g., code from another central processing unit (CPU) architecture), which directly impacts software performance. Figure 2 As shown, during the process of a dynamic binary translator translating the source machine code of a target application (i.e., the machine code compiled on the client platform), the generated machine code (i.e., the machine code that the host platform can execute) may be larger than the source machine code, resulting in code bloat. Code bloat not only increases memory usage but may also affect the efficiency of the instruction cache. Although many compilation optimization schemes exist, such as dead code elimination, loop unrolling, and constant folding, these optimizations can improve the performance of the generated code to some extent. However, in the context of binary translation, due to translation overhead and code bloat, these optimizations are unlikely to achieve the performance of native execution (i.e., compiling and running directly on the source machine).

[0052] Therefore, to directly leverage the performance advantages of native code and reduce the overhead of translation, the dynamic binary translator passes through library function calls during application runtime to the corresponding dynamic libraries on the host platform. Here, "passing through" means that during the instruction translation process, when the dynamic binary translator encounters a call to a library function, it doesn't perform an actual translation but directly jumps to the corresponding library function with the same functionality on the host platform for execution. Thus, local passing through of library functions not only solves the problem of missing dynamic libraries on the client platform but also improves the efficiency of binary translation.

[0053] In some related technologies, the Box86 / 64 binary translator can use a local library function pass-through method to run executable binary programs compiled under the x86 architecture (client platform) on the ARM architecture (host platform). When the executable binary program needs to call a library function, if the library function is a function in a dynamic library on the client platform, the Box86 / 64 binary translator performs instruction translation to translate the instructions of the library function on the client platform into the corresponding instructions on the host platform, and then executes those instructions. If the library function is a function in a dynamic library missing from the client platform, or a function in a dynamic library that the missing dynamic library depends on, the Box86 / 64 binary translator uses a local library function pass-through method to pass the call operation of the library function to a library function with the same function interface on the host platform. That is, the Box86 / 64 binary translator does not perform instruction translation and directly calls the library function with the same function interface on the host platform.

[0054] Box86 and Box64 are dynamic binary translators designed for the Linux platform. They allow the execution of binaries compiled for x86 or x86_64 architectures on ARM architectures (ARM32 for Box86, ARM64 for Box64). When translating instructions from x86 / x86_64 to ARM, the Box86 / 64 binary translator encounters situations where it needs to call corresponding library functions in the ARM architecture. To handle this, the Box86 / 64 binary translator uses some hand-written, complex wrapper functions to correct the calls to ARM library functions on the host platform.

[0055] It's important to note that in the Box86 / 64 context, a wrapper function is a special type of function that acts as a "wrapper" or "adapter" for calls to original library functions in x86 / x86_64 programs. That is, ARM and x86 / x86_64 architectures differ in function calling conventions, parameter passing, and return value handling. Directly using ARM library functions may not meet the needs of x86 / x86_64 programs. The role of wrapper functions is to bridge these differences, ensuring that x86 / x86_64 programs can correctly call functions on the ARM architecture.

[0056] As an example, the following types of library functions require wrapper functions to perform operations such as function parameter parsing and parameter reconstruction in order to call the corresponding library functions on the host platform.

[0057] (1) Library functions with variable arguments (e.g., printf, scanf, etc.)

[0058] These library functions accept a variable list of arguments, typically implemented using C's `stdarg.h` or `stdarg` macros. In the translation environment of a Box86 / 64 binary translator, the native variable-argument functions cannot be called directly because the emulation or translation layer needs to know the type and value of each parameter. Therefore, a wrapper function needs to be written that accepts a fixed list of arguments and then passes those arguments to the underlying native library functions on the host platform.

[0059] (2) Functions that depend on heterogeneous structures of different sizes

[0060] On different processor architectures (such as ARM and x86), even the same data structure may have different memory layouts and alignment requirements. Directly passing a structure to the host platform's native library functions may lead to data corruption or undefined behavior. Therefore, wrapper functions need to be constructed to handle these differences to ensure that the data structure is correct before being passed to the host platform's native library functions.

[0061] (3) Functions containing callbacks

[0062] If a library function accepts a callback function as an argument, and considering that the callback function may depend on the client platform's code or data, and that the callback function may be executed in a library function on the host platform, it is necessary to construct a wrapper function for the library function to ensure that the callback function is passed and executed correctly.

[0063] (4) Library functions that need to be handled by the dynamic binary translator

[0064] Library functions that perform memory operations (e.g., malloc) and input / output (I / O) operations (e.g., open) typically involve the allocation and management of low-level resources. These resources may have different semantics or implementations in the simulation or translation environment. Therefore, the simulation or translation layer usually needs to intercept the calls to these library functions to ensure they function as expected. Based on this, wrapper functions for these library functions need to be constructed to intercept their calls, pass them to the translator or simulation layer for processing, and then return the results to the caller.

[0065] However, constructing a wrapper function is a rather complex process. When the library function has source code, a lot of adaptation development work is required. For example, the base library (such as the C standard library) usually contains the library functions of the types mentioned above (1)-(4). If the base library performs local pass-through of library functions, it is a very time-consuming and labor-intensive task. When the library function does not have source code, the wrapper function cannot guarantee that two library functions with the same function interface have the same functionality on the client platform and the host platform. Therefore, it is impossible to construct the corresponding wrapper function.

[0066] Furthermore, in the aforementioned solution for porting the Box86 / 64 binary translator application, dynamic libraries that are missing on the client platform but have already been passed through must also have their dependent dynamic libraries passed through.

[0067] As an example, such as Figure 3 As shown, if an application on the client platform needs to run on the host platform using a Box86 / 64 binary translator, and the root library is missing on the client platform, local pass-through of library functions is required. During application execution or when library functions in the root library are running, they may call library functions in libraries A and B. If the execution of a library function in the root library requires calling library functions in libraries A and / or B, meaning the root library depends on libraries A and / or B, local pass-through of library functions is performed for the root library. Simultaneously, local pass-through of library functions in its dependent libraries A and / or B is also mandatory; that is, the pass-through list must include the root library, library A, and library B.

[0068] In this scenario, the corresponding root library, library A, and library B on the host platform need to be loaded into memory. Wrapper functions for each library (root, A, and B) must be provided to enable the invocation of these library functions. As mentioned earlier, if the source code of the library functions in libraries A and B cannot be obtained when the root library depends on them, it is impossible to construct wrappers to achieve local pass-through of library functions in libraries A and B, which in turn prevents the local pass-through of library functions in the root library from being implemented.

[0069] Based on this, this application provides a library function calling method. When migrating a target application from a first platform to a second platform, the dynamic libraries that the target application depends on are first determined. These dynamic libraries include a first type of dynamic library that needs to be passed through and a second type of dynamic library that does not need to be passed through. Then, the second type of dynamic library from the first platform is loaded into the memory of the second platform, and a third type of dynamic library from the second platform containing library functions with the same functionality as the first type of dynamic library, as well as a fourth type of dynamic library from the second platform containing library functions with the same functionality as the second type of dynamic library, are also loaded into memory. In this case, if the target library function includes library functions with the same functionality in the second and fourth type of dynamic libraries, in response to a function call request for the target library function, if the function call request is triggered by the target application, the target library function is called from the second type of dynamic library in memory; if the function call request is triggered by a library function in the third type of dynamic library, the target library function is called from the fourth type of dynamic library in memory.

[0070] Therefore, the library function calling scheme provided in this application only requires local pass-through of library functions for the first type of dynamic library on the first platform. For the second type of dynamic library on the first platform, both the second type of dynamic library and the fourth type of dynamic library with the same function on the second platform are directly loaded into memory, without the need for local pass-through of the second type of dynamic library. Naturally, there is no need to obtain the source code of the library functions in the second type of dynamic library to construct the wrapper function. In this way, the workload of constructing the wrapper function when the target application is ported from one platform to another is greatly reduced, and the normal operation of the target application on the second platform is guaranteed.

[0071] As an example, see above. Figure 3The library function calling scheme provided in this application embodiment only needs to pass the library function locally to the root library, A library and B library that the application depends on when processing the root library, A library and B library that the application depends on. It does not need to pass the library function locally to the A library and B library that the root library depends on. That is, the pass-through list only contains the root library, and the dynamic libraries loaded into the memory of the host platform include: the root library of the host platform, the A library of the client platform, the B library of the client platform, the A library of the host platform and the B library of the host platform. Since the library function calling scheme provided in this application embodiment directly loads the dynamic libraries existing on the client platform, when the application runs on the host platform, considering that root is a dynamic library that is locally passed through to the library functions, it actually executes the library functions in the root library of the host platform. Therefore, if the root library calls the library functions in library A and / or library B, the host platform's library A and / or library B are loaded from memory. That is, the root library that performs the library function call operation and the called library A and / or library B have the same instruction set, so no translation operation is required, and they can be executed directly. If other dynamic libraries in the application (i.e., dynamic libraries existing on the first platform) call library A and / or library B, the client platform's library A and / or library B are loaded from memory. That is, the dynamic library that performs the library function call operation and the called library A and / or library B both have the instruction set corresponding to the client platform. At this time, the binary translator performs instruction translation and then executes the code.

[0072] Next, the implementation environment of the embodiments of this application will be described.

[0073] Please refer to Figure 4 , Figure 4 This is a schematic diagram illustrating an implementation environment according to an embodiment of this application. The implementation environment includes a computer device, which may be a terminal or a server, etc. The computer device includes at least one processor 101, a communication bus 102, a memory 103, and at least one communication interface 104.

[0074] Processor 101 can be a general-purpose central processing unit (CPU), a network processor (NP), a microprocessor, or one or more integrated circuits for implementing the solutions of this application, such as application-specific integrated circuits (ASICs), programmable logic devices (PLDs), or combinations thereof. The aforementioned PLD can be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0075] The communication bus 102 is used to transmit information between the aforementioned components. The communication bus 102 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 4 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0076] The memory 103 may be a read-only memory (ROM), a random access memory (RAM), an electrically erasable programmable read-only memory (EEPROM), an optical disc (including a compact disc read-only memory (CD-ROM), a compressed optical disc, a laser disc, a digital versatile optical disc, a Blu-ray disc, etc.), a magnetic disk storage medium, or other magnetic storage device, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but not limited thereto. The memory 103 may exist independently and be connected to the processor 101 via the communication bus 102. The memory 103 may also be integrated with the processor 101.

[0077] Communication interface 104 uses any transceiver-like device for communicating with other devices or communication networks. Communication interface 104 includes a wired communication interface and may also include a wireless communication interface. The wired communication interface may be, for example, an Ethernet interface. The Ethernet interface may be an optical interface, an electrical interface, or a combination thereof. The wireless communication interface may be a wireless local area network (WLAN) interface, a cellular network communication interface, or a combination thereof.

[0078] As an example, processor 101 may include one or more CPUs, such as Figure 4 CPU0 and CPU1 are shown in the diagram.

[0079] As an example, a computer device may include multiple processors, such as Figure 4 The processors 101 and 105 shown are illustrated. Each of these processors may be a single-core processor or a multi-core processor. Here, "processor" may refer to one or more devices, circuits, and / or processing cores used to process data (such as computer program instructions).

[0080] In some embodiments, the computer device may further include output devices and input devices. The output device communicates with the processor 101 and can display information in various ways. For example, the output device may be a liquid crystal display (LCD), a light-emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector, etc. The input device communicates with the processor 101 and can receive user input in various ways. For example, the input device may be a mouse, keyboard, touchscreen device, or sensing device, etc.

[0081] In some embodiments, memory 103 is used to store program code 110 for executing the scheme of this application, and processor 101 can execute the program code 110 stored in memory 103. The program code 110 may include one or more software modules, and the computer device can implement the following by using processor 101 and the program code 110 in memory 103. Figure 6 The library function calling method provided in the example.

[0082] In some embodiments, the library function calling method provided in this application can be applied to a dynamic binary translator in a computer device. Taking the x86 platform as the client platform and the ARM platform as the host platform as an example, as follows... Figure 5As shown, the dynamic binary translator sits between x86 applications and the ARM-based Linux operating system. The dynamic binary translator can translate the instructions of x86 applications at runtime into AArch64-compatible instructions (AArch64 is the 64-bit execution state in the ARMv8 architecture, supporting the A64 instruction set). It can run x86 32 / 64-bit applications and x86 containers of the Linux operating system on ARM64 hardware and operating system, and can also run Windows x86 applications.

[0083] It should be understood that the computing device architecture and related application scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of computing device architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0084] After introducing the application background and implementation environment involved in the embodiments of this application, the library function calling method provided in the embodiments of this application will be explained in detail below.

[0085] Please refer to Figure 6 , Figure 6 This is a flowchart of a library function calling method provided in an embodiment of this application. The method is applied to... Figure 4 In the computer device shown, the method includes the following steps.

[0086] Step 601: Determine the dynamic libraries that the target application depends on at runtime. The target application is an application migrated from the first platform to the second platform. The system architectures of the first platform and the second platform are different. The dynamic libraries include the first type of dynamic libraries that need to be passed through and the second type of dynamic libraries that do not need to be passed through. The pass-through instruction is to implement the functionality of the corresponding library functions in the first platform through the library functions in the second platform.

[0087] In this embodiment, the difference in system architecture between the first platform and the second platform refers to the difference in the processor architecture corresponding to the first platform and the second platform. For example, the first platform is an x86 architecture, and the second platform is an ARM architecture.

[0088] Regarding the preceding text Figures 1-3 In the application porting scenario shown, the first platform in this application embodiment can be the client platform in the previous example, the second platform can be the host platform in the previous example, and the target application is an executable binary program compiled on the client platform, that is, the machine code corresponding to the target application on the client platform.

[0089] In some embodiments, both the first type of dynamic library and the second type of dynamic library are dynamic libraries that the target application depends on for execution. The first type of dynamic library is one that is missing in the first platform and needs to be passed through. That is, when the target application is running on the second platform, if it needs to call a library function in the first type of dynamic library, it can directly call the library function with the same function in the second platform through the dynamic binary translator. The second type of dynamic library is one that exists in the first platform and does not need to be passed through locally. When the target application is running on the second platform, if it needs to call a library function in the second type of dynamic library, the dynamic binary translator can translate and execute the instructions of the library function.

[0090] Optionally, if all the dynamic libraries that the target application depends on exist on the first platform, it is also possible to determine which of these dependent dynamic libraries are first-type dynamic libraries that need to be passed through and which are second-type dynamic libraries that do not need to be passed through, based on whether the source code of the library functions can be obtained. This application does not impose any limitations on this.

[0091] In some embodiments, the second type of dynamic library includes dynamic libraries that the first type of dynamic library needs to call to run; that is, when a library function in the first type of dynamic library runs, it may call a library function in the second type of dynamic library. In other words, when the target application runs on the first platform, both the target application and the first type of dynamic library may call library functions in the second type of dynamic library.

[0092] Optionally, the second type of dynamic library can be a specific dynamic library that the target application depends on at runtime, meaning that the library functions in this dynamic library only serve the target application. Of course, the second type of dynamic library can also be a base dynamic library that the target application and other applications depend on at runtime, meaning that the library functions in this base library can be shared among multiple applications, and these applications can all call the library functions in the base library when implementing certain functions. This application does not impose any limitations on this.

[0093] Step 602: Load the second type of dynamic library, the third type of dynamic library, and the fourth type of dynamic library into the memory of the second platform. The third type of dynamic library is a dynamic library in the second platform that contains the same library functions as the first type of dynamic library. The fourth type of dynamic library is a dynamic library in the second platform that contains the same library functions as the second type of dynamic library.

[0094] It should be noted that when the processor architectures corresponding to the first and second platforms are different, the only difference between the third type of dynamic library and the first type of dynamic library is the instruction set corresponding to the library functions. However, the same library functions in the third type of dynamic library and the first type of dynamic library can achieve exactly the same functionality. For example, for library function N, in the first type of dynamic library, library function N is implemented using the instruction set of the x86 architecture, while in the third type of dynamic library, library function N is implemented using the instruction set of the ARM architecture.

[0095] Similarly, the only difference between the second type of dynamic library and the fourth type of dynamic library is the instruction set corresponding to the library function. However, the same library function in the second type of dynamic library and the fourth type of dynamic library can achieve the same functionality.

[0096] In one possible implementation, step 602 may include the following steps:

[0097] (1) Obtain the dynamic libraries that are already loaded in memory.

[0098] For the second platform, before running the target application, it will also run applications compiled for its own platform, or applications compiled for other platforms (including but not limited to the first platform), thereby loading some dynamic libraries into memory. Based on this, when performing step 602 above, in order to avoid the duplicate loading of the same dynamic libraries, it can be determined whether the dynamic libraries included in the second type, third type, and fourth type of dynamic libraries have been loaded into memory based on the dynamic libraries already loaded in memory.

[0099] (2) Based on the dynamic libraries already loaded in memory, determine whether the first dynamic library has been loaded into memory.

[0100] The first dynamic library is any one of the dynamic libraries included in the second, third, and fourth categories. That is, for the dynamic libraries already loaded in memory, it is determined whether each of the second, third, and fourth categories has been loaded into memory.

[0101] Since the logic for determining whether each dynamic library has been loaded into memory is similar, the following explanation will focus on the implementation process of determining whether the first dynamic library has been loaded into memory based on the second dynamic library, taking the second dynamic library as an example of dynamic libraries already loaded into memory.

[0102] In one possible implementation, the process of determining whether the first dynamic library has been loaded into memory can be as follows: if the first dynamic library and the second dynamic library have the same library name, and the second dynamic library is a first type of dynamic library, then it is determined that the first dynamic library has been loaded into memory; if the first dynamic library and the second dynamic library have the same library name, and the first dynamic library and the second dynamic library belong to the same platform, then it is determined that the first dynamic library has been loaded into memory.

[0103] Since the first dynamic library belongs to a different type of dynamic library, when determining whether it has been loaded into memory according to the above logic, the following three situations may occur:

[0104] In the first scenario, the first dynamic library is any one of the second type of dynamic libraries. In this case, since the first dynamic library is not a first-type dynamic library, determining whether it has been loaded into memory requires not only checking if the library names of the first and second dynamic libraries are the same, but also checking if the platforms to which the first and second dynamic libraries belong are the same.

[0105] Based on this, when the second dynamic library loaded in memory has the same library name as the first dynamic library and belongs to the same platform (i.e., the first platform), it means that the first dynamic library has been loaded into memory in the historical process.

[0106] In the second scenario, if the first dynamic library is any one of the third type of dynamic libraries, then the first dynamic library is the one that needs to be passed through. In memory, it only needs to load the dynamic library with the same functionality from the second platform. Therefore, when determining whether the first dynamic library has been loaded into memory, it is only necessary to check if the library names of the first and second dynamic libraries are the same.

[0107] Therefore, if the second dynamic library loaded in memory has the same library name as the first dynamic library, it means that the first dynamic library has been loaded into memory in the historical process.

[0108] The third scenario is if the first dynamic library is any one of the fourth type of dynamic libraries. In this case, since the first dynamic library is not a first type of dynamic library, when determining whether the first dynamic library has been loaded into memory, it is necessary not only to determine whether the library names of the first and second dynamic libraries are the same, but also to determine whether the platforms to which the first and second dynamic libraries belong are the same.

[0109] Based on this, when the second dynamic library loaded in memory has the same library name as the first dynamic library and belongs to the same platform (i.e., the second platform), it means that the first dynamic library has been loaded into memory in the historical process.

[0110] As an example, assuming the first dynamic library is La and the second dynamic library is Lb, the condition for determining that La has been loaded into memory can be expressed as: (La and Lb have the same library name) && (La and Lb have the same system architecture || Lb is a pass-through dynamic library).

[0111] (3) If the first dynamic library is not loaded into memory, then load the first dynamic library into memory.

[0112] If it is determined that the first dynamic library is not loaded into memory, the first dynamic library also needs to be validated for legality, that is, to verify whether the first dynamic library belongs to the first platform or the second platform, so as to avoid loading dynamic libraries with the same name from other platforms.

[0113] In one possible implementation, the process of validating the first platform can be as follows: determine the platform information of the platform to which the first dynamic library belongs; if the platform information indicates that the platform to which the first dynamic library belongs includes the first platform and / or the second platform, then determine that the first dynamic library is a valid dynamic library, and perform the step of loading the first dynamic library into memory.

[0114] Therefore, this embodiment of the application determines the second, third, and fourth types of dynamic libraries required to load when the target application runs on the second platform based on the dynamic libraries it depends on at runtime. Before loading these dynamic libraries into the memory of the second platform, the application filters out those not already loaded in memory and performs a validity check on the filtered libraries. Finally, the dynamic libraries from the second, third, and fourth types that are not yet loaded into memory and are determined to be valid are loaded into memory. This ensures the accuracy of dynamic library loading and improves the efficiency of loading dynamic libraries into memory.

[0115] Based on step 602 above, see Figure 7The library functions provided in this application, after parsing the target application and determining the second, third, and fourth types of dynamic libraries that need to be loaded into memory, for any one of the second, third, and fourth types of dynamic libraries (e.g., the first dynamic library), determine whether the first dynamic library has already been loaded into memory based on the dynamic libraries already loaded in memory. If the first dynamic library has been loaded into memory, there is no need to reload it; the symbols in the first dynamic library can be directly relocated. If the first dynamic library has not been loaded into memory, it is necessary to further determine whether the first dynamic library is a valid dynamic library, i.e., whether the platform to which the first dynamic library belongs is the first platform and / or the second platform. If the first dynamic library is not a valid dynamic library, it is not loaded into memory; if it is a valid dynamic library, it is loaded into memory, and memory address mapping is performed on the library file of the first dynamic library, as well as the memory access addresses of the characters in the first dynamic library are relocated.

[0116] The first dynamic library is itself an executable file. Loading the first dynamic library into memory essentially involves determining the address range corresponding to the executable file in memory and mapping the executable file to that address range. The characters in the first dynamic library include library function names, variable names, etc., which are not limited in this embodiment.

[0117] It should be noted that during the loading of Type II, Type III, and Type IV dynamic libraries into memory, situations may arise where multiple dynamic libraries contain library functions with the same functionality. When these functions are called in the target application's code, it is necessary to define which dynamic library's library function should be invoked. For example, Type II and Type IV dynamic libraries may include library functions or global variables with the same functionality; therefore, it is necessary to define the memory access address when calling the library function, i.e., to define which platform's library function should be invoked.

[0118] In one possible implementation, when multiple dynamic libraries exist and contain library functions with the same functionality, it is ensured in some way that the desired library function in the dynamic library is called at runtime. This usually involves symbol lookup and relocation.

[0119] Symbol lookup refers to the process of finding the definitions of all symbols (including function names, variable names, etc.) used in the target application during the linking of dynamic libraries. These symbols may be defined in multiple different dynamic libraries or object library files. At this time, the dynamic binary translator will search for the definitions of these symbols according to specific rules (such as the order on the linker command line, the library search path, etc.). Relocation refers to the process of associating these definitions with references in the target application after the linker has found all the symbol definitions. During the relocation process, the linker will modify the symbol references in the target application to point to the correct memory address (i.e., the memory address where the symbol definition is located).

[0120] Therefore, before performing step 603 below, for dynamic libraries loaded into memory, it is necessary to relocate the memory access address of each library function or global variable. The following section explains the implementation process of relocating the jump access address when a library function calls other library functions, and relocating the variable access address of global variables.

[0121] In some embodiments, the process of relocating the jump access address of a library function can be as follows: obtaining the address range in memory corresponding to each of the second, third, and fourth types of dynamic libraries; determining the function call relationship of the multiple library functions based on the multiple library functions included in the second, third, and fourth types of dynamic libraries; and relocating the jump access address corresponding to each of the multiple library functions based on the function call relationship and the address range in memory corresponding to each dynamic library, wherein the jump access address indicates the address in memory of other library functions called by the corresponding library function during runtime.

[0122] Regarding the third type of dynamic library, since it only loads one platform version of the dynamic library in memory, there are no dynamic libraries with different platform architectures and the same library function name. Therefore, when relocating the library functions in the third type of dynamic library, the address of the called library function in memory can be set as the jump access address of the caller directly according to the function call relationship.

[0123] As an example, if library function P needs to call library function Q during the execution of the target application, and library function Q is any library function in the third type of dynamic library, then the memory address of library function Q is filled into the target address of library function P as the jump access address of library function P.

[0124] Regarding the second and fourth types of dynamic libraries, since they contain library functions with the same functionality, when the target library function with the same functionality is called from the second or fourth type of dynamic library, it is necessary to determine the jump access address in memory when calling the target library function based on the platform version of the caller.

[0125] In the first scenario, multiple library functions include the first library function in the target application, and the function call relationship indicates that the first library function needs to call the target library function at runtime. In this case, the caller is the first library function, and its platform is the first platform. The process of relocating the jump access address of the first library function can be as follows: based on the address range corresponding to the second type of dynamic library in memory and the offset address of the target library function, determine the function access address of the target library function; set this function access address as the jump access address for the first library function to call the target library function.

[0126] In the second scenario, multiple library functions include the second library function within the third type of dynamic library, and the function call relationship indicates that the second library function needs to call the target library function. In this case, the caller is the second library function, and its platform is the second platform. The process of relocating the jump access address of the second library function can be as follows: based on the address range corresponding to the fourth type of dynamic library in memory and the offset address of the target library function, determine the function access address of the target library function; set this function access address as the jump access address for the second library function to call the target library function.

[0127] Therefore, in this embodiment of the application, when calling a target library function that exists in memory for two platform versions, the jump address of the caller needs to be set to the address of the target library function in memory for the corresponding platform, based on the platform to which the caller belongs. In other words, when code on the first platform calls the target library function, its jump address is relocated to the target library function on the first platform, i.e., the target library function in the second type of dynamic library in memory; when code on the second platform calls the target library function, its jump address is relocated to the target library function on the second platform, i.e., the target library function in the fourth type of dynamic library in memory. Thus, for library function calls of the same platform version, the dynamic binary translator can directly call the library function from memory without performing a translation operation, improving the efficiency of library function calls.

[0128] Based on the explanation of the library function relocation process above, the following section, in conjunction with the appendix... Figure 8 The relocation process of library functions in each of the second, third, and fourth types of dynamic libraries is illustrated with examples.

[0129] Please refer to Figure 8For any library function among the second, third, and fourth types of dynamic libraries, an address lookup can be performed based on the function name. If the function access address is found in memory, it is determined whether the function access address is located in the local pass-through library (i.e., the third type of dynamic library passed through to the second platform), specifically whether it is within the address range corresponding to the local pass-through library. If the function access address is located in the local pass-through library, the relocation address of the library function is set as the entry address of the trampoline in the dynamic binary translation. Subsequent calls to the library function will then be made directly through the trampoline in the dynamic binary translation without requiring a translation operation. If the function access address is not located in the local pass-through library, it is further determined whether the function access address belongs to the same platform as the caller's dynamic library. If the dynamic library pointed to by the function access address of the library function belongs to the same platform as the caller's dynamic library, then the relocation address of the library function is set to the found function access address; if the dynamic library pointed to by the function access address of the library function does not belong to the same platform as the caller's dynamic library, then the library function is skipped and the search continues for the function access address of the next library function in memory.

[0130] In this context, both the caller and the called library function can be any library function in the target application. For example, the caller can be any library function from the second, third, and fourth types of dynamic libraries mentioned above, and it must be different from the called library function.

[0131] During the library function relocation process described above, if the function access address of a certain library function cannot be found in memory, an error will be reported to prompt the user that the library function may not have been loaded into memory.

[0132] In some embodiments, the process of relocating the variable access address of a global variable can be as follows: obtaining the address range in memory corresponding to each of the second, third, and fourth type dynamic libraries; determining the multiple global variables included in the second, third, and fourth type dynamic libraries; and for each of the multiple global variables, relocating the variable access address in memory corresponding to the global variable based on the dynamic library to which the global variable belongs and the address range in memory corresponding to each dynamic library.

[0133] In other words, since a global variable may be shared in multiple dynamic libraries, it is necessary to define a unique variable access address in memory for each global variable so that library functions accessing the global variable can access it through this variable access address.

[0134] In one possible implementation, if a library function in the target application and / or the third type of dynamic library accesses a global variable, the access address of the global variable is set to the memory address corresponding to the global variable in the second type of dynamic library; or, if a library function in the target application and / or the third type of dynamic library accesses a global variable, the access address of the global variable is set to the memory address corresponding to the global variable in the fourth type of dynamic library.

[0135] As an example, such as Figure 9 As shown, for any global variable in the second, third, and fourth type of dynamic libraries, an address lookup can be performed based on the variable name. If the access address of the global variable is found in memory, it is determined whether the access address is located in the local pass-through library (i.e., the third type of dynamic library passed through to the second platform), that is, whether it is within the address range corresponding to the local pass-through library. If the access address of the global variable is located in the local pass-through library, the relocation address of the global variable is set as the entry address of the trampoline in the dynamic binary translation, so that memory can be accessed through the trampoline in the dynamic binary translation when accessing the global variable later. If the access address of the global variable is not located in the local pass-through library, it is further determined whether the access address of the global variable is located in the dynamic library of the first platform, that is, whether it is within the address range corresponding to the second type of dynamic library. If the access address of a global variable is located in the dynamic library of the first platform, then the relocation address of the global variable is set to the found access address; if the access address of a global variable is not located in the dynamic library of the first platform, then the global variable is skipped and the search continues for the access address of the next global variable in memory.

[0136] Optionally, if the access address of a global variable is not located in the local pass-through library, then it is further determined whether the access address of the global variable is located in the dynamic library of the second platform, that is, whether it is located within the address range corresponding to the fourth type of dynamic library of the second platform. If the access address of the global variable is located in the dynamic library of the second platform, then the relocation address of the global variable is set to the found access address; if the access address of the global variable is not located in the dynamic library of the second platform, then the global variable is skipped, and the search for the next global variable's access address in memory continues.

[0137] During the global variable relocation process described above, if the access address of a certain global variable cannot be found in memory, an error will be reported to inform the user that the global variable may not have been loaded into memory.

[0138] Step 603: In response to a function call request from a target library function, if the function call request is triggered by the target application, call the target library function from the second type of dynamic library in memory; if the function call request is triggered by a library function in the third type of dynamic library, call the target library function from the fourth type of dynamic library in memory; wherein, the target library function includes library functions with the same function in the second type of dynamic library and the fourth type of dynamic library.

[0139] In other words, when a function call request is triggered by a library function on the first platform and requires calling the target library function from memory, the target library function on the first platform is called from memory; when a function call request is triggered by a library function on the second platform and requires calling the target library function from memory, the target library function on the second platform is called from memory. This ensures that when code on the second platform calls a library function, the dynamic binary translator can directly call the library function from memory without performing a translation operation.

[0140] In addition, such as Figure 10 As shown, assuming the first type of dynamic library includes dynamic library A.so, and it is necessary to call the library function funcA from dynamic library A.so, the implementation process may include the following steps:

[0141] S1: When the target application needs to perform a function and needs to call funcA, it will initiate a request through its normal function call mechanism. However, since the target application is running on a second platform, its instructions will be captured by the dynamic binary translator on the second platform and translated into instructions that the second platform can understand.

[0142] In practice, within the target application, a call to funcA first points to a special code segment called plt (procedure linking table). plt is a code table containing jump instructions used to redirect function calls to the actual function addresses. Furthermore, the jump instructions in plt transfer control flow to an entry in the global offset table (GOT).

[0143] The GOT table is a table used for storing the addresses of functions and variables in the repository, allowing the program to resolve symbol addresses at runtime.

[0144] S2: When the dynamic library A.so is loaded into memory, the dynamic linker is responsible for populating the GOT table.

[0145] In other words, for a dynamic library A.so that requires local pass-through of library functions, the dynamic linker will fill the entry for the jump module in the dynamic binary translator with the corresponding entry for funcA in the GOT table.

[0146] S3: When the control flow reaches the entry for funcA in the GOT table, it jumps to the jump module in the binary translator. This jump module then transfers the control flow to the symbol lookup module in the binary translator. The symbol lookup module searches for dynamic libraries on the second platform (local libraries with the same function as A.so, i.e., searching for the fourth type of dynamic library with the same function as the first type of dynamic library on the second platform) to find the actual access address of funcA.

[0147] S4: Once the address of funcA on the second platform is found, the dynamic binary translator constructs the appropriate parameters and calls funcA through the host platform's calling mechanism (such as system calls or function calls).

[0148] S5: After funcA finishes execution, it returns to the dynamic binary translator. At this point, the dynamic binary translator needs to process the return value of funcA.

[0149] S6: The dynamic binary translator saves the return value of funcA into the target application's context for use in subsequent execution. Then, the dynamic binary translator returns control flow to the next instruction in the target application that calls funcA and continues translating and executing the target application's instructions.

[0150] It should be noted that the specific implementation process of calling the corresponding library function in the second platform through the above-mentioned method of local pass-through of library functions can also refer to the relevant implementation process of local pass-through of library functions or the Box86 / 64 binary translator porting application. This application embodiment will not be repeated here.

[0151] In summary, in this embodiment, when migrating the target application from the first platform to the second platform, for the first type of dynamic libraries that need to be passed through and the second type of dynamic libraries that do not need to be passed through, when loading dynamic libraries into memory, for the first type of dynamic libraries that need to be passed through, a third type of dynamic library with the same function in the second platform is loaded into memory; for the second type of dynamic libraries that do not need to be passed through, the second type of dynamic library and a fourth type of dynamic library on the second platform that contains the same function as the second type of dynamic library are also loaded into memory. In this case, if the target library function includes library functions with the same function in the second and fourth type of dynamic libraries, in response to a function call request of the target library function, if the function call request is triggered by the target application, the target library function is called from the second type of dynamic library in memory; if the function call request is triggered by a library function in the third type of dynamic library, the target library function is called from the fourth type of dynamic library in memory. Therefore, the library function calling scheme provided in this application only requires local pass-through of library functions for the first type of dynamic library on the first platform. For the second type of dynamic library on the first platform, both the second type of dynamic library and the fourth type of dynamic library with the same function on the second platform are directly loaded into memory, eliminating the need for local pass-through of library functions for the second type of dynamic library. Consequently, there is no need to obtain the source code of the library functions in the second type of dynamic library to construct wrapper functions. This significantly reduces the workload of constructing wrapper functions when porting a target application from one platform to another, while ensuring that the target application can run normally on the second platform.

[0152] To facilitate understanding of the library function call logic shown in the above embodiments, the following will refer to the appendix. Figure 11 -Appendix Figure 13 The following examples will be used to supplement the explanation of the implementation process of dynamic library loading and library function calls.

[0153] Assume the first platform is the client platform and the second platform is the host platform. The target application depends on two dynamic libraries at runtime: library A (Guest Library A) and library B (Guest Library B) on the client platform. Guest Library A is a missing dynamic library on the client platform, requiring native library function pass-through to load and call library A (Host Library A) on the host platform. Furthermore, when the target application runs, Guest Library A needs to call library functions from library B, meaning Guest Library A depends on Guest Library B. Therefore, the process of loading the dynamic libraries required by the target application into the host platform's memory includes the following two scenarios.

[0154] In the first case, such as Figure 11 As shown, the dynamic binary translator uses the dynamic linker under the client platform architecture to perform dynamic library loading operations, so as to load Host LibraryA, Guest LibraryB and Host LibraryB, which are dependent on the target application to run, into memory.

[0155] In the second case, such as Figure 12 As shown, the dynamic binary translator uses the dynamic linker under the host platform architecture to perform dynamic library loading operations, so as to load Host LibraryA, Guest LibraryB and Host LibraryB, which are dependent on the target application, into memory.

[0156] That is, when executing the library function calling method provided in the embodiments of this application, after determining that the dynamic library needs to be loaded into the second platform, the library loading operation can be performed either through the dynamic linker in the first platform or through the dynamic linker in the second platform. The embodiments of this application do not impose any restrictions on this.

[0157] See when calling library functions. Figure 13 Assume the client platform is x86 architecture, the host platform is ARM architecture, and the x86 version of the high performance computing (HPC) application runs on the ARM version of the processor and has a high performance network card installed to perform high performance computing based on the message passing interface (MPI) library; moreover, the libc library is the C standard library, and both the MPI library and the HPC application will directly depend on the libc library.

[0158] Based on this, the HPC application runtime process can be as follows: When the HPC application starts, the x86 version of the dynamic linker loads the ARM version of the MPI library, the x86 version of the libc library, and the ARM version of the libc library into memory, and performs library function relocation. During runtime, HPC application calls to library functions in the MPI library are directly passed through the dynamic binary translator to the ARM version of the MPI library; that is, the x86 version of the HPC application directly calls the library functions in the local ARM version of the MPI library. When the ARM version of the MPI component library calls the libc library, it directly calls the ARM version of the libc library; and when the HPC application calls the libc library, it directly calls the x86 version of the libc library.

[0159] It should be noted that, regarding Figures 11-13 For the specific implementation logic of the relevant content, please refer to the above. Figure 6The descriptions in the illustrated method embodiments will not be repeated here.

[0160] Figure 14 This is a schematic diagram of a library function calling device provided in an embodiment of this application. This library function calling device can be implemented as part or all of a computer device by software, hardware, or a combination of both. See also... Figure 14 The device includes: a dynamic library determination module 1401, a dynamic library loading module 1402, and a library function calling module 1403.

[0161] The dynamic library determination module 1401 is used to determine the dynamic libraries that the target application depends on at runtime. The target application is an application migrated from a first platform to a second platform. The system architectures of the first platform and the second platform are different. The dynamic libraries include a first type of dynamic library that needs to be passed through and a second type of dynamic library that does not need to be passed through. The pass-through instruction is to implement the functions of the corresponding library functions in the first platform through the library functions in the second platform.

[0162] The dynamic library loading module 1402 is used to load the second type of dynamic library, the third type of dynamic library and the fourth type of dynamic library into memory. The third type of dynamic library is a dynamic library in the second platform that contains library functions with the same functions as the first type of dynamic library. The fourth type of dynamic library is a dynamic library in the second platform that contains library functions with the same functions as the second type of dynamic library.

[0163] The library function call module 1403 is used to respond to function call requests from target library functions. If the function call request is triggered by the target application, the target library function is called from the second type of dynamic library in memory; if the function call request is triggered by a library function in the third type of dynamic library, the target library function is called from the fourth type of dynamic library in memory. The target library function includes library functions with the same function in the second and fourth type of dynamic libraries.

[0164] Optionally, the library function calling device further includes:

[0165] The address acquisition module is used to obtain the address range in memory for each dynamic library in the second, third and fourth types of dynamic libraries.

[0166] The function relationship determination module is used to determine the function call relationship of multiple library functions based on the multiple library functions included in the second type of dynamic library, the third type of dynamic library, and the fourth type of dynamic library;

[0167] The function relocation module is used to relocate the jump access addresses corresponding to multiple library functions based on function call relationships and the address range corresponding to each dynamic library in memory. The jump access address indicates the memory address of other library functions called by the corresponding library function at runtime.

[0168] Optionally, the multiple library functions include a first library function in the target application, and the function call relationship indicates that the first library function needs to call the target library function when it runs;

[0169] The function relocation module is specifically used for:

[0170] Based on the address range corresponding to the second type of dynamic library in memory and the offset address of the target library function, the function access address of the target library function is determined;

[0171] Set the function access address to the jump access address of the target library function when the first library function calls it.

[0172] Optionally, multiple library functions include second library functions in a third type of dynamic library, and the function call relationship indicates that the second library function needs to call the target library function;

[0173] The function relocation module is specifically used for:

[0174] Based on the address range corresponding to the fourth type of dynamic library in memory and the offset address of the target library function, the function access address of the target library function is determined;

[0175] Set the function access address to the jump access address of the target library function when the second library function calls it.

[0176] Optionally, the library function calling device also includes:

[0177] The address acquisition module is used to obtain the address range in memory for each dynamic library in the second, third and fourth types of dynamic libraries.

[0178] The variable determination module is used to determine multiple global variables included in the second, third, and fourth types of dynamic libraries;

[0179] The variable relocation module is used to relocate the memory access address of each global variable among multiple global variables, based on the dynamic library to which the global variable belongs and the memory address range of each dynamic library.

[0180] Optionally, the variable relocation module is specifically used for:

[0181] If the target application and / or library functions in the third type of dynamic library access global variables, then the access address of the global variable is set to the memory address corresponding to the global variable in the second type of dynamic library; or,

[0182] If the target application and / or library functions in the third type of dynamic library access global variables, then the access address of the global variable will be set to the memory address corresponding to the global variable in the fourth type of dynamic library.

[0183] Optionally, the dynamic library loading module 1402 includes:

[0184] The acquisition unit is used to acquire dynamically loaded libraries in memory;

[0185] The determining unit is used to determine whether the first dynamic library has been loaded into memory based on the loaded dynamic library. The first dynamic library is any one of the dynamic libraries included in the second, third and fourth types of dynamic libraries.

[0186] The loading unit is used to load the first dynamic library into memory if it is not already loaded.

[0187] Optionally, the loaded dynamic library includes a second dynamic library; the determining unit is specifically used for:

[0188] If the first dynamic library and the second dynamic library have the same library name, and the second dynamic library is a first type of dynamic library, then it is determined that the first dynamic library has been loaded into memory.

[0189] If the first dynamic library and the second dynamic library have the same library name, and the first dynamic library and the second dynamic library belong to the same platform, then it is determined that the first dynamic library has been loaded into memory.

[0190] Optionally, the loading unit also includes:

[0191] The information determination subunit is used to determine the platform information of the platform to which the first dynamic library belongs;

[0192] The validity verification subunit is used to determine that the first dynamic library is a valid dynamic library if the platform information indicates that the platform to which the first dynamic library belongs includes the first platform and / or the second platform, and to perform the step of loading the first dynamic library into memory.

[0193] In this embodiment, when migrating a target application from a first platform to a second platform, for the dynamic libraries that the target application depends on for execution, specifically the first type of dynamic libraries that require pass-through and the second type of dynamic libraries that do not require pass-through, when loading dynamic libraries into memory, for the first type of dynamic libraries that require pass-through, a third type of dynamic library with the same functionality as the second type of dynamic library is loaded into memory; for the second type of dynamic libraries that do not require pass-through, the second type of dynamic library, as well as a fourth type of dynamic library on the second platform that contains the same functionality as the second type of dynamic library, are also loaded into memory. In this case, if the target library function includes library functions with the same functionality in both the second and fourth type of dynamic libraries, in response to a function call request for the target library function, if the function call request is triggered by the target application, the target library function is called from the second type of dynamic library in memory; if the function call request is triggered by a library function in the third type of dynamic library, the target library function is called from the fourth type of dynamic library in memory. Therefore, the library function calling scheme provided in this application only requires local pass-through of library functions for the first type of dynamic library on the first platform. For the second type of dynamic library on the first platform, both the second type of dynamic library and the fourth type of dynamic library with the same function on the second platform are directly loaded into memory, eliminating the need for local pass-through of library functions for the second type of dynamic library. Consequently, there is no need to obtain the source code of the library functions in the second type of dynamic library to construct wrapper functions. This significantly reduces the workload of constructing wrapper functions when porting a target application from one platform to another, while ensuring that the target application can run normally on the second platform.

[0194] It should be noted that the library function calling device provided in the above embodiments, when running the target application on the second platform and calling library functions in memory, is only illustrated by 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 library function calling device and the library function calling method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0195] This application also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the steps of the library function call method shown in the above embodiments.

[0196] This application also provides a computer program product containing instructions that, when executed on a computer, cause the computer to perform the steps of the library function call method shown in the embodiments. Alternatively, a computer program is provided that, when executed on a computer, causes the computer to perform the steps of the library function call method shown in the above embodiments.

[0197] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital versatile disc (DVD)), or a semiconductor medium (e.g., solid state disk (SSD)). It is worth noting that the computer-readable storage medium mentioned in the embodiments of this application can be a non-volatile storage medium; in other words, it can be a non-transient storage medium.

[0198] It should be understood that "multiple" as mentioned herein refers to two or more. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. In addition, to facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first," "second," etc., are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and the terms "first," "second," etc., do not necessarily imply that they are different.

[0199] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in the embodiments of this application are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the dynamic libraries, library functions, platform information, etc. involved in the embodiments of this application were all obtained with full authorization.

[0200] The above descriptions are embodiments provided in this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A library function calling method, characterized in that, The method includes: The dynamic libraries that the target application depends on at runtime are determined. The target application is an application migrated from a first platform to a second platform. The system architectures of the first platform and the second platform are different. The dynamic libraries include a first type of dynamic library that needs to be passed through and a second type of dynamic library that does not need to be passed through. The passing through instruction is to implement the functionality of the corresponding library function in the first platform through the library function in the second platform. The second type of dynamic library, the third type of dynamic library, and the fourth type of dynamic library are loaded into memory. The third type of dynamic library is a dynamic library in the second platform that contains library functions with the same functionality as the first type of dynamic library. The fourth type of dynamic library is a dynamic library in the second platform that contains library functions with the same functionality as the second type of dynamic library. In response to a function call request from a target library function, if the function call request is triggered by the target application, the target library function is called from the second type of dynamic library in memory; if the function call request is triggered by a library function in the third type of dynamic library, the target library function is called from the fourth type of dynamic library in memory; wherein, the target library function includes library functions with the same function functionality in the second type of dynamic library and the fourth type of dynamic library.

2. The method as described in claim 1, characterized in that, Before responding to a function call request from a target library function, the method further includes: Obtain the address range in memory corresponding to each of the second type of dynamic library, the third type of dynamic library, and the fourth type of dynamic library; Based on the multiple library functions included in the second type of dynamic library, the third type of dynamic library, and the fourth type of dynamic library, the function call relationship of the multiple library functions is determined; Based on the function call relationship and the address range corresponding to each dynamic library in memory, the jump access address corresponding to each of the multiple library functions is relocated. The jump access address indicates the address in memory of other library functions called by the corresponding library function during runtime.

3. The method as described in claim 2, characterized in that, The plurality of library functions includes a first library function in the target application, and the function call relationship indicates that the first library function needs to call the target library function when it runs; The step of relocating the jump access addresses corresponding to the multiple library functions based on the function call relationships and the address range corresponding to each dynamic library in memory includes: Based on the address range corresponding to the second type of dynamic library in the memory and the offset address of the target library function, the function access address of the target library function is determined; Set the function access address to the jump access address of the first library function when calling the target library function.

4. The method as described in claim 2, characterized in that, The plurality of library functions includes the second library function in the third type of dynamic library, and the function call relationship indicates that the second library function needs to call the target library function; The step of relocating the jump access addresses corresponding to the multiple library functions based on the function call relationships and the address range corresponding to each dynamic library in memory includes: Based on the address range corresponding to the fourth type of dynamic library in the memory and the offset address of the target library function, the function access address of the target library function is determined; Set the function access address as the jump access address for the second library function to call the target library function.

5. The method according to any one of claims 1-4, characterized in that, Before responding to a function call request from a target library function, the method further includes: Obtain the address range in memory corresponding to each of the second type of dynamic library, the third type of dynamic library, and the fourth type of dynamic library; Identify the multiple global variables included in the second type of dynamic library, the third type of dynamic library, and the fourth type of dynamic library; For each of the plurality of global variables, based on the dynamic library to which the global variable belongs and the address range corresponding to each dynamic library in memory, the variable access address corresponding to the global variable in memory is relocated.

6. The method as described in claim 5, characterized in that, The step of relocating the variable access address corresponding to the global variable in memory based on the dynamic library to which the global variable belongs and the address range corresponding to each dynamic library in memory includes: If the target application and / or the library function in the third type of dynamic library accesses the global variable, then the variable access address of the global variable is set to the memory address corresponding to the global variable in the second type of dynamic library; or, If the target application and / or the library function in the third type of dynamic library accesses the global variable, then the variable access address of the global variable is set to the memory address corresponding to the global variable in the fourth type of dynamic library.

7. The method according to any one of claims 1-6, characterized in that, Loading the second type of dynamic library, the third type of dynamic library, and the fourth type of dynamic library into the memory of the second platform includes: Obtain the dynamic libraries already loaded in memory; Based on the loaded dynamic library, determine whether the first dynamic library has been loaded into the memory. The first dynamic library is any one of the second type of dynamic library, the third type of dynamic library, and the fourth type of dynamic library. If the first dynamic library is not loaded into the memory, then the first dynamic library is loaded into the memory.

8. The method as described in claim 7, characterized in that, The loaded dynamic library includes a second dynamic library; The step of determining whether the first dynamic library has been loaded into memory based on the already loaded dynamic library includes: If the first dynamic library and the second dynamic library have the same library name, and the second dynamic library is a dynamic library of the first type, then it is determined that the first dynamic library has been loaded into the memory; If the first dynamic library and the second dynamic library have the same library name, and the first dynamic library and the second dynamic library belong to the same platform, then it is determined that the first dynamic library has been loaded into the memory.

9. The method as described in claim 7 or 8, characterized in that, Before loading the first dynamic library into the memory, the method further includes: Determine the platform information of the platform to which the first dynamic library belongs; If the platform information indicates that the platform to which the first dynamic library belongs includes the first platform and / or the second platform, then the first dynamic library is determined to be a valid dynamic library, and the step of loading the first dynamic library into the memory is executed.

10. A library function calling device, characterized in that, The device includes: The dynamic library determination module is used to determine the dynamic libraries that the target application depends on at runtime. The target application is an application migrated from a first platform to a second platform. The system architectures of the first platform and the second platform are different. The dynamic libraries include a first type of dynamic library that needs to be passed through and a second type of dynamic library that does not need to be passed through. The pass-through instruction is to implement the function of the corresponding library function in the first platform through the library function in the second platform. The dynamic library loading module is used to load the second type of dynamic library, the third type of dynamic library and the fourth type of dynamic library into memory. The third type of dynamic library is a dynamic library in the second platform that contains library functions with the same functionality as the first type of dynamic library. The fourth type of dynamic library is a dynamic library in the second platform that contains functions with the same library functionality as the second type of dynamic library. The library function call module is used to respond to a function call request from a target library function. If the function call request is triggered by the target application, the module calls the target library function from the second type of dynamic library in memory. If the function call request is triggered by a library function in the third type of dynamic library, the module calls the target library function from the fourth type of dynamic library in memory. The target library function includes library functions with the same functionality in both the second type of dynamic library and the fourth type of dynamic library.

Images