A dynamic link call conversion method and device

Abstract

The present application discloses a dynamic link call conversion method and device, wherein the method includes: if, when performing symbol resolution and binding for a first component, the first component is dynamically linked to a first symbol in a first dynamic link library, and the first symbol has not established a dynamic link symbol binding relationship with the first component, and the first component and the first dynamic link library use different calling conventions, then a dynamic linker generates a first table entry in a call conversion table, the first table entry includes a first instruction and a second instruction, the first instruction is used to instruct to load the first address of the first symbol in the memory to a specified first storage container, and the second instruction is used to instruct to jump to a call converter; the dynamic linker fills the second address of the first table entry in the memory into the second table entry in the default GOT table; the default GOT table belongs to the first component, thereby achieving the effect of call conversion across calling conventions without the need for manual intervention by the programmer or recompiling the program.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method and device for converting dynamic link calls. Background Art

[0002] Programs rely on many libraries during runtime, and dynamic linkers link programs to these libraries. When a program calls a function in a library, but the calling convention used by the program differs from that used by the library, the dynamic linker cannot link the libraries together. Even if they do, the libraries may not function properly, preventing cross-convention function calls.

[0003] In order to implement function calls across calling conventions, a call converter needs to be introduced. For example, function 1 in program A needs to call function 2 in function library B, where the former follows calling convention α and the latter follows calling convention β. In this case, function 1 cannot directly call function 2. Even if it is forced to call, it will cause a program error. Call conversion can be achieved by calling the converter, that is, function 1 calls the call converter with calling convention α, and the call converter calls function 2 with calling convention β, and later similarly transfers the return value in accordance with the calling convention. In the prior art, since the call converter cannot actively intercept function calls across calling conventions, the programmer needs to actively change the call to function 2 to a call to the call converter to complete it in a roundabout way, and this process must also actively pass the relevant information of function 2 to the call converter. It can be seen that this call conversion method requires manual intervention by the programmer, such as actively writing how to pass parameters to the call converter or recompiling the program to embed the call converter. In particular, when this call conversion method is used for dynamic linking, it is particularly cumbersome, and it is necessary to manually open the dynamic link library that does not conform to the calling convention and pass it to the call converter to generate the call entry (handle) after call conversion. It is not suitable for dynamic linking automatically completed by the dynamic linker. Summary of the Invention

[0004] The embodiments of the present application provide a dynamic link call conversion method and apparatus for implementing call conversion across calling conventions without requiring manual intervention by a programmer or recompiling a program.

[0005] In a first aspect, an embodiment of the present application provides a dynamic link call conversion method, which can be executed by a dynamic link call conversion device, which can be a terminal device or a component in a terminal device, or a server or a component in a server. The present application does not limit the execution subject of the method. The method includes: if when performing symbol resolution and binding for a first component, the first component dynamically links to a first symbol in a first dynamic link library, and the first symbol has not established a dynamic link symbol binding relationship with the first component, and the first component and the first dynamic link library use different calling conventions, then a first table entry of a call conversion table is generated by a dynamic linker, the first table entry includes a first instruction and a second instruction, the first instruction is used to indicate the loading of the first address of the first symbol in the memory to a specified first storage container, and the second instruction is used to indicate a jump to the call converter; the second address of the first table entry in the memory is filled into the second table entry in the default GOT table by the dynamic linker; wherein the default GOT table belongs to the first component.

[0006] In the above scheme, when performing symbol resolution and binding for the first component, if the first component needs to call the first symbol in the first dynamic link library across calling conventions and the first symbol has not established a dynamic link symbol binding relationship with the first component, by modifying the binding process of the dynamic linker, the address filled in the default GOT table by the dynamic linker is changed to the address of the corresponding table entry (i.e., the first table entry) in the call conversion table in the memory, the first component's call to the first symbol can be converted into a call to the first table entry, thereby achieving the effect of call conversion across calling conventions without the need for manual intervention by the programmer or recompiling the program.

[0007] In one possible implementation, after the dynamic linker fills the second address of the first table entry in the memory into the second table entry in the default GOT table, it also includes: triggering the execution of a third instruction by the dynamic linker or the first component; wherein the third instruction uses the second address stored in the second table entry in the default GOT table as an indication, and jumps to the first table entry in the call conversion table according to the indication; executing the third instruction, jumping to the first table entry in the call conversion table; executing the first instruction in the first table entry, loading the first address of the first symbol in the memory into the first storage container; executing the second instruction, jumping to the call converter; the call converter is used to accept the call of the first component using the first calling convention, and call the first symbol using the second calling convention according to the first address stored in the first storage container.

[0008] In the above scheme, since the second entry of the default GOT table points to the second address of the first entry of the call conversion table in the memory, the call of the first symbol by the first component is converted into a call to the first entry. Therefore, the second entry can load the first address of the first symbol in the memory and instruct the call converter to complete the final call and call conversion, thereby achieving the effect of call conversion across calling conventions without the need for manual intervention by the programmer or recompiling the program.

[0009] In one possible implementation, after calling the first symbol using the second calling convention according to the first address stored in the first storage container by calling the converter, the following steps are further included: when the first symbol completes execution and returns, returning to the calling converter; calling the converter using the second calling convention to obtain the first return value; calling the converter using the first calling convention to store the first return value in the second storage container; after the calling converter completes execution, returning to the first component; the first component using the first calling convention to retrieve the first return value from the second storage container and determine it as the return value of the first symbol. The second storage container may be a register, memory (such as a stack in memory), or other memory. In one possible implementation, if the second storage container is a register, it should belong to the return value register specified in the first calling convention; this implementation ensures that the first component can correctly obtain the return value of the first symbol and ensures correct data transfer.

[0010] In one possible implementation, the dynamic linker also includes a dynamic link library runtime parsing component for establishing a dynamic link symbol binding relationship; the initial value of the second table entry in the default GOT table when the first component is initialized is a default value; the first component includes a third instruction; the second address of the first table entry in the memory is filled into the second table entry in the default GOT table through the dynamic linker, including: when the first component triggers the execution of the third instruction for the first time, the third instruction uses the default value in the second table entry in the default GOT table as an indication, and jumps to the fourth instruction according to the indication; wherein the fourth instruction may be located in the default PLT table or the stub table; executing the fourth instruction, jumping to the dynamic link library runtime parsing component; filling the second address into the second table entry in the default GOT table through the dynamic link library runtime parsing component.

[0011] In one possible implementation, a first table entry of a call translation table is generated by a dynamic linker, and the second address of the first table entry in the memory is filled into the second table entry in the default GOT table by the dynamic linker, including: when the first component is initialized, the first table entry of the call translation table is generated by the dynamic linker, and the second address of the first table entry in the memory is filled into the second table entry in the default GOT table.

[0012] In one possible implementation, the dynamic linker also includes a dynamic link library runtime parsing component for establishing a dynamic link symbol binding relationship; the method also includes: when the first component is initialized, the dynamic linker pre-fills the fifth table entry of the real address table with an agreed value, and the agreed value is used to indicate that the first symbol is not bound; the dynamic linker or the first component triggers the execution of a third instruction; wherein the third instruction uses the second address stored in the second table entry in the default GOT table as an indication, and jumps to the first table entry of the call conversion table according to the indication; executes the third instruction, jumps to the first table entry in the call conversion table; executes the first instruction in the first table entry, loads the agreed value indicating that the first symbol is not bound from the fifth table entry of the real address table to the first storage container; executes the second instruction, jumps to the call converter; determines that the first symbol is not bound according to the agreed value in the first storage container through the call converter, and jumps to the dynamic link library runtime parsing component.

[0013] In a possible implementation, after jumping to the dynamic link library runtime parsing component, the method further includes: filling the first address of the first symbol in the memory into the fifth entry in the real address table through the dynamic link library runtime parsing component.

[0014] In one possible implementation, before the dynamic link library runtime parsing component fills the first address of the first symbol in the memory into the fifth table entry in the real address table, it also includes: determining the first address of the first symbol in the memory based on the third address to which the first dynamic link library is loaded and the address offset of the first symbol in the first dynamic link library through the dynamic link library runtime parsing component.

[0015] In one possible implementation, after the dynamic link library runtime parsing component fills the first address of the first symbol in the memory into the fifth table entry in the real address table, it also includes: triggering the execution of a third instruction through the dynamic linker or the first component; executing the third instruction, jumping to the first table entry in the call conversion table; executing the first instruction in the first table entry, loading the first address of the first symbol from the fifth table entry in the real address table to the first storage container; executing the second instruction, jumping to the call converter; accepting the call of the first component using the first calling convention through the call converter, and calling the first symbol using the second calling convention according to the first address stored in the first storage container.

[0016] In one possible implementation, the second address of the first table entry in the memory is filled into the second table entry in the default GOT table through the dynamic linker, including: when the first component is initialized, the dynamic linker completes the immediate binding process of all symbols dynamically linked to the first component, and fills the second address of the first table entry in the memory into the second table entry in the default GOT table.

[0017] In one possible implementation, the first instruction is used to instruct to directly load the first address of the first symbol using an immediate value load; the method further includes: executing the first instruction in the first table entry, and using the immediate value to load the first address of the first symbol in the memory to the first storage container.

[0018] In one possible implementation, the method further includes: determining whether to load the first dynamic link library; if it is determined through the dynamic linker that the first dynamic link library has not been loaded, searching for the first dynamic link library in a search path that complies with the first calling convention used by the first component and all foreign calling conventions that can be supported by call conversion based on the name or path of the first dynamic link library; after searching for the first dynamic link library, loading the first dynamic link library into the memory.

[0019] In a possible implementation, the method further includes: after generating the call conversion table, setting the call conversion table to be readable, executable, and non-writable.

[0020] In a possible implementation, the addresses of the entries in the call translation table in the memory are continuous, or the addresses of the entries in the call translation table in the memory are discontinuous.

[0021] In one possible implementation, the method further includes: for a real address table implementing delayed binding, setting the real address table to be readable, writable, and non-executable, and the real address table is used to fill in the first address of the first symbol in the memory, or to fill in the agreed value indicating that the first symbol is not bound; or, for a real address table implementing immediate binding, setting the real address table to be readable, non-writable, and non-executable, and the real address table is used to fill in the first address of the first symbol in the memory.

[0022] In a possible implementation, the addresses of the entries in the real address table in the memory are continuous, or the addresses of the entries in the real address table in the memory are discontinuous.

[0023] In a possible implementation, the first component is a program, or the first component is a second dynamic link library.

[0024] In a second aspect, an embodiment of the present application provides a dynamic link call conversion device, comprising:

[0025] a generating unit configured to generate, by a dynamic linker, a first table entry of a call translation table if, when performing symbol resolution and binding for the first component, the first component is dynamically linked to a first symbol in a first dynamic link library, and no dynamic link symbol binding relationship is established between the first symbol and the first component, and the first component and the first dynamic link library use different calling conventions, the first table entry including a first instruction and a second instruction, the first instruction being used to instruct loading a first address of the first symbol in a memory into a specified first storage container, and the second instruction being used to instruct jumping to a call translator;

[0026] A filling unit is used to fill the second address of the first table entry in the memory into the second table entry in the default GOT table through a dynamic linker; wherein the default GOT table belongs to the first component.

[0027] In a third aspect, an embodiment of the present application further provides a computer device, including:

[0028] a memory for storing program instructions;

[0029] The processor is configured to call the program instructions stored in the memory and execute any method of the first aspect according to the obtained program.

[0030] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute any method of the above-mentioned first aspect.

[0031] In a fifth aspect, an embodiment of the present application provides a computer program product, comprising a computer program executable by a computer device, wherein when the program is run on the computer device, the computer device executes any method for implementing the above-mentioned first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 A flowchart of a dynamic link call conversion method provided in an embodiment of the present application;

[0033] Figure 2 A schematic diagram of the process of symbol resolution and binding provided in an embodiment of the present application;

[0034] Figure 3 A schematic diagram of the loading process of the dynamic link library provided in the embodiment of the present application;

[0035] Figure 4 This is a schematic diagram before the program is started according to an embodiment of the present application;

[0036] Figure 5 A schematic diagram of the program provided in the embodiment of the present application just started;

[0037] Figure 6 A schematic diagram of the first call to PLT entry 1 function 1 being bound provided in an embodiment of the present application;

[0038] Figure 7 A schematic diagram showing that function 1 provided in an embodiment of the present application has completed binding;

[0039] Figure 8 A schematic diagram of an unsimplified PLT table and GOT table without a real address table provided in an embodiment of the present application;

[0040] Figure 9 A schematic diagram of a call scenario provided in an embodiment of the present application;

[0041] Figure 10 A schematic diagram of the structure of a dynamic link call conversion device provided in an embodiment of the present application;

[0042] Figure 11 A structural diagram of a dynamic link call conversion device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0043] To make the objectives, technical solutions, and advantages of this application more clear, this application will be further described in detail below with reference to the accompanying drawings. Obviously, the embodiments described are only some of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making any creative efforts are within the scope of protection of this application.

[0044] The following is an explanation of some of the professional terms used in this application.

[0045] Linking: Generally speaking, compiling a program from source code to produce an executable file (program) or library requires several steps. These steps typically include compilation, assembly, and linking. Generally, if there is no ambiguity, the term "compile" encompasses all of these steps. We consider this definition of "compile" broad, and unless otherwise specified, it should be understood in this broad sense. In a narrow sense, compilation refers to converting source code written in a programming language into assembly language code. Assembly language code remains human-readable but cannot be executed by a processor, but can be easily converted to machine code. Assembly refers to converting assembly language code into machine code (hereinafter referred to as an instruction stream or instructions) that can be executed by a processor and stored in an object file. Generally speaking, a software program of a certain size will have many source code files, which will generate many object files and rely on many libraries. A linker (note: a linker is not a dynamic linker) is responsible for linking these object files and the dependent libraries together to form an executable file or library; this process is called linking.

[0046] Sometimes, terms such as compile time, link time, and run time (also known as execution time, runtime, and to avoid ambiguity, often referred to as "when the program is running / executed") are used to refer to the process of a program from source code to target file (compile time, including compilation and assembly in a narrow sense), from target file to executable file or function library (link time), and from executable file or function library in storage space to the process actually executed on the processor (run time).

[0047] There are two ways to "link these target files and the dependent function libraries together to form an executable file or function library": dynamic linking or static linking.

[0048] When performing dynamic linking, the linker only writes some characteristic information about the dynamic link library into the executable file or function library mentioned above; it does not write the dynamic link library itself into the latter. This characteristic information is used to guide the dynamic linker. Therefore, the actual linking work (loading and binding) is left to the dynamic linker at runtime.

[0049] When the linker completes static linking, it first merges the various target files and static link libraries into a binary file (similar to loading a dynamic link), and then corrects the reference to the address in the machine code based on the offset position of the merged target files and static link libraries (similar to binding in dynamic linking).

[0050] Dynamic linking and static linking are not mutually exclusive. An executable file (program) or function library can use only dynamic linking, only static linking, or both. For example, a software project or function library project of a certain scale, which has several source code files, may have the following situations, including but not limited to:

[0051] In case 1, the target files compiled from these source files are often statically linked together to form a single executable file (single product) or function library (single product). These target files become part of the single product.

[0052] Case 2: In rare cases, some target files are statically linked into a function library (dynamic link library, product 1), and then the remaining target files are statically linked into an executable program (product 2), which is then dynamically linked to the former (product 1).

[0053] In case 3, such software may rely on external libraries in addition to its own source code. Depending on the linker options passed to the linker, some of these libraries may be statically linked into one or more of the aforementioned products (either a single product in case 1, or products 1 and / or 2 in case 2); others may be dynamically linked into one or more of the aforementioned products (same as above). Depending on the linker options passed to the linker, all external libraries may be statically or dynamically linked.

[0054] Linker and dynamic linker: A linker is not a dynamic linker. In terms of the time of operation, the linker operates at the linking stage, while the dynamic linker operates at the execution stage. In terms of the inputs accepted and the outputs produced, the linker accepts target files, static link libraries, and dynamic link libraries (the target file is required, and the remaining two are optional), and produces an executable file or a dynamic link library (generally, a linker is not used to generate static link libraries; static link libraries are created directly by indexing and archiving target files). The dynamic linker accepts executable files and searches for the required dynamic link libraries on its own. It does not produce any tangible products, but only affects the contents of memory during program execution: it completes the loading and binding of dynamic link libraries into memory, resolves the dependencies between the program and the dynamic link library, and enables the program to execute correctly.

[0055] In computer science, a library (also known as a function library, program library, or simply library) is a collection of subroutines used to develop software. Unlike executable files, a library is not a standalone computer program; instead, it provides services to other programs. The primary purpose of a library is to provide a mechanism for code reuse, saving developers time and effort by avoiding rewriting the same code. Libraries can be compiled and linked as either dynamic link libraries or static link libraries.

[0056] Symbol table: In computer science, a symbol table is a data structure used in language translators such as compilers and interpreters. In a symbol table, each identifier in a program's source code is associated with information about its declaration or use, such as its data type, scope, and memory address. Object files typically contain a symbol table that contains all externally visible identifiers. When linking different object files, the linker uses the symbol tables in these files to resolve any unresolved symbol references. The symbol table may exist only during the compilation and linking phases, or it may be embedded in the output files of that phase (such as executable files, dynamic / static link libraries) for use in subsequent phases. For example, it can be used in interactive debuggers or to provide formatted diagnostic reports during or after program execution.

[0057] The symbol table that stores all symbols is called .symtab and is mainly used for debugging purposes.

[0058] A special type of symbol table is the dynamic symbol table (usually .dynsym), which stores the import and export symbols associated with dynamic linking and does not include symbols within modules. The symbol names corresponding to the symbols in the dynamic symbol table are stored in the dynamic symbol string table (usually .dynstr). A dynamic symbol table is a table that stores information about the import and export symbols associated with dynamic linking. The dynamic symbol table is generated by the linker.

[0059] Import symbols are symbols that the current executable file or dynamic link library depends on; exported symbols are symbols provided by the current executable file or dynamic link library. Obviously, to complete the binding of an imported symbol, the corresponding exported symbol must be found. Generally speaking, the dynamic linker can find the required exported symbols in the dynamic link library to which the current program or dynamic link library is linked.

[0060] The dynamic symbol table may also contain symbols specific to a program or dynamic link library, even if these symbols are not intended for export or import. This is well understood for dynamic link libraries: dynamic link libraries may be loaded at unspecified addresses, so references to some of their own functions and global symbols may not be determined until runtime. These symbols are bound by the dynamic linker even if they are not actually used for dynamic linking (not for importing or exporting symbols). For executables, this is typically done when the position-independent execution feature is enabled, making these executables executables (PIEs), which can be loaded and executed at arbitrary addresses. This is commonly used to implement address space layout randomization (ASLR). Such executables also share the aforementioned issues with dynamic link libraries (the locations of some symbols must be determined at runtime), so they also need to include their own symbols in the dynamic symbol table, even if these symbols are not intended for export or import.

[0061] Figure 1 A flow chart of a dynamic link call conversion method provided in an embodiment of the present application is exemplarily shown. The method flow can be executed by a dynamic link call conversion device, which can be a terminal device or a component within a terminal device, or a server or a component within a server; wherein the component is, for example, a processor.

[0062] like Figure 1 As shown, the method flow includes the following steps:

[0063] Step 101: If, when performing symbol resolution and binding for the first component, the first component is dynamically linked to the first symbol in the first dynamic link library, and the first symbol has not established a dynamic link symbol binding relationship with the first component, and the first component and the first dynamic link library use different calling conventions, then a first table entry of a call conversion table is generated by a dynamic linker, the first table entry includes a first instruction and a second instruction, the first instruction is used to indicate the loading of the first address of the first symbol in the memory to the specified first storage container, and the second instruction is used to indicate a jump to the call converter.

[0064] In one implementation, the first component is a program. In another implementation, the first component is a second dynamic link library linked to the first dynamic link library. In both of the above implementations, the first symbol can be a function. For ease of description, the following example uses the example where the first component is program A, the second component is the first dynamic link library, and the first symbol can be a function.

[0065] The following describes the difference in calling conventions used by the first component and the first dynamic link library in step 101. For example, the calling convention used by program A is The calling convention used by the first dynamic link library is calling convention β. If, during symbol resolution and binding for program A, program A links to function 2 in the first dynamic link library, and function 2 has not established a binding relationship with program A, a first table entry in a call translation table is generated by the dynamic linker.

[0066] The first storage container in step 101 above may be a register, a memory (such as a stack in memory), or other memory. In one possible implementation, if the first storage container is a register, it should belong to the calling convention The caller-saved registers specified in the (first calling convention) are used to ensure that the context of the first component is not destroyed by the first instruction, ensuring correct execution and avoiding erroneous crashes.

[0067] Step 102: Fill the second address of the first entry in the memory into the second entry in the default GOT table through the dynamic linker; the default GOT table belongs to the first component.

[0068] Before step 101, the dynamic linker parses the dynamic symbol table of the first component to obtain the symbol information to which the first component is dynamically linked and the address of the GOT table entry to be filled, and then performs symbol parsing and binding according to the symbol information. Figure 2 The process diagram shown.

[0069] The symbol information dynamically linked to the first component includes multiple symbols, and this application takes the first symbol as an example for explanation. Figure 2 As shown, first, according to the symbol information, the first dynamic link library where the first symbol is located is found, and then it is determined whether the first dynamic link library has been loaded. If not, that is, the dynamic linker has not loaded the first dynamic link library, the dynamic link library loading process is executed. The dynamic link library loading process is specifically referred to in Figure 3 If yes, that is, the dynamic linker has loaded the first dynamic link library into memory, the symbol table of the first dynamic link library is parsed to find the offset of the first symbol. The offset is then combined with the memory address where the first dynamic link library was loaded to calculate the actual address of the first symbol in memory.

[0070] Next, a determination is made as to whether the first symbol is a function with an external calling convention. If the first symbol is a function with an external calling convention, the first symbol's actual memory address ("symbol address") cannot be directly entered into the GOT. Instead, the corresponding call translation PLT entry must be entered into the GOT. This can be divided into two specific scenarios: Scenario 1: The first symbol's actual memory address is entered into the corresponding real address table entry, i.e., the fifth entry (if the corresponding entry does not exist, a new one can be created); Scenario 2: In the absence of a real address table, a call translation table entry, i.e., the first entry, is generated. The first symbol's actual memory address is entered into the immediate value field of the instruction (or instruction cluster) that directly loads the symbol address. In either scenario, the first symbol's actual memory address is entered into the corresponding GOT entry, i.e., the second entry, with the corresponding call translation table entry (i.e., the first entry; if the corresponding call translation table entry does not exist, a new one can be created). If the first symbol is not a function of the foreign calling convention, but a local calling convention, that is, the calling convention used by the first component and the first dynamic link library is the same, then the actual address of the first symbol in the memory is filled into the corresponding table entry in the default GOT table, that is, the second table entry, to complete the establishment of the dynamic link symbol binding relationship between the first symbol and the first component. In the case that the first symbol is a function of the local calling convention, there is no need to execute Figure 1 The dynamic link call conversion method shown.

[0071] See below Figure 3 , which introduces the loading process of dynamic link libraries.

[0072] First, determine whether the name or path of the first dynamic link library is passed in. If the path is passed in, determine whether the path exists. If so, that is, the path exists, determine the path of the dynamic link library. If not, that is, the path does not exist, determine that the loading failed (generally causing the program to crash), and end the process. If the name is passed in, search for the first dynamic link library in each dynamic link library search path that conforms to the current calling convention (that is, the first calling convention used by the first component, that is, the local calling convention) and all foreign calling conventions supported by call conversion, and then determine whether the first dynamic link library is found. If so, that is, the first dynamic link library is found, determine the path of the first dynamic link library. If not, that is, the first dynamic link library is not found, it indicates that the loading failed (generally causing the program to crash), and end the process. After determining the dynamic link library path, determine whether the first dynamic link library has been loaded. If so, the first dynamic link library has been loaded into the memory, and the loading process ends. If so, it indicates that the first dynamic link library has not been loaded, and then load the first dynamic link library into the memory from the path, and end the loading process.

[0073] Typically, dynamic link libraries with different calling conventions are installed in different directories (paths). When searching for a dynamic library using its name, the dynamic library is searched in the search paths for both the current calling convention ("native") and all calling conventions that can be supported by call conversion ("foreign") . This ensures that dynamic link libraries across calling conventions are included in the search scope, ensuring that the required symbols can be found in both the dynamic link libraries with the native calling convention and the dynamic link libraries with the foreign calling convention. Furthermore, the problem of lacking dynamic link libraries with the native calling convention can be resolved by using dynamic link libraries with the foreign calling convention.

[0074] When the same symbol is found in both a native calling convention dynamic link library and a foreign calling convention dynamic link library, which one is used first for binding is not specified. One possible implementation is to give priority to the native calling convention symbol to avoid the overhead of call translation; another possible implementation is to give priority to the foreign calling convention symbol when it is known that the performance of the foreign calling convention symbol is better than that of the foreign calling convention symbol to offset the overhead of call translation; another possible implementation is to count the other symbols that the symbol depends on and / or the symbols that depend on it, and use the most common calling convention among these dependencies and / or dependents to determine the calling convention version selected for binding for the symbol.

[0075] After step 102, that is, after the dynamic linker fills the second address of the first table entry in the memory into the second table entry in the default GOT table, the dynamic linker or the first component can trigger the execution of the third instruction. It should be noted that this can be a jump to the third instruction or a sequential execution to the third instruction. The third instruction uses the second address stored in the second table entry in the default GOT table as an indication and jumps to the first table entry in the call conversion table according to the indication; the third instruction is executed to jump to the first table entry in the call conversion table; the first instruction in the first table entry is executed to load the first address of the first symbol in the memory into the first storage container; the second instruction is executed to jump to the call converter; the call converter is used to accept the call of the first component using the first calling convention and call the first symbol using the second calling convention according to the first address. The execution of the third instruction is triggered by the dynamic linker or the first component. This may occur because the dynamic linker continues to complete the call to the first symbol that triggered this binding after completing the binding of the first symbol. In this case, the execution of the third instruction is triggered by the dynamic linker; it may also be because the first component calls the first symbol again after the binding is completed. In this case, the execution of the third instruction is triggered by the first component.

[0076] It should be noted that after the dynamic linker fills the second address of the first table entry in the memory into the second table entry in the default GOT table, the execution of the third instruction is triggered differently in the delayed binding scenario and the immediate binding scenario: in the delayed binding scenario, the execution of the third instruction can be triggered by the dynamic linker or the first component; in the immediate binding scenario, the execution of the third instruction can be triggered by the first component, and there is no situation where the dynamic linker triggers the execution of the third instruction, which will not be repeated below.

[0077] Here, the call conversion process implemented by the call converter is further described, which may specifically include the following steps S1 to S7:

[0078] S1, accepting a call from the first component using the first calling convention, and obtaining a first return address from a second storage container; wherein the second storage container is a storage container specified by the first calling convention for storing return addresses, and the first return address is used to return to the first component.

[0079] S2, storing the second return address into a third storage container; wherein the second return address is used to return to the call translator, and the third storage container is a storage container specified by the second calling convention for storing the return address.

[0080] S3, obtaining a first address from the first storage container, and calling a first symbol located at the first address using a second calling convention.

[0081] S4, after the first symbol is executed, the first symbol will store its return value in the fourth storage container, and use the return address stored in the third storage container as an instruction to return to the second return address; wherein the fourth storage container is a storage container specified by the second calling convention for storing return values.

[0082] S5, after returning to the calling converter, the calling converter obtains the return value from the fourth storage container and stores the return value into the fifth storage container; wherein the fifth storage container is a storage container specified by the first calling convention for storing return values.

[0083] S6, using the first return address as an instruction, returning to the first component.

[0084] S7. The first component may obtain a return value from the fifth storage container according to the first calling convention.

[0085] There are many possible implementations of the above step 102.

[0086] Implementation method one: when the default GOT table is not pre-filled, the dynamic linker also includes a dynamic link library runtime parsing component for establishing a dynamic link symbol binding relationship; the initial value of the second table item in the default GOT table when the first component is initialized is a default value; the first component includes a third instruction; when the first component triggers the execution of the third instruction for the first time, the third instruction uses the default value in the second table item in the default GOT table as an indication, and jumps to the fourth instruction according to the indication; wherein the fourth instruction may be located in the default PLT table or the stub table; execute the fourth instruction and jump to the dynamic link library runtime parsing component; fill the second address into the second table item in the default GOT table through the dynamic link library runtime parsing component.

[0087] In the second embodiment, when the default GOT table is pre-filled, when the first component is initialized, a first entry of the call translation table is generated by the dynamic linker, and the second address of the first entry in the memory is filled into the second entry in the default GOT table.

[0088] Based on the second embodiment, the dynamic linker also includes a dynamic link library runtime parsing component for establishing a dynamic link symbol binding relationship; when the first component is initialized, the dynamic linker pre-fills the fifth table entry of the real address table with an agreed value, and the agreed value is used to indicate that the first symbol is not bound; the execution of the third instruction is triggered by the dynamic linker or the first component; wherein the third instruction uses the second address stored in the second table entry in the default GOT table as an indication, and jumps to the first table entry of the call conversion table according to the indication; executes the third instruction, jumps to the first table entry in the call conversion table; executes the first instruction in the first table entry, loads the agreed value indicating that it is not bound from the fifth table entry of the real address table to the first storage container; executes the second instruction, jumps to the call converter; determines that the first symbol is not bound according to the agreed value in the first storage container through the call converter, and jumps to the dynamic link library runtime parsing component.

[0089] After jumping to the dynamic link library runtime parsing component, the dynamic link library runtime parsing component fills the first address of the first symbol in the memory into the fifth table entry in the real address table.

[0090] Before the dynamic link library runtime parsing component fills the first address of the first symbol in the memory into the fifth table entry in the real address table, the dynamic link library runtime parsing component also determines the first address of the first symbol in the memory based on the third address to which the first dynamic link library is loaded and the address offset of the first symbol in the first dynamic link library.

[0091] After the dynamic linker generates the first entry in the call translation table, there are two ways to jump to the call translator:

[0092] In method one, the dynamic linker embeds the call translator's third address in memory into the second instruction in the call translation table; executes the second instruction, loads the third address embedded in the second instruction, and jumps to the call translator based on the third address, where the third address is the address of the call translator in memory. In one possible implementation, the second instruction can directly jump to the third address based on its own instructions, that is, jump to the call translator, without specifically loading the third address. Using method one, a direct jump to the call translator is possible.

[0093] In the second approach, the dynamic linker inserts the call translator's third address in memory into the sixth entry in the real address table. The second instruction is executed, loading the third address from the sixth entry in the real address table and jumping to the call translator based on the third address. This approach allows for an indirect jump to the call translator.

[0094] After the above step 102, when delayed binding is completed, if the default PLT table entry is called again, it can be achieved in the following way: the dynamic linker or the first component triggers the execution of the third instruction; executes the third instruction, jumps to the first table entry in the call conversion table; executes the first instruction in the first table entry, loads the first address of the first symbol from the fifth table entry in the real address table to the first storage container; executes the second instruction, jumps to the call converter; accepts the call of the first component using the first calling convention through the call converter, and calls the first symbol using the second calling convention according to the first address stored in the first storage container.

[0095] The following is a specific example and Figures 4 to 7 , taking the first component as a program and the first symbol as a function as an example, the call conversion process in the delayed binding scenario is explained. It should be noted that this example only illustrates one dynamically linked function. If more functions are dynamically linked, then Figures 4 to 7 The default PLT table, default GOT table, call conversion table and real address table in the IO only need to grow accordingly (for example, add table entries). It should also be noted that in some real-world scenarios, there may not be a PLT table. At this time, the third instruction ("the instruction (cluster) that jumps to the address pointed to by GOT table entry 3") is moved to the instruction stream of the first component and replaces the "instruction (cluster) that calls PLT table entry 1" described later in the text and in the figure. The table composed of the remaining PLT table entry contents (including the fourth instruction and table entry 0) is called a stub table (if it is an immediate binding, a stub table is not required). Readers can understand that regardless of whether there is a PLT table, Figures 4 to 7 The processes described below can all be simply and equivalently transformed into a form without a PLT table, which only involves moving the position of the third instruction.

[0096] Figure 4The diagram before the program is started is shown. Before the program is started, that is, when it is still on the hard disk, it is impossible to know in advance which address the dynamically linked function will be loaded into. Therefore, most of the data in the default GOT table remains unfilled. Among them, the second table entry in the default GOT table is Figure 4 The original GOT entry 3 is labeled "(Function 1 Address)." The parentheses () in the figure indicate that the program originally expected Function 1's address to be in entry 3, but it hasn't been filled in yet (i.e., before the program starts). By default, GOT entry 3 now contains the default address, which is used to trigger delayed binding.

[0097] like Figure 4 As shown, the original GOT also includes entries 0 through 2. Entry 0's value is used to fill in the .dynamic address. Entry 1 is marked "(link_map address)." The parentheses () indicate that the program originally expected to fill in the link_map address in entry 1, but it hasn't been filled in yet (i.e., before the program starts). Similarly, "(_dl_runtime_resolve address)" in entry 2 indicates that the program originally expected to fill in the _dl_runtime_resolve address in entry 2, but it hasn't been filled in yet (i.e., before the program starts).

[0098] like Figure 4 As shown, the instruction stream of the "first component" includes multiple instructions, including the instruction (cluster) that calls PLT entry 1. These instructions are executed in descending order from the bottom of the instruction stream, unless a jump occurs. When the instruction (cluster) that calls PLT entry 1 in the instruction stream is first executed, the corresponding flow is executed according to the dashed arrows in the figure.

[0099] like Figure 4 As shown, the original PLT table includes table entries 0 and 1, where table entry 0 includes: "the instruction (cluster) to load the link_map address into a specified register or push it into the stack" and "the instruction (cluster) to jump to the address pointed to by table entry 2 in the GOT table"; table entry 1 in the PLT table (also referred to as the third table entry below) includes the third instruction and the fourth instruction, where the third instruction is Figure 4 The fourth instruction in the "instruction (cluster) that jumps to the address pointed to by entry 3 in the GOT table" is Figure 4 "Instructions (clusters) that load the function number into a specified register or push it onto the stack" and "Instructions (clusters) that jump to PLT entry 0".

[0100] It should be understood that Figures 5 to 8 Zhongyu Figure 4For the same content, please refer to Figure 4 In addition, the default GOT in this article can be understood as the original GOT, and the default PLT can be understood as the original PLT. Other places will not be repeated.

[0101] Figure 5 The figure shows a schematic diagram of the program just started, at which time the dynamic linker has completed its initial work.

[0102] Among them, the initial work of the dynamic linker mainly includes:

[0103] S51, bootstrap or self-binding. The dynamic linker itself is a special dynamic library that does not load itself, but must bind itself. The specific process of self-binding is relatively conventional and will not be detailed here.

[0104] S52: Parse the program's dynamic symbol table to obtain a list of symbols that the program is dynamically linked to. Parse the program's .dynamic section to obtain a list of dynamic link libraries that the program is dynamically linked to, along with some options for specifying dynamic linking behavior.

[0105] S53: Complete the initial work of delayed binding and / or complete the immediate binding.

[0106] (1) Initial work of delayed binding: Use the above information to generate the link_map of this program. Fill in the link_map address into the table 1 in the original GOT table as shown in 4, and fill in the address of _dl_runtime_resolve (that is, the dynamic link library runtime resolution component mentioned above, used to establish the dynamic link symbol binding relationship, the same below, no longer specified) into the table 2 in the original GOT table. After filling in, Figure 5 The GOT table entries 1 and 2 in the default GOT table. Sometimes it is also necessary to repair the initial value of the default GOT table entry (add it to the address where the current program / dynamic link library is loaded).

[0107] (2) Immediate binding: Use the above information to complete the immediate binding.

[0108] It should be noted that _dl_runtime_resolve is part of the dynamic linker. Since the dynamic linker has already been loaded, _dl_runtime_resolve is naturally loaded as well. Furthermore, dynamic link libraries likely have their own PLT / GOT tables and are likely linked to other dynamic link libraries. Therefore, each time a dynamic link library is loaded (or a symbol is bound to a dynamic link library for the first time), the above-mentioned S52-S53 operations may also need to be performed on that dynamic link library. In some implementations, the dynamic linker's initial lazy binding work may also include preloading the dynamic link libraries to which the program is linked (but not binding them) and performing some pre-resolving. This is because the dynamic linker can minimize the overhead of preloading by leveraging mechanisms provided by the operating system. In this case, these dynamic link libraries do not need to be loaded again later. The following text still uses the example that the initial work performed by the dynamic linker does not include pre-loading of the dynamic link library. It should be understood that even if the dynamic linker pre-loads the dynamic link library, it will have no substantial impact on the subsequent process. This is because the dynamic link library can always be loaded on demand and will only be loaded if it has not been loaded. Otherwise, the loading can be skipped directly.

[0109] In addition to the initial work described above, the dynamic linker also needs to handle the following tasks:

[0110] S54, parse the PLT table and GOT table of the program to determine how many functions are dynamically linked, and based on this number, generate a call conversion table and a real address table. For example, the first table entry of the call conversion table in this article is as follows Figure 5 In the call conversion table shown in Table 1, the first instruction can be Figure 5 The second instruction in the entry 1 of the call translation table shown in the figure is "load the real address table entry 3 to a specified register or instruction (cluster) on the stack", which can be Figure 5 The table entry 1 in the call translation table shown in FIG. 1 includes "instructions (clusters) for jumping to the call translator", and the table entry 1 in the call translation table may also include "instructions (clusters) for performing preparation work". For example, the fifth table entry in the real address table in this article is as follows Figure 5 The entry 3 of the real address table shown is marked as "(address of function 1)", indicating that the initial value of the entry 3 of the real address table is the default address.

[0111] Since both the call translation table and the real address table are generated after the program starts, and are generated by the dynamic linker, the address of the call translator in memory is known at this time (especially after the dynamic linker has completed bootstrapping). Therefore, the address of the call translator in memory can be directly embedded in the "jump to the call translator instruction (cluster)" in the call translation table (called a direct jump), without the need to first load the bound address from the default GOT table before jumping (called an indirect jump) as required by the original default PLT table. Of course, the latter methodology is still feasible, such as: allocating an entry in the real address table to store the address of the call translator, and then first obtaining the address of the call translator from the real address table in the call translation table entry before jumping to it. This will not be discussed in detail later.

[0112] Depending on whether the default GOT entries are pre-populated at initialization time (in this example, entries numbered 3 or greater, entries 1-2 are already filled in as a preparatory step for lazy binding), there are two slightly different implementations:

[0113] First, when the default GOT is not pre-populated, due to delayed binding, the corresponding call translation table entries in the existing GOT numbered 3 or greater can be omitted during initialization, retaining their default values. Consequently, when the corresponding PLT entry is first called, _dl_runtime_resolve is entered, where _dl_runtime_resolve completes the populating (binding) of the corresponding GOT entry and real address table entry. In this implementation, the initial values ​​of the real address table entries are not used at all, so any value they take does not affect subsequent processes.

[0114] The second type is when the original GOT table (i.e., the aforementioned default GOT table) is pre-filled: Since the call conversion table is dynamically generated, the addresses of its various entries are known after generation. Therefore, the corresponding entries of the call conversion table can be pre-filled into the entries numbered greater than or equal to 3 in the original GOT table during initialization, so there is no need to fill in the GOT table entries again later. However, due to delayed binding, the dynamic link library has not been loaded during initialization, so it is still necessary to enter _dl_runtime_resolve when the PLT table entry is called for the first time. Therefore, under this implementation, the initial value of the table entry in the real address table ultimately determines the execution flow when the PLT table entry is called for the first time, so it is necessary to pre-fill the agreed value into the table entry of the real address table at the same time to ensure that delayed binding works properly. The following is an example of the first implementation method.

[0115] It should be noted that _dl_runtime_resolve and the call converter do not necessarily need to be dynamically generated or loaded, they can be part of a modified dynamic linker. Figure 5 The entry numbers in the call translation table and real address table do not start at 0. This is simply to facilitate the correspondence between these entries and the original PLT and GOT. The starting numbering value is not meaningful, and non-consecutive numbering has no special meaning and does not necessarily correspond to each other. This can be applied to other examples by analogy.

[0116] Figure 6 A schematic diagram showing the first call to PLT entry 1 function 1 being bound.

[0117] like Figure 6 As shown, when the PLT table entry 1 in the instruction stream of the "first component" is called for the first time, it jumps to the table entry 1 of the original PLT table, and executes the "instruction that jumps to the address executed by GOT table entry 3" in the table entry 1 of the original PLT table to jump to the table entry 3 in the GOT table. The table entry 3 in the GOT table is the default address, which will be loaded into the value of the table entry 3 of the default GOT table, jump to the table entry 1 of the PLT table, and execute the "instruction (or instruction cluster) that loads the function number into the register of an instruction or pushes it into the stack" and "jumps to the instruction (cluster) of PLT table entry 0" in table entry 1, and then jumps to PLT table entry 0, and then jumps to _dl_runtime_resolve through PLT table entry 0.

[0118] Since this application modifies the original _dl_runtime_resolve, the behavior of _dl_runtime_resolve is as follows:

[0119] S61: If the dynamic link library containing function 1 has not yet been loaded, it is loaded. If it has already been loaded, there is no need to reload it. The key is to obtain the address of function 1. This is obtained by parsing the symbol table of the dynamic link library containing function 1, obtaining the address offset of function 1 within the dynamic link library, and then adding it to the address where function 1 is loaded.

[0120] S62, add the corresponding entry (in this example) to the real address table. Figure 6 The entry 3) in the real address table shown in FIG is filled with the address of function 1.

[0121] S63, add the corresponding entry in the original GOT table (in this example Figure 6 The entry 3 in the original GOT table shown in the figure is filled in with the corresponding entry in the call conversion table (in this example, Figure 6 The address of entry 1) in the call translation table is shown.

[0122] S64, the binding is complete. Since the instruction that triggered the delayed binding is ultimately intended to call function 1, after the delayed binding is complete, function 1 should still be called through the call converter in some way.

[0123] In some implementations, the dynamic linker can jump directly to entry 1 of the call translation table at this point. Entry 1 of the call translation table then loads the real address of the function from entry 3 of the real address table and jumps to the call translator. After jumping to the call translator, the call translator retrieves the function address from a specified register or on the stack and calls the function using the corresponding calling convention.

[0124] In some other implementations, the dynamic linker jumps to entry 1 of the PLT table. Since the address of entry 1 of the call translation table has been correctly filled in entry 3 of the original GOT table, PLT entry 1 will not jump to _dl_runtime_resolve via PLT entry 0 again, but can jump to entry 1 of the call translation table. The subsequent process can refer to the aforementioned implementation method.

[0125] Figure 7 A schematic diagram showing that function 1 has completed binding is shown.

[0126] After function 1 has completed binding, such as Figure 7 As shown, each time a jump is made to PLT entry 1 (i.e., entry 1 of the original PLT), the address of entry 1 in the call translation table can be directly loaded from entry 3 in the default GOT, allowing PLT entry 1 to jump directly to entry 1 in the call translation table. Furthermore, entry 1 in the call translation table can be directly loaded from entry 3 in the real address table to the address of function 1 and placed in a register or on the stack, thereby passing the address of function 1 to the call translator. The call translator can then retrieve the address of function 1 from a specific register or stack and complete the call translation.

[0127] In the third implementation, in the case of immediate binding, the binding process for all symbols is completed during program initialization. This implementation is applicable to both the unsimplified default PLT and GOT tables, as well as the simplified default PLT and GOT tables. When the first component is initialized, the dynamic linker completes the immediate binding process for all symbols dynamically linked to the first component and populates the second address of the first entry in memory into the second entry in the default GOT. When the third entry in the default PLT is called, the linker jumps to the third entry in the default PLT and executes the third instruction in the third entry to jump to the second entry in the default GOT.

[0128] In the fourth embodiment, in the absence of a real address table, the first instruction is used to indicate the use of immediate loading to directly load the first address of the first symbol; the first instruction in the first table entry is executed, and the first address of the first symbol in the memory is loaded into the first storage container using the immediate number.

[0129] In this implementation, as long as immediate binding is used, the address where the dynamically linked symbol will be loaded is already known when the call translation table is generated. Therefore, it is possible to generate instructions (clusters) that directly load (including but not limited to loading immediate values ​​into registers and / or onto the stack) the symbolic address and embed these instructions (clusters) into the call translation table, completely eliminating the need for a real address table. In this case, security can be achieved by locking the call translation PLT table as readable, executable, and non-writable after generation.

[0130] See also Figure 8 This is a schematic diagram without simplifying the PLT table and GOT table and without a real address table. Figure 8 As shown, the first instruction, "Load the address of function 1 using an immediate value into a specified register or on the stack," is directly embedded in the call translation table. The real address table is not used, allowing the symbolic address to be loaded directly through the call translation table. It should be understood that the existing PLT and GOT tables have been simplified, and the absence of a real address table is also feasible, which will not be discussed here.

[0131] Based on any of the above embodiments, after the call conversion table is generated, the call conversion table is set to be readable, executable, and non-writable. In specific implementation, the call conversion table can be first written to a writable memory area and then locked as readable, executable, but not writable.

[0132] The real address table for implementing delayed binding is set to be readable, writable and non-executable. In this case, the real address table is used to fill in the first address of the first symbol in the memory, or to fill in the agreed value indicating that the first symbol is not bound.

[0133] For the real address table implementing immediate binding, it should be initially readable, writable and non-executable when immediate binding is fully implemented until it becomes readable, non-writable and non-executable after immediate binding is completed. In this case, the real address table is used to fill in the first address of the first symbol in the memory.

[0134] In some possible implementations, the call translation PLT table and the real address table can be allowed to be generated and expanded on demand. For example, when implementing delayed binding, the dynamic linker may not generate the call translation table and the real address table in the initial work, but may leave them to be generated until the first delayed binding of a function that requires call translation. Regardless of when the call translation table and the real address table are generated, it is not necessary to immediately determine their size and generate all table entries, but they can be expanded (adding table entries) on demand. For example, each time a function that requires call translation is delayed is bound, if the corresponding table entry does not exist, it can be added. Based on this, the call translation table and the real address table do not necessarily need to be continuous, and the various table entries may not be continuous in memory address.

[0135] Based on any of the above embodiments, the addresses of the entries in the call translation table in the memory are continuous, or the addresses of the entries in the call translation table in the memory are discontinuous. The addresses of the entries in the real address table in the memory are continuous, or the addresses of the entries in the real address table in the memory are discontinuous.

[0136] In some possible cases, not all functions in the original PLT and GOT tables have corresponding entries in the call translation table and the real address table. Sometimes, the call translation table and the real address table may not even exist.

[0137] In one example, all dynamically linked functions are not cross-calling conventions: in this case, call translation is obviously not required, and thus the call translation table and real address table do not need to exist.

[0138] In another example, some dynamically linked functions are not cross-calling convention: these functions obviously do not need call translation, and their behavior when bound is the same as the existing technology, so they do not need corresponding entries in the call translation table and the real address table.

[0139] It's important to note that the terms "native" and "foreign" used in this application are relative and limited. They are not static, as perspectives change. Dynamic linkers must consider the native / foreign nature of calling conventions dialectically, depending on the user for whom they are performing symbolic linking and binding.

[0140] like Figure 9In the call scenario shown, program (executable file) A is dynamically linked to libraries B and C, and library B itself is dynamically linked to library C. Program A uses calling convention α, while libraries B and C use calling convention β. When the dynamic link library performs symbol resolution and binding for program A, the symbols from libraries B and C use the foreign calling convention, so function calls need to be redirected to the call translator. When the dynamic link library performs symbol resolution and binding for library B, the symbols from library C use the native calling convention, so function calls do not need to be redirected to the call translator. Functions from library C use the same calling convention β, but because the callers (program A / library B) differ, the native / foreign nature of their calling conventions differs from different perspectives.

[0141] In the embodiments of the present application, the binding of dynamically linked functions is entirely dependent on the dynamic linker. That is, when a program calls a function in a dynamic link library, the address ultimately called is determined entirely by the address entered into the default GOT by the dynamic linker. Based on this, by modifying the dynamic linker's binding process and replacing the address entered into the default GOT by the dynamic linker with the address of the corresponding entry (the first entry) in the call translation table in memory, the first component's call to the first symbol can be converted to a call to the first entry, thereby enabling the insertion of call translation without requiring manual intervention by the programmer or program recompilation.

[0142] In embodiments of the present application, by redirecting function calls to a call converter, problems in various scenarios can be solved. In some scenarios, even if the calling conventions do not match, there is no need to modify or recompile the existing executable file (program) and dynamic link library to enable the executable file to load the required dynamic link library. For example, in scenarios where the source code for the program or dynamic link library is unavailable (not delivered or lost, etc.), and recompiling them to match the calling conventions is impossible, the embodiments of the present application can solve this problem. In other scenarios, some calling conventions have significantly better performance, while others have greater compatibility. Therefore, the performance-sensitive parts of the software can be formed into a dynamic link library (using a calling convention with better performance), while the remaining parts can be formed into an executable file (using a calling convention with better compatibility), and the latter can be dynamically linked to the former. The present application is also applicable to such scenarios, and can simultaneously address the requirements of both performance and compatibility.

[0143] Based on the same technical concept, Figure 10 The following is a schematic structural diagram of a dynamic link call conversion device provided by an embodiment of the present invention, which can execute the above method flow.

[0144] like Figure 10As shown, the dynamic link call conversion device specifically includes:

[0145] A generating unit 1001 is configured to generate, through a dynamic linker, a first table entry of a call translation table if, when performing symbol resolution and binding for a first component, the first component is dynamically linked to a first symbol in a first dynamic link library, and no dynamic link symbol binding relationship is established between the first symbol and the first component, and the first component and the first dynamic link library use different calling conventions. The first table entry includes a first instruction and a second instruction, the first instruction being used to instruct loading a first address of the first symbol in a memory into a specified first storage container, and the second instruction being used to instruct jumping to a call translator.

[0146] The filling unit 1002 is used to fill the second address of the first table entry in the memory into the second table entry in the default GOT table through the dynamic linker; wherein the default GOT table belongs to the first component.

[0147] In one possible implementation, the dynamic link call conversion apparatus further includes a trigger unit 1003 and an execution unit 1004; the trigger unit 1003 is configured to trigger execution of a third instruction by the dynamic linker or the first component; wherein the third instruction uses the second address stored in the second entry in the default GOT table as an instruction and jumps to the first entry in the call conversion table according to the instruction;

[0148] The execution unit 1004 is configured to: execute a third instruction to jump to a first entry in a call conversion table; execute a first instruction in the first entry to load a first address of a first symbol in a memory into a first storage container; execute a second instruction to jump to a call converter; and the call converter is configured to accept a call from the first component using a first calling convention, and call the first symbol using a second calling convention according to the first address stored in the first storage container.

[0149] In one possible implementation, the dynamic linker also includes a dynamic link library runtime parsing component for establishing a dynamic link symbol binding relationship; the initial value of the second table entry in the default GOT table when the first component is initialized is a default value; the first component includes a third instruction; an execution unit 1004 is used to: when the first component triggers the execution of the third instruction for the first time, the third instruction uses the default value in the second table entry in the default GOT table as an indication, and jumps to the fourth instruction according to the indication; wherein the fourth instruction may be located in the default PLT table or the stub table; execute the fourth instruction and jump to the dynamic link library runtime parsing component; a filling unit 1002 is used to fill the second address into the second table entry in the default GOT table through the dynamic link library runtime parsing component.

[0150] In one possible implementation, the generation unit 1001 is used to generate a first table entry of the call translation table through a dynamic linker when the first component is initialized; the filling unit 1002 is used to fill the second address of the first table entry in the memory into the second table entry in the default GOT table.

[0151] In one possible implementation, the dynamic linker also includes a dynamic link library runtime parsing component for establishing a dynamic link symbol binding relationship; the filling unit 1002 is also used to: when the first component is initialized, pre-fill the fifth table entry of the real address table with an agreed value through the dynamic linker, and the agreed value is used to indicate that the first symbol is not bound; the triggering unit 1003 is also used to: trigger the execution of a third instruction through the dynamic linker or the first component; wherein the third instruction uses the second address stored in the second table entry in the default GOT table as an indication, and jumps to the first table entry of the call conversion table according to the indication; the execution unit 1004 is also used to: execute the third instruction, jump to the first table entry in the call conversion table; execute the first instruction in the first table entry, load the agreed value indicating that the first symbol is not bound from the fifth table entry of the real address table to the first storage container; execute the second instruction, jump to the call converter; determine that the first symbol is not bound according to the agreed value in the first storage container through the call converter, and jump to the dynamic link library runtime parsing component.

[0152] In a possible implementation, the filling unit 1002 is further configured to fill the first address of the first symbol in the memory into the fifth entry in the real address table through a dynamic link library runtime parsing component.

[0153] In one possible implementation, the execution unit 1004 is further used to: determine the first address of the first symbol in the memory according to the third address to which the first dynamic link library is loaded and the address offset of the first symbol in the first dynamic link library through the dynamic link library runtime parsing component.

[0154] In one possible implementation, the trigger unit 1003 is also used to: trigger the execution of the third instruction through the dynamic linker or the first component; the execution unit 1004 is also used to: execute the third instruction, jump to the first table entry in the call conversion table; execute the first instruction in the first table entry, load the first address of the first symbol from the fifth table entry in the real address table to the first storage container; execute the second instruction, jump to the call converter; the dynamic link call conversion device also includes a calling unit 1005, which is used to accept the call of the first component using the first calling convention through the calling converter, and call the first symbol using the second calling convention according to the first address stored in the first storage container.

[0155] In one possible implementation, the execution unit 1004 is specifically used to: when the first component is initialized, complete the immediate binding process of all symbols dynamically linked to the first component through the dynamic linker, and fill the second address of the first table entry in the memory into the second table entry in the default GOT table.

[0156] In one possible implementation, the first instruction is used to indicate the use of immediate loading to directly load the first address of the first symbol; the execution unit 1004 is further used to: execute the first instruction in the first table entry, and use the immediate number to load the first address of the first symbol in the memory to the first storage container.

[0157] In one possible implementation, the dynamic link call conversion device also includes a loading unit 1006, which is used to: determine whether to load the first dynamic link library; if it is determined through the dynamic linker that the first dynamic link library has not been loaded, search for the first dynamic link library in a search path that complies with the first calling convention used by the first component and all external calling conventions that can be supported by call conversion based on the name or path of the first dynamic link library; after searching for the first dynamic link library, load the first dynamic link library into the memory.

[0158] In a possible implementation, the generating unit 1001 is further configured to: after generating the call conversion table, set the call conversion table to be readable, executable, and non-writable.

[0159] In a possible implementation, the addresses of the entries in the call translation table in the memory are continuous, or the addresses of the entries in the call translation table in the memory are discontinuous.

[0160] In one possible implementation, the generation unit 1001 is further used to: for a real address table implementing delayed binding, set the real address table to be readable, writable, and non-executable, and the real address table is used to fill in the first address of the first symbol in the memory, or to fill in the agreed value indicating that the first symbol is not bound; or, for a real address table implementing immediate binding, set the real address table to be readable, non-writable, and non-executable, and the real address table is used to fill in the first address of the first symbol in the memory.

[0161] In a possible implementation, the addresses of the entries in the real address table in the memory are continuous, or the addresses of the entries in the real address table in the memory are discontinuous.

[0162] In a possible implementation, the first component is a program, or the first component is a second dynamic link library.

[0163] Based on the same technical concept, the embodiment of the present application provides a dynamic link call conversion device 1100, which can be a computing device. Figure 11 As shown, the dynamic link call conversion device 1100 includes at least one processor 1101 and a memory 1102 connected to the at least one processor. The specific connection medium between the processor 1101 and the memory 1102 is not limited in the embodiment of the present application. Figure 11 For example, the processor 1101 and the memory 1102 are connected via a bus. The bus can be divided into an address bus, a data bus, a control bus, and the like.

[0164] In an embodiment of the present application, the memory 1102 stores instructions that can be executed by at least one processor 1101. The at least one processor 1101 can implement the above-mentioned dynamic link call conversion method by executing the instructions stored in the memory 1102.

[0165] The processor 1101 is the control center of the abnormal instruction processing device 1100. It can connect various components of the computer device using various interfaces and lines, and perform resource settings by running or executing instructions stored in the memory 1102 and calling data stored in the memory 1102. Optionally, the processor 1101 may include one or more determination units. The processor 1101 may integrate an application processor and a modem processor, wherein the application processor primarily processes the operating system, user interface, and application programs, and the modem processor primarily processes wireless communications. It is understood that the modem processor may not be integrated into the processor 1101. In some embodiments, the processor 1101 and the memory 1102 may be implemented on the same chip. In some embodiments, they may also be implemented on separate chips.

[0166] Processor 1101 can be a general-purpose processor, such as a central processing unit (CPU), a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, and can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of this application. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly implemented as being executed by a hardware processor, or can be executed by a combination of hardware and software modules in the processor.

[0167] Memory 1102, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer executable programs, and modules. Memory 1102 may include at least one type of storage medium, such as flash memory, a hard disk, a multimedia card, a card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic storage, a magnetic disk, an optical disk, and the like. Memory 1102 is any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. Memory 1102 in the embodiments of the present application may also be a circuit or any other device capable of performing a storage function, used to store program instructions and / or data.

[0168] Based on the same technical concept, an embodiment of the present application also provides a computer-readable storage medium, which stores a computer-executable program. The computer-executable program is used to enable a computer to execute any of the above-mentioned dynamic link call conversion methods.

[0169] An embodiment of the present application provides a computer program product, including a computer program executable by a computer device. When the program runs on the computer device, the computer device executes the dynamic link call conversion method in any of the above-mentioned ways.

[0170] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0171] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the present application. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0172] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0173] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0174] Obviously, those skilled in the art may make various changes and modifications to this application without departing from the spirit and scope of this application. Thus, if these modifications and variations of this application fall within the scope of the claims of this application and their equivalents, this application is intended to include these modifications and variations.

Claims

1. A dynamic link call conversion method, characterized in that: include: If, when performing symbol resolution and binding for a first component, the first component is dynamically linked to a first symbol in a first dynamic link library, and a dynamic link symbol binding relationship with the first component is not established for the first symbol, and the first component and the first dynamic link library use different calling conventions, then when the first component is initialized or the first dynamic link library is latently bound to the first symbol, a first table entry in a call translation table is generated by a dynamic linker, the first table entry including a first instruction and a second instruction, the first instruction being used to instruct loading a first address of the first symbol in a memory into a specified first storage container, and the second instruction being used to instruct jumping to a call translator; the call translator being used to accept a call from the first component using the first calling convention, and to call the first symbol using the second calling convention according to the first address stored in the first storage container; The second address of the first table entry in the memory is filled into the second table entry in the default GOT table through the dynamic linker; wherein the default GOT table belongs to the first component.

2. The method according to claim 1, wherein After the dynamic linker fills the second address of the first entry in the memory into the second entry in the default GOT table, the method further includes: The execution of a third instruction is triggered by the dynamic linker or the first component; wherein the third instruction uses the second address stored in the second table entry in the default GOT table as an instruction and jumps to the first table entry in the call translation table according to the instruction; Executing the third instruction to jump to the first entry in the call conversion table; executing a first instruction in the first table entry to load a first address of the first symbol in the memory into the first storage container; Execute the second instruction and jump to the calling converter.

3. The method according to claim 1, wherein The dynamic linker also includes a dynamic link library runtime parsing component for establishing a dynamic link symbol binding relationship; the initial value of the second table entry in the default GOT table when the first component is initialized is a default value; The first component includes a third instruction; The step of filling the second address of the first entry in the memory into the second entry in the default GOT table by the dynamic linker includes: When the first component triggers the execution of the third instruction for the first time, the third instruction uses the default value in the second entry in the default GOT table as an indication and jumps to a fourth instruction according to the indication; wherein the fourth instruction is located in the default PLT table or the stub table; Execute the fourth instruction to jump to the dynamic link library runtime parsing component; The second address is filled into the second table entry in the default GOT table through the dynamic link library runtime parsing component.

4. The method according to claim 1, wherein The step of generating a first table entry of a call translation table by a dynamic linker, and filling a second address of the first table entry in a memory into a second table entry in a default GOT table by the dynamic linker, comprises: When the first component is initialized, a first table entry of a call translation table is generated by the dynamic linker, and the second address of the first table entry in the memory is filled into the second table entry in the default GOT table.

5. The method according to claim 4, wherein The dynamic linker also includes a dynamic link library runtime parsing component for establishing a dynamic link symbol binding relationship; the method also includes: When the first component is initialized, pre-filling a fifth entry of the real address table with a predetermined value through the dynamic linker, where the predetermined value is used to indicate that the first symbol is not bound; The execution of a third instruction is triggered by the dynamic linker or the first component; wherein the third instruction uses the second address stored in the second entry in the default GOT table as an instruction and jumps to the first entry in the call translation table according to the instruction; Executing the third instruction to jump to the first entry in the call conversion table; executing a first instruction in the first table entry to load the agreed value indicating that the first symbol is not bound from a fifth table entry of the real address table into a first storage container; Execute the second instruction and jump to the call converter; The calling converter determines that the first symbol is not bound according to the agreed value in the first storage container, and jumps to the dynamic link library runtime parsing component.

6. The method according to claim 3 or 5, wherein: After jumping to the dynamic link library runtime parsing component, the method further includes: The first address of the first symbol in the memory is filled into the fifth table entry in the real address table through the dynamic link library runtime parsing component.

7. The method according to claim 6, wherein Before the dynamic link library runtime parsing component fills the first address of the first symbol in the memory into the fifth entry in the real address table, the method further includes: The dynamic link library runtime parsing component determines the first address of the first symbol in the memory according to the third address to which the first dynamic link library is loaded and the address offset of the first symbol in the first dynamic link library.

8. The method according to claim 6, wherein After the dynamic link library runtime parsing component fills the first address of the first symbol in the memory into the fifth entry in the real address table, the method further includes: triggering execution of a third instruction by the dynamic linker or the first component; Executing the third instruction to jump to the first entry in the call conversion table; executing the first instruction in the first entry to load the first address of the first symbol from the fifth entry in the real address table into the first storage container; Execute the second instruction and jump to the call converter; The call translator accepts a call from the first component using a first calling convention, and calls the first symbol using a second calling convention according to the first address stored in the first storage container.

9. The method according to claim 2, wherein The step of filling the second address of the first entry in the memory into the second entry in the default GOT table by the dynamic linker includes: When the first component is initialized, the dynamic linker completes an immediate binding process for all symbols dynamically linked to the first component, and fills the second address of the first entry in the memory into the second entry in the default GOT table.

10. The method according to claim 1, wherein The first instruction is used to instruct to directly load the first address of the first symbol using immediate load; the method further includes: A first instruction in the first table entry is executed to load a first address of the first symbol in the memory into the first storage container using an immediate value.

11. The method according to claim 1, wherein The method further comprises: Determining whether to load the first dynamic link library; If it is determined through the dynamic linker that the first dynamic link library has not been loaded, searching for the first dynamic link library in a search path that complies with a first calling convention used by the first component and all foreign calling conventions supported by call translation, based on the name or path of the first dynamic link library; After searching for the first dynamic link library, the first dynamic link library is loaded into the memory.

12. The method according to claim 1, wherein The method further comprises: After the call conversion table is generated, the call conversion table is set to be readable, executable, and non-writable.

13. The method according to claim 1, wherein The addresses of the entries in the call translation table in the memory are continuous, or the addresses of the entries in the call translation table in the memory are discontinuous.

14. The method according to claim 2, wherein The method further comprises: For a real address table implementing delayed binding, the real address table is set to be readable and writable but not executable, and the real address table is used to fill in the first address of the first symbol in the memory, or to fill in a predetermined value indicating that the first symbol is not bound; or For a real address table for implementing immediate binding, the real address table is set to be readable, non-writable, and non-executable, and the real address table is used to fill in the first address of the first symbol in the memory.

15. The method according to claim 5, wherein The addresses of the entries in the real address table in the memory are continuous, or the addresses of the entries in the real address table in the memory are discontinuous.

16. The method according to claim 1, wherein The first component is a program, or the first component is a second dynamic link library.

17. A computer device, characterized in that: include: a memory for storing program instructions; A processor is configured to call the program instructions stored in the memory and execute the method according to any one of claims 1 to 16 according to the obtained program.

18. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute the method according to any one of claims 1 to 16.

19. A computer program product, characterized in that The invention comprises a computer program executed by a computer device, which causes the computer device to execute the steps of the method according to any one of claims 1 to 16 when the program is run on the computer device.

Images