Method and device for expanding user space, computing equipment and storage medium

Abstract

The invention provides a method and device for expanding user space, computing equipment and a storage medium, and the method comprises the steps: determining a first dynamic link library and a second dynamic link library when a memory application is not completed due to exhaustion of the user space; the second dynamic link library refers to a dynamic link library which does not have a dependency relationship with a caller of the memory application function; determining an address range which can be vacated in the memory if the second dynamic link library is unloaded, and determining a global offset table (GOT) item which needs to be modified according to the address range; the memory address recorded by the GOT entry needing to be modified falls into the address range, and the GOT entry needing to be modified is the GOT entry of an object having a dependency relationship with the second dynamic link library; modifying the memory address recorded by the GOT table item to be modified into a set value; the set value is used for indicating reloading of the second dynamic link library; and releasing the loading of the second dynamic link library. According to the scheme, the virtual memory can be effectively expanded.

Description

Technical Field

[0001] This application relates to the field of computer technologies, and in particular, to a method, apparatus, computing device, and storage medium for expanding the user space. Background Art

[0002] Virtual memory is generally divided into non-overlapping kernel space and user space. User programs can only access the user space. That is to say, the maximum virtual memory space that a user program can use depends on the size of the user space. For example, for some instruction set architectures, the total virtual memory is 4GB, of which the user space is 2GB and the kernel space is 2GB. If the 2GB corresponding to the user space has been completely used up by the user program, then when the user program applies for virtual memory from the kernel again, the kernel cannot allocate virtual memory to this user program anymore, and eventually the program crashes.

[0003] Then, how to expand virtual memory remains to be solved. Summary of the Invention

[0004] This application provides a method, apparatus, computing device, and storage medium for expanding the user space, which can effectively expand virtual memory.

[0005] In a first aspect, an embodiment of this application provides a method for expanding the user space. This method can be executed by a device for expanding the user space. The device for expanding the user space can be a terminal device or a module for a terminal device, or a server or a module for a server. This application does not limit the execution subject of this method. The method includes: when a memory application fails due to the exhaustion of the user space, determining a first dynamic link library and a second dynamic link library; the first dynamic link library refers to a dynamic link library that has a dependency relationship with the caller of the memory application function; the second dynamic link library refers to a dynamic link library that has no dependency relationship with the caller of the memory application function; determining the address range that will be vacated in the memory if the second dynamic link library is unloaded, and determining the global offset table (GOT) entries to be modified according to the address range; the memory addresses recorded in the GOT entries to be modified fall within the address range, and the GOT entries to be modified are the GOT entries of objects that have a dependency relationship with the second dynamic link library; modifying the memory addresses recorded in the GOT entries to be modified to a set value; the set value is used to indicate the reloading of the second dynamic link library; unloading the second dynamic link library.

[0006] The above solution can alleviate the problem of insufficient user space by dynamically and on-demand unloading the second dynamic link library without modifying the hardware or the kernel.

[0007] In a possible implementation method, determine the direct caller of the memory application function, determine the dynamic link library to which the direct caller of the memory application function belongs as the first dynamic link library, and determine one or more dynamic link libraries that do not belong to the direct caller of the memory application function as the second dynamic link library; or, analyze the call chain of the memory application function, determine the dynamic link libraries located in the call chain as the first dynamic link library, and determine one or more dynamic link libraries not in the call chain as the second dynamic link library; the call chain includes callers that directly or indirectly call the memory application function.

[0008] The above solution can accurately and effectively determine the second dynamic link library, and then can relieve the shortage of user space by unloading the second dynamic link library.

[0009] In a possible implementation method, determine all loaded dynamic link libraries; for any dynamic link library among all the loaded dynamic link libraries, if the dynamic link library is the direct caller of the memory application function or is located in the call chain of the memory application function, then exclude the dynamic link library from all the loaded dynamic link libraries; select at least one dynamic link library from the all loaded dynamic link libraries after the exclusion, and determine it as the second dynamic link library.

[0010] The above solution can accurately and effectively determine the second dynamic link library, and then can relieve the shortage of user space by unloading the second dynamic link library.

[0011] In a possible implementation method, analyze the call chain of the memory application function by means of stack backtracking.

[0012] The above solution can accurately and effectively determine the call chain.

[0013] In a possible implementation method, determine the objects that have a dependency relationship with the second dynamic link library; the dependency relationship includes direct dependency or indirect dependency; the objects include dynamic link libraries and / or the user program itself; scan all GOT tables of the objects that have a dependency relationship with the second dynamic link library, and determine any table entry of any GOT table that falls within the address range as the GOT table entry to be modified.

[0014] The above solution can accurately and effectively determine the GOT table entry to be modified.

[0015] In a possible implementation method, for any GOT table entry to be modified, use the memory address for lazy binding in the procedure link table PLT entry corresponding to the GOT table entry or the memory address of the stub table entry corresponding to the GOT table entry as the set value, and fill it into the GOT table entry.

[0016] In the above solution, the memory address for lazy binding in the procedure link table (PLT) entry corresponding to the GOT table entry or the memory address of the stub table entry corresponding to the GOT table entry is used as the set value, so that any GOT table entry that needs to be modified can trigger reloading automatically when it is used again later.

[0017] In a possible implementation method, before unloading the second dynamic link library, a PLT table or stub table for reloading is established for the second dynamic link library without a PLT table or stub table, and a corresponding PLT table entry or stub table entry for reloading is created.

[0018] The above solution can accurately and effectively determine the set value.

[0019] In a possible implementation method, the sections with non-writable permissions in the second dynamic link library are unloaded.

[0020] In a possible implementation method, the sections with executable and non-writable permissions in the second dynamic link library are unloaded.

[0021] In a possible implementation method, the section with executable and non-writable permissions is specifically the code section, that is, the ".text section".

[0022] In a possible implementation method, the address range vacated in memory by unloading the section with executable and non-writable permissions is set to non-executable.

[0023] The above solution can safely unload the second dynamic link library without producing destructive effects.

[0024] In a possible implementation method, the second dynamic link library is reloaded.

[0025] In a possible implementation method, according to the remaining user space, an attempt is made to reload all unloaded dynamic link libraries; or, the second dynamic link library currently required to be called by the user program is reloaded.

[0026] The above solution can accurately and effectively reload the second dynamic link library.

[0027] In a possible implementation method, the section header table of the second dynamic link library is determined; according to the section header table, the offset, size, and / or permission attributes of the section to be reloaded in the second dynamic link library are determined; according to the offset, size, and / or permission attributes of the section to be reloaded in the second dynamic link library, the kernel is requested to load the section of the second dynamic link library.

[0028] In a possible implementation method, the section to be reloaded is the section that was previously unloaded from the second link library.

[0029] The above solution can accurately and effectively reload the second dynamic link library.

[0030] In a possible implementation method, for an object that has a dependency relationship with the second dynamic link library, re - establish the binding relationship with the second dynamic link library.

[0031] The above solution, by re - establishing the binding relationship between the object that has a dependency relationship with the second dynamic link library and the second dynamic link library, can ensure the correctness of the program running effect.

[0032] In a possible implementation method, the re - establishing the binding relationship with the second dynamic link library includes: when an object that has a dependency relationship with the second dynamic link library needs to call any function in the second dynamic link library, re - establish the binding relationship required for this call.

[0033] In a possible implementation method, the re - establishing the binding relationship with the second dynamic link library includes: after re - loading the second dynamic link library, scan all GOT tables of the objects that have a dependency relationship with the second dynamic link library, and determine the linking target of all GOT table entries; if the linking target belongs to the second dynamic link library, determine the corresponding GOT table entry as the GOT table entry that needs to re - establish the binding relationship; for any GOT table entry that needs to re - establish the binding relationship, fill in the memory address of the linking target into the GOT table entry.

[0034] The above solution can efficiently and with low overhead re - establish the binding relationship between the object that has a dependency relationship with the second dynamic link library and the second dynamic link library, and can reduce the impact of re - binding on program running and improve program running efficiency.

[0035] In a possible implementation method, the method is executed by the dynamic linker.

[0036] The above solution can improve general applicability.

[0037] In a second aspect, an embodiment of the present application provides a device for expanding the user space, including: a determination unit, a modification unit, and an unloading unit. The determination unit is configured to determine a first dynamic link library and a second dynamic link library when a memory application fails due to exhaustion of the user space; the first dynamic link library refers to a dynamic link library that has a dependency relationship with the caller of the memory application function; the second dynamic link library refers to a dynamic link library that has no dependency relationship with the caller of the memory application function; determine the address range that will be vacated in the memory if the second dynamic link library is unloaded, and determine the global offset table (GOT) entries to be modified according to the address range; the memory addresses recorded in the GOT entries to be modified fall within the address range, and the GOT entries to be modified are the GOT entries of objects that have a dependency relationship with the second dynamic link library; the modification unit is configured to modify the memory addresses recorded in the GOT entries to be modified to a set value; the set value is used to indicate the reloading of the second dynamic link library; the unloading unit is configured to unload the second dynamic link library.

[0038] In a possible implementation method, the determination unit is configured to determine the direct caller of the memory application function, determine the dynamic link library to which the direct caller of the memory application function belongs as the first dynamic link library, and determine one or more dynamic link libraries that do not belong to the direct caller of the memory application function as the second dynamic link library; or, the determination unit is configured to analyze the call chain of the memory application function, determine the dynamic link libraries located in the call chain as the first dynamic link library, and determine one or more dynamic link libraries not in the call chain as the second dynamic link library; the call chain includes the callers that directly or indirectly call the memory application function.

[0039] In a possible implementation method, the determination unit is configured to determine all the loaded dynamic link libraries; for any one of all the loaded dynamic link libraries, if the dynamic link library is the direct caller of the memory application function or is located in the call chain of the memory application function, then exclude the dynamic link library from all the loaded dynamic link libraries; select at least one dynamic link library from the all loaded dynamic link libraries after the exclusion, and determine it as the second dynamic link library.

[0040] In a possible implementation method, the determination unit is configured to analyze the call chain of the memory application function by means of stack backtracking.

[0041] In a possible implementation method, a determination unit is configured to determine an object having a dependency relationship with the second dynamic link library; the dependency relationship includes a direct dependency or an indirect dependency; the object includes a dynamic link library and / or the user program itself; scan all GOT tables of the object having a dependency relationship with the second dynamic link library, and determine any table entry of any GOT table falling within the address range as a GOT table entry to be modified.

[0042] In a possible implementation method, a modification unit is configured to, for any GOT table entry to be modified, use the memory address for lazy binding in the procedure link table PLT table entry corresponding to the GOT table entry or the memory address of the stub table entry corresponding to the GOT table entry as a set value, and fill it into the GOT table entry.

[0043] In a possible implementation method, an unloading unit is configured to, before unloading the second dynamic link library, establish a PLT table or a stub table for reloading for the second dynamic link library without a PLT table or a stub table, and create a corresponding PLT table entry or stub table entry for reloading.

[0044] In a possible implementation method, an unloading unit is configured to unload a section in the second dynamic link library with non-writable permission.

[0045] In a possible implementation method, an unloading unit is configured to unload a section in the second dynamic link library with executable and non-writable permission.

[0046] In a possible implementation method, an unloading unit is configured to set the address range vacated in memory by unloading the executable and non-writable section to non-executable.

[0047] In a possible implementation method, the above device further includes a reloading unit configured to reload the second dynamic link library.

[0048] In a possible implementation method, a reloading unit is configured to attempt to reload all unloaded dynamic link libraries according to the remaining user space; or, reload the second dynamic link library currently required to be called by the user program.

[0049] In a possible implementation method, a determination unit is configured to determine the section header table of the second dynamic link library; according to the section header table, determine the offset, size, and / or permission attribute of the section to be reloaded in the second dynamic link library; a reloading unit is configured to request the kernel to load the section of the second dynamic link library according to the offset, size, and / or permission attribute of the section to be reloaded in the second dynamic link library.

[0050] In a possible implementation method, a reloading unit is configured to re - establish a binding relationship with the second dynamic - link library for an object that has a dependency on the second dynamic - link library. In a possible implementation method, the above - mentioned apparatus further includes an execution unit, and the execution unit is configured to execute any method of the first aspect through a dynamic linker.

[0051] In a possible implementation method, the above - mentioned apparatus further includes a re - binding unit. The re - binding unit is configured to re - establish a binding relationship required for this call when an object that has a dependency on the second dynamic - link library needs to call any function in the second dynamic - link library.

[0052] In a possible implementation method, the re - binding unit is configured to, after re - loading the second dynamic - link library, scan all Global Offset Tables (GOTs) of the objects that have a dependency on the second dynamic - link library, and determine the linking targets of all GOT entries; if the linking target belongs to the second dynamic - link library, determine the corresponding GOT entry as the GOT entry that needs to re - establish the binding relationship; for any GOT entry that needs to re - establish the binding relationship, fill the memory address of the linking target into the GOT entry.

[0053] In a third aspect, an embodiment of the present application further provides a computing device, including: A memory, configured to store program instructions; A processor, configured to call the program instructions stored in the memory and execute any method of the first aspect according to the obtained program instructions.

[0054] In a fourth aspect, an embodiment of the present application further provides a computer - readable storage medium, in which computer - readable instructions are stored. When a computer reads and executes the computer - readable instructions, any method of the first aspect is implemented.

[0055] In a fifth aspect, 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 is caused to execute any method of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] Figure 1 It is a schematic flowchart of a method for expanding a user space provided by an embodiment of the present application; Figure 2 It is a schematic flowchart of a method for determining a second dynamic - link library provided by an embodiment of the present application; Figure 3A And Figure 3B It is a schematic flowchart of a method for determining a second dynamic - link library provided by an embodiment of the present application; Figure 4A and Figure 4B is a schematic flowchart of a method for determining a second dynamic link library provided by an embodiment of the present application; Figure 5 is a schematic flowchart of a method for determining GOT table entries to be modified provided by an embodiment of the present application; Figure 6 is a schematic structural diagram of a dependency relationship provided by an embodiment of the present application; Figure 7A and Figure 7B is a schematic flowchart of a method for determining a potential reverse dependency set provided by an embodiment of the present application; Figure 8A and Figure 8B is a schematic flowchart of a method for determining a potential reverse dependency set provided by an embodiment of the present application; Figure 9A and Figure 9B is a schematic flowchart of a method for determining GOT table entries to be modified provided by an embodiment of the present application; Figure 10A and Figure 10B is a schematic flowchart of a method for modifying GOT table entries provided by an embodiment of the present application; Figure 11 is a schematic flowchart of a method for unloading a target provided by an embodiment of the present application; Figure 12 is a schematic flowchart of a method for reloading a second dynamic link library provided by an embodiment of the present application; Figure 13 is a schematic flowchart of a method for reloading a second dynamic link library provided by an embodiment of the present application; Figure 14 is a schematic flowchart of a method for unloading a second dynamic link library provided by an embodiment of the present application; Figure 15 is a schematic flowchart of a method for unloading a second dynamic link library provided by an embodiment of the present application; Figure 16 is a schematic flowchart of a method for modifying a memory application function provided by an embodiment of the present application; Figure 17 is a schematic structural diagram of a program dependency relationship provided by an embodiment of the present application; Figure 18 is a schematic structural diagram of a PLT table and a GOT table provided by an embodiment of the present application; Figure 19 is a schematic structural diagram of a stub table and a GOT table provided by an embodiment of the present application; Figure 20Structural schematic diagram of a device for expanding user space provided by an embodiment of the present application; Figure 21 Structural schematic diagram of a device for expanding user space provided by an embodiment of the present application. Detailed implementation manners

[0057] The following briefly introduces the basic terms used in the embodiments of the present application.

[0058] Kernel space / user space: Virtual memory is divided into two sections, kernel space and user space. Since both the kernel and user programs need memory to run, they both need to occupy a certain amount of virtual memory space. Therefore, it can also be said that the kernel runs on the kernel space, and the user program runs on the user space. Due to its privileges, the kernel can access the user space; due to the lack of privileges in the user space, accessing the kernel space will cause an exception. The sizes occupied by the two spaces in virtual memory are usually architecture-specific, such as the division of kernel space and user space in 32-bit MIPS. The kernel space and user space evenly divide the 4GiB of 32-bit virtual memory space, each getting the upper 2GiB and the lower 2GiB. For x86, the kernel space occupies the upper 1GiB, and the user space occupies the lower 3GiB.

[0059] Dynamic linking or static linking: Used to link object files and the dependent function libraries together to form an executable file or a function library.

[0060] When the linker completes dynamic linking, it only writes some characteristic information of the dynamic link library into the executable file or function library, rather than writing the dynamic link library itself into the latter. These characteristic information are used to guide the dynamic linker. Therefore, the actual linking work (loading and binding) is left to the dynamic linker to complete when the program is running.

[0061] When the linker completes static linking, it first merges each object file and static link library into a binary file (similar to the loading in dynamic linking), and then modifies the references to addresses in the machine code according to the offset positions of each object file and static link library after merging (similar to the binding in dynamic linking).

[0062] 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. Taking a software project or function library project of a certain scale as an example, which has several source code files, there may be, but are not limited to, the following situations: 1. The object files compiled from these source code files are often statically linked together to form a single executable file (single product) or a library (single product). These object files become part of a single product.

[0063] 2. In rare cases, some of the object files may also be statically linked into a library (dynamic link library, product 1), and then the remaining object files are statically linked into an executable program (product 2), and the latter (product 2) is then dynamically linked to the former (product 1).

[0064] 3. Such a software may depend on some external libraries in addition to its own source code. Depending on the linking options passed to the linker, some of the libraries may be statically linked and become part of one or more of the above products (possibly the single product in case 1, or product 1 and / or product 2 in case 2); some may be dynamically linked to one or more of the above products (same as before). Depending on the linking options passed to the linker, it is also possible that all external libraries are statically linked or dynamically linked.

[0065] The PLT table, also known as the Procedure Linkage Table, extracts the long indirect jumps based on the GOT table, so that the main instruction stream only needs to simply jump to the PLT table entry, and it also serves as a stub for the first call in the case of lazy binding. The PLT table is executable but not writable during program execution to prevent accidental overwriting of the PLT table from causing program execution errors or even security vulnerabilities. The instructions (clusters) for the secondary jumps in the PLT table are optional (can be embedded in the main instruction stream), and the stub in it is also optional in the case of immediate binding.

[0066] The GOT table, also known as the Global Offset Table, is the soul of dynamic linking. It is used by the dynamic linker to fill in various addresses that can only be determined at runtime, especially the addresses of bound symbols, and they are absolute addresses (hence the name: global offset). The GOT table is readable and writable but not executable when the program starts; for lazy binding, since the GOT table may be modified at any time during program execution due to lazy binding, it will always remain readable and writable but not executable; for immediate binding, preferably, it should be set to readable but not writable and not executable after binding (that is, when the program just starts and the dynamic linker has completed its initial work), so as to prevent accidental overwriting of the GOT table from causing program execution errors or even security vulnerabilities.

[0067] The initial value of the GOT entry is the key to lazy binding. Since the addresses stored in the GOT table are absolute addresses, for those dynamic link libraries with GOT tables (or some programs that allow loading and execution at arbitrary addresses, i.e., position-independent executables PIE, which are commonly used to implement address space layout randomization ASLR), the addresses they are loaded at during runtime cannot be determined during compilation (including the link phase during compilation, the same below). Then the initial value of the GOT entry will be a relative address. After the dynamic link library is loaded (or after the above special program starts), the dynamic linker will fix this initial value to an absolute address (simply add the starting address where the dynamic link library / program is loaded to the entry). It should be noted that such a fix does not mean symbol binding. Such a fix is just one part of the preparatory work for lazy binding.

[0068] Dynamic linker: The dynamic linker (dynamic linker / loader) is responsible for completing the dynamic linking work during program runtime. On GNU / Linux, it is ld.so. Particularly popular is ld.so implemented by the GNU LIBC (GLIBC) project, and this application takes it as an example.

[0069] Figure 1 It is a flowchart of a method for expanding the user space provided by an embodiment of this application. This method can be executed by a device for expanding the user space, and the device for expanding the user space can be a terminal device or a module for a terminal device, or a server or a module for a server. This application does not limit the execution entity of this method.

[0070] This method includes the following steps: Step 101, when a memory application fails due to exhaustion of the user space, determine the first dynamic link library and the second dynamic link library.

[0071] Among them, the first dynamic link library refers to the dynamic link library that has a dependency relationship with the caller of the memory application function; the second dynamic link library refers to the dynamic link library that has no dependency relationship with the caller of the memory application function.

[0072] Step 102, determine the address range that will be freed in memory if the second dynamic link library is unloaded, and determine the GOT entries of the global offset table that need to be modified according to the address range.

[0073] Among them, the memory address recorded in the GOT entry to be modified falls within the address range, and the GOT entry to be modified is the GOT entry of an object that has a dependency relationship with the second dynamic link library.

[0074] Step 103: Modify the memory address recorded in the GOT entry to be modified to a set value.

[0075] Among them, the set value is used to indicate the reloading of the second dynamic link library. This application does not limit the specific acquisition method of the set value, nor does it limit the specific value of the set value.

[0076] Step 104: Unload the second dynamic link library.

[0077] The above solution can, without modifying the hardware or the kernel, alleviate the problem of insufficient user space by dynamically and on-demand unloading the second dynamic link library.

[0078] In a possible implementation method, in the above step 101, as long as a dynamic link library is not being used, it can be unloaded at any time. This application does not limit the timing of unloading the dynamic link library.

[0079] However, a more efficient way should be to unload only when the user space is exhausted and memory allocation cannot be completed. In other words, when processing memory allocation, if the memory allocation fails, it may indicate that the user space is exhausted, and at this time, unloading can be triggered. Further, the trigger for unloading can be implicit or explicit: if it is implicit, it can be triggered by the memory allocation function when the memory allocation fails; if it is explicit, it can be triggered by the caller of the memory allocation function after receiving the memory allocation failure indication (including errors, etc.) returned by the memory allocation function.

[0080] The embodiments of this application are all described according to the implicit trigger for unloading. The explicit situation is similar and will not be elaborated here.

[0081] In a possible implementation method, in the above step 101, the determination of the first dynamic link library and the second dynamic link library includes: determining the direct caller of the memory allocation function, determining the dynamic link library to which the direct caller of the memory allocation function belongs as the first dynamic link library, and determining one or more dynamic link libraries that do not belong to the direct caller of the memory allocation function as the second dynamic link library; or, analyzing the call chain of the memory allocation function, determining the dynamic link libraries located in the call chain as the first dynamic link library, and determining one or more dynamic link libraries not in the call chain as the second dynamic link library; the call chain includes the callers that directly or indirectly call the memory allocation function.

[0082] In a possible implementation method, the method for determining the second dynamic link library is as follows Figure 2 shown, and includes the following steps: Step 201, determine all the loaded dynamic link libraries.

[0083] Step 202, for any one of the loaded dynamic link libraries, if the dynamic link library is the direct caller of the memory application function or is located in the call chain of the memory application function, then exclude the dynamic link library from all the loaded dynamic link libraries.

[0084] Step 203, select at least one dynamic link library from all the loaded dynamic link libraries after the exclusion, and determine it as the second dynamic link library.

[0085] Next, the two cases of Step 202 are analyzed separately.

[0086] The first case is that the dynamic link library is the direct caller of the memory application function.

[0087] As we know, when unloading a dynamic link library to free up user space, only those dynamic link libraries that are not being used can be selected.

[0088] Function call is essentially a process of jumping from one function (caller) to another function (callee), and after the callee finishes execution, it jumps back to the caller, and then the caller can continue to execute. Before a function call, the caller must place the return address after the function call (usually pointing to the next instruction or the next n instructions of the instruction for the function call, and this address must belong to the caller) somewhere in memory (usually somewhere on the stack) or on a certain register (and it will most likely be backed up to the stack eventually). Only in this way can the callee jump back to the caller by reading out this address after it finishes execution, and the caller can continue to execute. Therefore, by reading out the above return address, the callee can determine its caller at any time. And given an address, the dynamic linker can determine the dynamic link library it comes from.

[0089] Therefore, when a piece of code calls a memory application function (which can also be called a (dynamic) memory allocation function, such as malloc() or calloc() in the C standard library (libc)) because of applying for memory, we can determine who called the function from the return address; therefore, we can determine which dynamic link library (or the program itself) is applying for memory, and this dynamic link library should be excluded from the current candidate list of dynamic link libraries that can be unloaded.

[0090] Based on this, in the first case where the dynamic link library is not loaded, when the user space is exhausted and the memory application cannot be completed, the direct caller of the memory application function is determined, and one or more dynamic link libraries that are not the direct callers of the memory application function are unloaded. It is not necessary to unload all the dynamic link libraries that are not the direct callers of the memory application function. One or more of them can also be selected only. This is because in many cases, the memory application does not require a large memory area. Therefore, it can be tried to unload fewer dynamic link libraries first to see if this is sufficient to make the memory application successful. If there are no dynamic link libraries that can be unloaded after excluding the direct callers of the memory application function, an indication of failed unloading is returned; further, the caller of the memory application function can interpret such an indication as a memory application failure (an error occurred in the memory application).

[0091] In a possible implementation method, the method for unloading one or more dynamic link libraries that are not the direct callers of the memory application function is as Figure 3A and Figure 3B shown. This method includes the following steps: Step 301, when triggering the unloading, determine all the loaded dynamic link libraries (excluding the dynamic linker).

[0092] Theoretically, the dynamic linker is not unloaded.

[0093] Step 302, determine the caller of the memory application function.

[0094] Step 303, determine the dynamic link library of the caller.

[0095] Step 304, remove the dynamic link library of the caller from the set of dynamically unloadable link libraries.

[0096] Step 305, determine whether the set of dynamically unloadable link libraries is empty.

[0097] Optionally, if the set of dynamically unloadable link libraries is empty, an indication of failed unloading is returned; if it is not empty, select one or more dynamic link libraries from the set of dynamically unloadable link libraries to generate a set of dynamically unloadable link libraries. Among them, the set of dynamically unloadable link libraries is the second dynamic link library, and all the loaded dynamic link libraries excluding the second dynamic link library are the first dynamic link library.

[0098] In the second case, the dynamic link library is located in the call chain of the memory application function.

[0099] Suppose there is such a call chain: a certain function in the program itself -> a certain function in dynamic link library A -> a certain function in dynamic link library B -> a certain function in dynamic link library C -> a memory allocation function.

[0100] This call chain means that: 1. The program has executed to a certain function in the program itself; 2. For some need, the above-mentioned certain function from the program itself calls a certain function from dynamic link library A; 3. For some need, the above-mentioned certain function from dynamic link library A calls a certain function from dynamic link library B; 4. For some need, the above-mentioned certain function from dynamic link library B calls a certain function from dynamic link library C; 5. For some need, the above-mentioned certain function from dynamic link library C calls the memory allocation function to allocate a section of memory.

[0101] When the memory allocation function finishes execution, then: 1. The memory allocation function returns, and the above-mentioned certain function from dynamic link library C continues to complete the remaining work (if any); 2. The above-mentioned certain function from dynamic link library C returns, and the above-mentioned certain function from dynamic link library B continues to complete the remaining work (if any); 3. The above-mentioned certain function from dynamic link library B returns, and the above-mentioned certain function from dynamic link library A continues to complete the remaining work (if any); 4. The above-mentioned certain function from dynamic link library A returns, and the above-mentioned certain function from the program itself continues to complete the remaining work (if any); 5. The program continues to execute.

[0102] Then when the memory allocation function returns, it will return to the above-mentioned certain function in dynamic link library C; and so on, subsequently returning to the above-mentioned certain function in dynamic link library B, the above-mentioned certain function in dynamic link library A, and finally returning to the above-mentioned certain function in the program itself.

[0103] As can be seen from the above process, the dynamic link library C is the direct caller of the memory application function. If only the direct caller of the memory application function (i.e., the dynamic link library C in this example) is excluded from the candidate list of dynamic link libraries that can be unloaded, the dynamic link libraries A and B are still in the candidate list. Try to imagine that if the dynamic link library B is unloaded, although the memory application function returns to "a certain function in the dynamic link library C" after execution, and at this time the program can continue to run normally because the dynamic link library C is not unloaded; but once "a certain function in the dynamic link library C" is executed and returns to "a certain function in the dynamic link library B", since the dynamic link library B is unloaded, the corresponding memory area has been allocated to other memory applications, so the place returned to is no longer "a certain function in the dynamic link library B", which leads to memory misuse. Similarly, if the dynamic link library A is unloaded, once "a certain function in the dynamic link library B" is executed and returns to "a certain function in the dynamic link library A", the corresponding memory area has also been allocated to other memory applications, so the place returned to is no longer "a certain function in the dynamic link library A", which also leads to memory misuse.

[0104] Based on this, the second case of unloading the dynamic link library in this application is proposed. When the user space is exhausted and the memory application cannot be completed, analyze the call chain of the memory application function and unload one or more dynamic link libraries that are not in the call chain. That is, when determining the candidate list of dynamic link libraries that can be unloaded currently, not only the direct caller of the memory application function (such as "a certain function in the dynamic link library C" in the above example) needs to be determined, but also all indirect callers (such as "a certain function in the dynamic link library A" and "a certain function in the dynamic link library B" in the above example) need to be determined in a chain, and the dynamic link libraries corresponding to these direct and indirect callers are all excluded from the candidate list (corresponding to the above example, that is, excluding the dynamic link libraries A, B, and C). In other words, all dynamic link libraries in the call chain are excluded.

[0105] In a possible implementation method, the method of unloading one or more dynamic link libraries that are not in the call chain is as Figure 4A and Figure 4B shown. This method includes the following steps: Step 401, when triggering the unloading, determine the initial members of the set of dynamic link libraries that can be unloaded.

[0106] In a possible implementation method, all loaded dynamic link libraries (excluding the dynamic linker) are determined as the initial members of the set of dynamic link libraries that can be unloaded.

[0107] Step 402: Determine which function triggered the unloading, and identify the function as the function to be analyzed.

[0108] In a possible implementation, the memory allocation function is identified as the function to be analyzed.

[0109] Step 403: Determine whether the function to be analyzed has a caller.

[0110] If the function to be analyzed has no caller, execute Step 406; if the function to be analyzed has a caller, execute Step 404.

[0111] Step 404: Determine the dynamic link library of the caller, and remove the dynamic link library of the caller from the set of dynamically loadable and unloadable dynamic link libraries.

[0112] Step 405: Use the caller as the function to be analyzed.

[0113] In a possible implementation, use the caller as the function to be analyzed and re - execute Step 403.

[0114] This application does not limit the execution order of Step 404 and Step 405, and they can also be executed simultaneously.

[0115] Step 406: Determine whether the set of dynamically loadable and unloadable dynamic link libraries is empty.

[0116] Optionally, if the set of dynamically loadable and unloadable dynamic link libraries is empty, return an indication of unloading failure; if not, select one or more dynamic link libraries from the set of dynamically loadable and unloadable dynamic link libraries to generate a set of dynamic link libraries to be unloaded, where the set of dynamic link libraries to be unloaded is the second dynamic link library.

[0117] In a possible implementation, analyze the call chain of the memory allocation function by means of stack backtracking. This application does not limit the method of analyzing the call chain of the memory allocation function.

[0118] Among them, stack backtracking is to restore the current and all previous stack frames (stackframe) according to the state of the program at a certain moment, and each stack frame corresponds to a function in the call chain. In particular, at a specific position in the stack frame, there will be a return address. Since the return address can be used to determine the caller, the call chain of the program at this moment can be determined.

[0119] In a possible implementation method, backtracking is performed successively through the frame pointer register (also known as the stack frame pointer register, framepointer, FP, BP, EBP, RBP) in combination with the previously backed-up frame pointer in the stack. Among them, the starting address of the current stack frame can be determined through the frame pointer.

[0120] Specifically, the ending address of the current stack frame can be determined through the stack pointer register, and then the frame pointer of the previous stack frame that has been backed up can be obtained at a specific position in the current stack frame. Furthermore, the starting address of the previous stack frame can be determined, and then the starting address of the stack frame before the previous one can be obtained in the same way in the previous stack frame, and so on.

[0121] In another possible implementation method, backtracking is performed successively through the stack pointer register (stack pointer, SP, ESP, RSP) in combination with the frame mapping table (such as.eh_frame) in the debugging information (such as DWARF) in the program (executable file) or dynamic link library. Among them, the ending address of the current stack frame can be determined through the stack pointer.

[0122] Specifically, the value in the stack pointer register is always reliable, and it always points to the ending address of the current stack frame; however, only the stack pointer register is not enough to backtrack to the previous stack frame. At this time, we do not know the starting address of the current stack frame (and thus cannot calculate the ending address of the previous stack frame). It is still necessary to determine the starting position of the current stack frame, or the size of the current stack frame, or the ending position of the previous stack frame (knowing any one of these three can be combined with the stack pointer to calculate the other two) in order to locate the previous stack frame. For the previous stack frame, it is also necessary to know any one of its aforementioned three attributes in order to locate the stack frame before the previous one, and so on.

[0123] Optionally, the frame mapping table (such as.eh_frame) in the debugging information (such as DWARF) can give these information.

[0124] In one embodiment, by rewriting the GOT table, subsequent use of the unloaded dynamic link library can trigger reloading. Then, after reloading, the corresponding symbols also need to be bound to these rewritten GOT table entries, that is, re-binding. In other words, reloading and re-binding are dynamically triggered due to subsequent use of the unloaded dynamic link library, and we need to perform some preparatory work for reloading and re-binding to make such dynamic triggering possible.

[0125] In a possible implementation method, in step 102 above, the method for determining the GOT table entries to be modified according to the address range is as Figure 5 shown, and this method includes the following steps: Step 501: Determine the objects that have a dependency relationship with the second dynamic link library.

[0126] Among them, the dependency relationship includes direct dependency or indirect dependency; the objects include dynamic link libraries and / or the user program itself.

[0127] Step 502: Scan all the GOT tables of the objects that have a dependency relationship with the second dynamic link library, and determine any entry in any GOT table that falls within the address range as the GOT table entry to be modified.

[0128] The following explains the objects that have a dependency relationship with the second dynamic link library.

[0129] Figure 6 Exemplarily, the dependency relationships between the program itself and dynamic link libraries A, B, C, and D are shown. Among them, the program itself depends on dynamic link libraries A and D; dynamic link library A depends on dynamic link libraries B and C; dynamic link library B depends on dynamic link library C; dynamic link library C depends on dynamic link library D. If described according to reverse dependency, the following direct reverse dependencies can be determined: dynamic link library A is depended on by the program itself; dynamic link library B is depended on by dynamic link library A; dynamic link library C is depended on by dynamic link libraries A and B; dynamic link library D is depended on by dynamic link library C and the program itself. Among them, the definition of reverse dependency is being depended on, that is, if X depends on Y, then Y is depended on by X. Therefore, we have: Y is the forward dependency of X, and X is the reverse dependency of Y.

[0130] In a possible implementation method, the method for determining the objects that have a direct dependency relationship with the second dynamic link library is as Figure 7A and Figure 7B shown. This method includes the following steps: Step 701: Select any dynamic link library from the set of unloaded dynamic link libraries.

[0131] Among them, the set of unloaded dynamic link libraries is the second dynamic link library.

[0132] Step 702: Add the dynamic link library to the potential reverse dependency set.

[0133] Among them, the objects included in the potential reverse dependency set are the objects that have a dependency relationship with the second dynamic link library.

[0134] Step 703: Add the dynamic link library or the program itself that directly depends on the dynamic link library to the potential reverse dependency set until the set of unloaded dynamic link libraries is empty.

[0135] Analyze the dependency relationships of the current program and all dynamic link libraries, find all dynamic link libraries that directly depend on this dynamic link library, and add them to the potential reverse dependency set. If the program also directly depends on this dynamic link library, then add the program to the potential reverse dependency set as well. This is because there will be entries in the GOT table of the dynamic link library (or the program itself) that directly depends on the unloaded dynamic link library bound to the unloaded dynamic link library. The unloaded dynamic link library itself should also be added to the potential reverse dependency set because there are also some GOT table entries in the dynamic link library that bind to its own symbols. In other words, the dynamic link library is also its own implicit potential reverse dependency.

[0136] The reason it is called the potential reverse dependency set here is that the effect caused by unloading the second dynamic link library depends on the section selected during unloading: if there are only reverse dependencies on writable data, as long as the unloaded section does not contain a writable section, these reverse dependencies will not be broken; if there are only reverse dependencies on data (writable or read-only), as long as the unloaded section is limited to the executable and non-writable section (especially the.text section, i.e., the code section), these reverse dependencies will not be broken either. Nevertheless, even if a potential reverse dependency is a reverse dependency that will not be broken by unloading, adding it to the potential reverse dependency set will do no harm.

[0137] Based on Figure 6 the example, if dynamic link library A is unloaded: dynamic link library A and the program itself will be added to the potential reverse dependency set. If dynamic link library B is unloaded: dynamic link libraries A and B will be added to the potential reverse dependency set. If dynamic link library C is unloaded: dynamic link libraries A, B, and C will be added to the potential reverse dependency set. If dynamic link library D is unloaded: dynamic link libraries C, D, and the program itself will be added to the potential reverse dependency set.

[0138] In one possible implementation method, by recursively determining direct reverse dependencies, all indirect reverse dependencies can be determined. The method for determining the objects that have an indirect reverse dependency relationship with the second dynamic link library is as Figure 8A and Figure 8B shown. The method includes the following steps: Step 801, select any dynamic link library from the set of unloaded dynamic link libraries.

[0139] Step 802, add the current program and all dynamic link libraries recursively dependent on the dynamic link library to the potential reverse dependency set until the set of unloaded dynamic link libraries is empty.

[0140] Based on Figure 6For example, if the dynamic link library A is unloaded: the dynamic link library A and the program itself will be added to the potential reverse dependency set. If the dynamic link library B is unloaded: the dynamic link libraries A, B and the program itself will be added to the potential reverse dependency set. If the dynamic link library C is unloaded: the dynamic link libraries A, B, C and the program itself will be added to the potential reverse dependency set. If the dynamic link library D is unloaded: the dynamic link libraries A, B, C, D and the program itself will be added to the potential reverse dependency set.

[0141] In a possible implementation method, for the above step 502, the method of scanning all GOT tables of the objects that have a dependency relationship with the second dynamic link library and determining any table entry in any GOT table that falls within the address range as the GOT table entry to be modified is as Figure 9A and Figure 9B shown. This method includes the following steps: Step 901, select any dynamic link library (or the program itself) from the potential reverse dependency set.

[0142] Step 902, scan all GOT tables of this dynamic link library (or the program itself).

[0143] Step 903, according to the set of address ranges vacated due to unloading, add the table entries whose all table entry values fall within the address range set to the affected GOT table entry set.

[0144] Step 904, repeatedly execute steps 901 to 903 until the potential reverse dependency set is empty.

[0145] Each dynamic link library and / or the current program in the potential reverse dependency set will have at least one GOT table, and these GOT tables are called "affected GOT tables". Analyze each table entry of the GOT tables of these dynamic link libraries and / or the current program. If the value of a table entry falls within the original address range of the section being unloaded, add it to the "affected GOT table entry" set.

[0146] In a possible implementation method, for any GOT table entry to be modified, use the memory address for lazy binding in the procedure link table PLT entry corresponding to the GOT table entry or the memory address of the stub table entry corresponding to the GOT table entry as the set value and fill it into the GOT table entry. The present application does not limit the specific content of the set value.

[0147] In a possible implementation method, the set value is the initial value in the case of lazy binding. This application does not limit how to restore the initial value. For example, the initial value can be obtained by calculation, or by creating a backup of the initial GOT table when the program starts or when the dynamic link library is first loaded and querying the backup when needed.

[0148] In a possible implementation method, the set value is a certain fixed identifier, which is used to indicate obtaining the initial value in the case of lazy binding. That is, when the program obtains this set value, it triggers the execution of an instruction to obtain the initial value in the case of lazy binding according to this set value.

[0149] Since the dynamic link library may not be loaded to the same address when it is reloaded later, the old value of the affected GOT table entry may become an incorrect value at that time, so it needs to be rebound at that time. Therefore, we should now prepare for these GOT table entries to be able to trigger re-binding in the future. Modify the value of the above-mentioned affected GOT table entry to restore it to the initial value in the case of lazy binding. That is, for the case of using the PLT table, point to the trampoline for lazy binding in the corresponding PLT table entry; for the case of not using the PLT table, point to the corresponding stub table entry (these two cases are essentially the same because the content of the stub table entry is the trampoline for lazy binding). It should be noted that among all the dynamic link libraries that a program recursively depends on, some can use the PLT table while others do not, and this is not in conflict.

[0150] In a possible implementation method, the method of modifying the GOT table entry is as Figure 10A shown, and this method includes the following steps: Step 1001, select any GOT table entry from the set of affected GOT table entries.

[0151] Step 1002, restore the value of the GOT table entry to the initial value of lazy binding.

[0152] In a possible implementation method, determine whether the dynamic link library corresponding to the GOT table entry uses the PLT table. If it does, determine the corresponding PLT table entry of the GOT table entry, and determine the trampoline address for lazy binding in the PLT table entry, and modify the value of the GOT table entry according to the trampoline address; if it does not, determine the address of the corresponding stub table entry of the GOT table entry, and modify the value of the GOT table entry according to the address of the stub table entry.

[0153] In a possible implementation method, before unloading the second dynamic link library, a PLT table or stub table for reloading is established for the second dynamic link library without a PLT table or stub table, and corresponding PLT table entries or stub table entries for reloading are created. This situation will be described in detail later.

[0154] Step 1003, repeatedly execute Step 1001 to Step 1002 until the set of affected GOT table entries is empty.

[0155] The specific implementation of the above steps, as Figure 10B shown, will not be elaborated here.

[0156] In a possible implementation method, when a function in the unloaded dynamic link library is used, since the value in the corresponding GOT table entry has been rewritten as the initial value in the case of lazy binding, the call to the function (the "target function") in the unloaded dynamic link library will ultimately cause the dynamic link library runtime resolution function (_dl_runtime_resolve) to be called.

[0157] In a possible implementation method, modify the behavior of the dynamic link library runtime resolution function so that it can load the corresponding dynamic link library when it has not been loaded yet, and then perform the binding. At this time, the dynamic linker can complete the reloading of the dynamic link library and the rebinding of the target function, and then can normally call the real target function.

[0158] In one embodiment, the second dynamic link library is not completely unloaded, only some of its components, that is, certain sections, are unloaded.

[0159] In a possible implementation method, unload the sections in the second dynamic link library with non-writable permissions.

[0160] If a section is writable (commonly such as.data,.rodata,.bss, etc.), then during the execution of the program, the data in it is likely to be modified. Once it is unloaded, when it is reloaded later, these modifications will be lost. If a section is not writable, then it can be unloaded and no data will be lost when it is reloaded later.

[0161] In a possible implementation method, unload the sections in the second dynamic link library with executable and non-writable permissions.

[0162] If a section storing read-only data is unloaded, it cannot be re-triggered for loading when it is needed next time. Executable sections store various functions. After they are unloaded, as long as the GOT table is appropriately rewritten (for example, restored to the initial state of lazy binding), subsequent calls to these functions can be redirected to the dynamic linker to trigger reloading. There is an additional benefit when it comes to executable and non-writable sections. If you want to jump to an address for execution, this address must have the executable attribute; otherwise, it is a memory misuse. For an unloaded executable and non-writable section, after unloading, the kernel can be requested to set the corresponding area as non-executable. Then, when this area is later used for memory allocation, since memory allocation is generally for data and will not reset this area as executable, this can prevent accidentally jumping to this area and treating data as instructions. This helps to detect errors in the program earlier.

[0163] In a possible implementation method, the address range vacated in memory by unloading the executable and non-writable section is set as non-executable.

[0164] In a possible implementation method, the.text section (code segment) of the second dynamic link library is unloaded; and after unloading, the kernel is requested to set the memory area where the.text section originally located as non-executable.

[0165] Some programs may have some custom executable and non-writable sections, and unloading them may have unexpected risks. Based on this, we may want to only unload well-known executable and non-writable sections. The most representative section in executable and non-writable sections is the.text section (also called the code segment, code section,.text segment), which is also usually the largest-sized section in the dynamic link library. The benefit of unloading it is the highest, and the risk is also relatively predictable.

[0166] In a possible implementation method, some components of the second dynamic link library are unloaded, such as Figure 11 shown, which will not be elaborated here.

[0167] In one embodiment, after unloading the second dynamic link library, it further includes: reloading the second dynamic link library.

[0168] In a possible implementation method, according to the remaining user space, an attempt is made to reload all unloaded dynamic link libraries. If the remaining user space is sufficient, all unloaded dynamic link libraries can be reloaded; if the remaining user space is not enough to reload all unloaded dynamic link libraries, according to the remaining user space and the memory amount required by the unloaded dynamic link libraries, an attempt is made to reload some of the unloaded dynamic link libraries.

[0169] In another possible implementation method, the second dynamic link library currently required to be called by the user program is reloaded. That is, when the user program currently needs to use the functions in the unloaded dynamic link library, the unloaded second dynamic link library is reloaded.

[0170] In a possible implementation method, the method for reloading the second dynamic link library is as Figure 12 shown and includes the following steps: Step 1201: Determine the section header table of the second dynamic link library.

[0171] Step 1202: According to the section header table, determine the offset, size, and / or permission attributes of the section to be reloaded in the second dynamic link library.

[0172] Step 1203: According to the offset, size, and / or permission attributes of the section to be reloaded in the second dynamic link library, request the kernel to load the section of the second dynamic link library.

[0173] Optionally, directly copy the data in the section into memory, or request the kernel to establish a named memory mapping to load the section to be reloaded.

[0174] In a possible implementation method, after reloading the second dynamic link library, it further includes: for the objects that have a dependency relationship with the second dynamic link library, re - establish the binding relationship with the second dynamic link library.

[0175] After reloading, all affected GOT table entries related to these sections can be immediately rebound (analogous to immediate binding), or only the GOT table entry that triggered this reloading can be rebound (analogous to deferred binding). In the latter case, the remaining un - reloaded affected GOT table entries corresponding to these sections will cause the dynamic link library runtime resolution function to be called when they are used, and then they can be bound.

[0176] In a possible implementation method, the set value of the GOT table entry triggers re - binding, and after re - binding, it conditionally triggers reloading.

[0177] In a possible implementation method, the method for reloading the second dynamic link library is as Figure 13 shown. This method is executed by the dynamic link library runtime resolution function, and this method includes the following steps: Step 1301: Determine the GOT table entry that triggers deferred binding (re - binding) and the symbol to be bound.

[0178] Step 1302, determine whether the symbol is on a loaded section.

[0179] In a possible implementation method, if the symbol is on a loaded section, then execute Step 1304; otherwise, execute 1303.

[0180] Step 1303, determine various attributes of the section according to the information in the second dynamic link library section header table, and use the above attributes to load the section.

[0181] In a possible implementation method, the specific behavior of Step 1303 is as follows Figure 12 as shown in Steps 1201 - 1023.

[0182] Step 1304, bind the symbol.

[0183] In a possible implementation method, bind all affected GOT table entries related to the symbol.

[0184] In another possible implementation method, bind all affected GOT table entries related to the second dynamic link library.

[0185] In yet another possible implementation method, only bind the symbols corresponding to the GOT table entries that trigger lazy binding (rebinding). For other symbols, they can be temporarily not bound and then bound when the lazy binding (rebinding) corresponding to these symbols is triggered later (equivalent to the other symbols will trigger lazy binding (rebinding) later and then execute the process as shown in Figure 13 Steps 1301 - 1305 for these other symbols at that time).

[0186] Step 1305, jump to the function that triggers lazy binding (rebinding).

[0187] Any dynamic link library (in fact, it also applies to programs and executable files, and these files are collectively called relocatable files ELF) can be divided into many sections (section, also translated as segment, sub - segment). The uses of each section are not the same. Some sections are used to store read - only data, some are used to store the initial values of readable and writable data, and generally the largest section is the code section, also called the code segment, which stores the machine code that can be executed by the CPU.

[0188] There is metadata used to describe each section, and such metadata is usually stored in the form of a section header. The collection of section headers is called a section header table. The section header describes the attributes of the section, and the most important ones are: 1. The permission attributes of the section. That is, whether it is writable and whether it is executable; corresponding to the flags W and X in the section header respectively.

[0189] 2. The position of the section in the file (i.e., the offset) and the size (length) of the section.

[0190] Whether the kernel is loading an executable file (program) or the dynamic linker is loading a dynamic link library, it depends on these attribute information to correctly perform the loading.

[0191] In order to correctly load a dynamic link library into memory, the dynamic linker needs to perform a series of delicate operations. Although the dynamic linker is also a kind of dynamic link library, since the dynamic linker is often loaded by the kernel, how it is loaded will not be discussed here; we focus on how the dynamic linker loads other dynamic link libraries, especially how to load it into memory when a dynamic link library to be loaded is found.

[0192] 1. Open the dynamic link library and find the section header table in it.

[0193] 2. From each section header in the section header table, know the position of each section of the dynamic link library in the file, the size of the section, and its permission attributes.

[0194] 3. For each section, use the position of the section in the file, the size of the section, the permission attributes, and the file descriptor of the opened dynamic link library as parameters of the system call, and pass them to the kernel to request the kernel to establish a named memory mapping (file mapping).

[0195] This application provides another embodiment, which can be used in the case of immediate binding.

[0196] In the case of lazy binding, a crucial step is to determine which GOT entry in which dynamic link library (or the current program) triggers the lazy binding. If this cannot be determined, then neither can we determine which symbol to bind nor which GOT entry to modify to complete the binding. The "instruction (cluster) that loads the function number into a certain specified register or pushes it onto the stack" in the trampoline for lazy loading in the PLT entry (or stub entry) corresponding to the GOT entry (except the 0th entry) solves the problem of "which GOT entry". Also, since there is an "instruction (cluster) that loads the link_map address into a certain specified register or pushes it onto the stack" in the 0th PLT entry (or stub entry), the problem of "determining which dynamic link library (or this program)" can be solved.

[0197] However, for the case of immediate binding, if the PLT table is used, the trampoline for lazy loading is optional, and the PLT table entry 0 is also optional; if the PLT table is not used, the stub table is optional. This brings a problem: if the above elements are missing, the two questions of "which GOT table entry" in "which dynamic link library (or the current program)" cannot be solved only by modifying the GOT table entry during reloading or rebinding.

[0198] In a possible implementation method, before unloading the second dynamic link library, a PLT table or a stub table for reloading is established for the second dynamic link library without a PLT table or a stub table, and the corresponding PLT table entry or stub table entry for reloading is created.

[0199] Specifically, for each affected GOT table entry, if it has a situation where the above elements for lazy binding are omitted (the corresponding PLT table entry lacks the trampoline for lazy binding; or the corresponding PLT table lacks entry 0; or the corresponding PLT table and stub table are missing), then a "stub table for reloading and rebinding" is established for the dynamic link library or the current program from which it originates (note that it is not bound to). If such a stub table has been previously created for this dynamic link library and / or the current program, then that stub table can be reused. If a dynamic link library or the current program uses lazy binding for some symbols and does not use the PLT table, then it will have a stub table for lazy binding.

[0200] Optionally, the newly created stub table here is for the reloading and rebinding of those symbols that must be immediately bound due to the omission of the above elements for lazy binding, and is different from the original stub table for lazy binding.

[0201] In a possible implementation method, for each affected GOT table entry, a corresponding stub table entry is established in the corresponding stub table, and then the value of the affected GOT table entry is modified to the address of the corresponding stub table entry; if the corresponding stub table has been previously created and there is already a corresponding stub table entry for a certain GOT table entry, there is no need to repeat the establishment of the stub table entry, and the value of the affected GOT table entry can be directly modified to the address of the corresponding stub table entry.

[0202] In a possible implementation method, when a function in an unloaded dynamic link library is used, since the value in the corresponding GOT table entry has been rewritten as the address of the corresponding entry in the newly created stub table, the call to the function in the unloaded dynamic link library (the "target function") will ultimately cause the dynamic link library runtime resolution function (_dl_runtime_resolve) to be called.

[0203] In a possible implementation method, lazy binding and immediate binding may coexist. Even for the same dynamic link library, some symbols may use lazy binding while others may use immediate binding.

[0204] In a possible implementation method, the structure of each newly created stub table is as follows: The content of the 0th item is "the instruction (cluster) that loads the identifier of the corresponding dynamic link library (or the current program) into a specified register or pushes it onto the stack" and "the instruction (cluster) that jumps to the dynamic link library runtime resolution function".

[0205] Among them, the "identifier of the corresponding dynamic link library (or the current program)" is used to determine which dynamic link library (or the current program) triggers the re-binding or re-loading. Exemplarily, it can be the link_map address of the corresponding dynamic link library (or the current program). It should be noted that if the link_map address is loaded, it can be loaded from the 0th entry of the GOT table used for lazy binding of this dynamic link library (or the current program), or from elsewhere in memory, or loaded using an immediate number; this application does not make any limitations in this regard. If other identifiers are loaded, they can be loaded from somewhere in memory or loaded using an immediate number; this application does not make any limitations in this regard.

[0206] The "instruction (cluster) that jumps to the dynamic link library runtime resolution function" can be to first load the address of the dynamic link library runtime resolution function from a certain entry (such as entry 2) of the GOT table used for lazy binding and then jump there (which is equivalent to the "instruction (cluster) that jumps to the address pointed to by GOT table entry 2" in the previous text, where this GOT refers to the GOT used for lazy binding); it can also be to load the address of the dynamic link library runtime resolution function from elsewhere in memory and then jump there; it can also be a jump instruction (cluster) using an immediate number, and this application does not make any limitations in this regard.

[0207] This application provides another embodiment. The difference between this embodiment and the above embodiment is that when the dynamic link library is first loaded, some sections are skipped.

[0208] In a possible implementation method, when the runtime resolution function in the dynamic linker implements the function of loading a dynamic link library before the corresponding dynamic link library is loaded, a part of the sections are skipped during the first loading of the dynamic link library. The method for selecting the sections is similar to the method for selecting the unloaded sections described above, and will not be elaborated here.

[0209] Specifically, for lazy binding, since the affected GOT table entries are not bound yet and maintain the initial value of lazy loading, and the runtime resolution function in the dynamic linker has been modified to be able to load the dynamic link library from which the symbol to be bound comes when the latter is not loaded, then, if a part of the sections of a part of the dynamic link libraries are not loaded at startup, when lazy binding is triggered, these unloaded dynamic link libraries can naturally be loaded back as needed. In this way, we achieve that the first loading becomes dynamic and on-demand, rather than being completed immediately at startup. Simply put, as long as we make the runtime resolution function in the dynamic linker be able to load the dynamic link library from which the symbol to be bound comes when the latter is not loaded, then we can benefit from the implementation method of skipping a part of the sections during the first loading of the dynamic link library without any additional modification in the case of lazy binding.

[0210] In a possible implementation method, for the case of immediate binding (accurately speaking, when there is an element for lazy binding omitted in a section skipped during the first loading), we only need to, on this basis, create a stub table (different from the stub table used for lazy binding) for each dynamic link library and / or the current program where there are affected GOT table entries and immediate binding exists in these entries, then for each GOT table entry using immediate binding, create a corresponding table entry for the stub in the corresponding stub table, and then modify the value of the affected GOT table entry to the address of the corresponding stub table entry.

[0211] Optionally, the creation of the stub table is the same operation as creating a PLT table or a stub table for reloading for the second dynamic link library without a PLT table or a stub table described above, and the same table is created. In other words, in the case of immediate binding, the stub table created here is also the stub table for reloading.

[0212] The following further analyzes how to trigger the unloading of a dynamic link library when memory cannot be allocated.

[0213] In a possible implementation method, by modifying the existing memory allocation function or writing a new memory allocation function, when a memory allocation fails due to exhaustion of the user space, unloading of the dynamic link library is triggered.

[0214] In a possible implementation method, when it is impossible to allocate the required amount of memory from the kernel, unloading of the dynamic link library is triggered; if the unloading is successful, an attempt is made again to allocate the required amount of memory from the kernel. If the re-attempt also fails, unloading of the dynamic link library is triggered again, so that progressive unloading can be achieved (in other words, only a small number of sections in a small number of dynamic link libraries can be unloaded each time). A certain number of retry attempts is set. If, after exceeding the set number of retries, the attempt to allocate the required amount of memory from the kernel still fails, it is considered that the situation of user space exhaustion is very serious, and an error is returned or raised. The method is specifically as Figure 14 shown and will not be elaborated here.

[0215] In another possible implementation method, the original memory allocation function is retained, and a wrapper layer is added on this basis to trigger the unloading of the dynamic link library when a memory allocation fails due to exhaustion of the user space.

[0216] In a possible implementation method, when it is impossible to allocate the required amount of memory from the original memory allocation function, unloading of the dynamic link library is triggered; if the unloading is successful, an attempt is made again to allocate the required amount of memory from the original memory allocation function. If the re-attempt also fails, unloading of the dynamic link library is triggered again, so that progressive unloading can be achieved. A certain number of retry attempts is set. If, after exceeding the set number of retries, the attempt to allocate the required amount of memory from the original memory allocation function still fails, it is considered that the situation of user space exhaustion is very serious, and an error is returned or raised. The method is specifically as Figure 15 shown and will not be elaborated here.

[0217] In another possible implementation method, the method is executed by the dynamic linker.

[0218] Based on the above scheme, since the trigger timing for unloading is located in the memory allocation function, the memory allocation function needs to have the ability to trigger unloading. For an existing executable file, the memory allocation function it uses may come from the executable file itself, may come from a certain dynamic link library, or may come from the dynamic linker in some cases. In some cases, it may also be a combination of these situations, such as: the executable file itself uses the memory allocation function from itself, but the dynamic link library linked by the executable file uses the memory allocation function from another dynamic link library.

[0219] That is to say, for the memory request function from the executable file itself, it is impossible to make the memory request through the function benefit from the present application without recompiling the executable file. In other words, if an existing executable file only uses its own memory request function (this also includes the case of using only static links), it is impossible to benefit from the present application without recompiling it.

[0220] As long as an executable file uses a memory allocation function from a dynamic link library or a dynamic linker directly or indirectly (e.g., via a dynamic link library that it depends on or recursively depends on), the memory allocation via the memory allocation function from the dynamic link library or the dynamic linker can benefit from the present application.

[0221] If an executable file directly or indirectly uses a memory request function from a dynamic linker, since this application itself is to modify the dynamic linker, it is only necessary to modify the memory request function in the dynamic linker so that it has the ability to trigger unloading when memory cannot be allocated.

[0222] If an executable file directly or indirectly uses a memory request function from a dynamic link library, then since this function must be loaded and bound by the dynamic linker before it can be used, the dynamic linker can bind it to another memory request function with the ability to trigger unloading when completing the binding for this function, so that the call to the memory request function can be hijacked. The other memory request function with the ability to trigger unloading may, for example, come from a dynamic link library, may come from a dynamic linker, or may be created on-site, and there is no special limitation here. For example, the other memory request function with the ability to trigger unloading may be a memory request function independent of the existing memory request function, and it has the ability to trigger unloading (such as the first example in the previous section), which we call an independent memory request function with the ability to trigger unloading; or it may be a wrapper created for the existing memory request function from the dynamic link library, which is equivalent to adding the ability to trigger unloading to the existing memory request function from the dynamic link library, which we call a wrapper function. The method is as follows: Figure 16 As shown, no further details are given here.

[0223] The following explains why the GOT entries that need to be modified should be restored to their initial values ​​in the case of delayed binding.

[0224] The following is a specific example to illustrate.

[0225] Program (executable file) A is dynamically linked to library B and library C, and library B itself is also dynamically linked to library C. As Figure 17 shown.

[0226] At a certain moment during the execution of program A, it has not directly called function 1 from library C yet, but has called function 2 in library B, and function 2 will call function 1. Then: Since function 2 is called by program A, it has been bound for program A; Since function 1 is called by function 2 in library B, it has also been bound for library B. Therefore, at this time, both function 1 and 2 have been loaded into memory (being loaded into memory is a necessary but not sufficient condition for successful binding). At this time, in the GOT table of program A, function 2 has been bound, while function 1 has not been bound yet; In the GOT table of library B, function 1 has been bound.

[0227] Program A continues to execute, and finally it directly calls function 1 from library C. At this time, function 1 is already in memory, and the dynamic linker does not need to perform the loading step anymore. All it needs to do is to correctly fill in its address into the GOT table of program A. At this time, in the GOT table of program A, functions 1 and 2 have been bound; In the GOT table of library B, function 1 has been bound.

[0228] It can be seen that in fact, the GOT table and the PLT table to be described below are not globally shared, but each of program A, library B, and library C has its own copy, and their contents are different from each other. That is to say, not only programs that use dynamic linking will have their own GOT table and PLT table, but the dynamically linked libraries themselves will also have them, so that the dynamic linker itself will also have them.

[0229] Next, taking the x86 GNU LIBC dynamic linker as an example, the data structures and processes involved in lazy binding will be described. Under different architectures and when using different dynamic linkers, the various names below may change, but the overall idea remains the same.

[0230] First of all, before the program starts, it is obviously impossible to know in advance which address the dynamically linked function will be loaded into. Therefore, most of the data in the GOT table remains unfilled, as Figure 18 shown.

[0231] Among them, what is more special is that for the address of the dynamically linked function (for Figure 18In the GOT entry 3 - 4), the GOT table pre - fills default values for them, that is, the address of the next instruction of the instruction (cluster) "jump to the address pointed to by GOT entry n" in the corresponding PLT entry, that is, the address of the first instruction of the instruction (cluster) "load the function number into a certain specified register or push it onto the stack".

[0232] This is a very ingenious design. Imagine that: Since the corresponding dynamically - linked function is not bound, when executing the instruction (cluster) "jump to the address pointed to by GOT entry n", the corresponding GOT entry is loaded (its value is still the default value), thus jumping to the instruction (cluster) "load the function number into a certain specified register or push it onto the stack", and then continuing to jump to PLT entry 0, and finally entering _dl_runtime_resolve (the dynamic - link library runtime resolution function) to complete lazy binding. This is exactly the basis for the re - binding to be automatically triggered as described above. However, it doesn't mean that any randomly selected default value of the GOT entry can achieve this goal. After jumping to the address pointed to by the default value, when continuing to execute at that address, the function number must be loaded into a certain specified register or pushed onto the stack, and it must also be able to finally jump to the dynamic - link library runtime resolution function.

[0233] After completing lazy binding, when executing the instruction (cluster) "jump to the address pointed to by GOT entry n" again, the corresponding GOT entry is loaded (its value is already the correct address of the corresponding function), thus being able to jump to the corresponding function.

[0234] The content of the PLT entry is often called a trampoline. The original meaning is "trampoline", often translated as "bounce bed", indicating that it plays the role of a "springboard". We can say that the PLT entry (except entry 0) in this example has two trampolines. The first is the instruction (cluster) "jump to the address pointed to by GOT entry n", and the remaining content for lazy binding is the second. Therefore, it can be said that the ingenuity of lazy binding lies in: when using the first trampoline for the first time, the destination of the jump is the second trampoline, and the destination of the jump of the latter is _dl_runtime_resolve, so that lazy binding can be completed. After lazy binding is completed, the destination of the jump of the first trampoline is the linked function, and then the second trampoline has completed its mission and becomes ineffective.

[0235] Figure 19shows the structure of the stub table. A significant difference in operation between this solution and the above solution is that after the function is bound, for each function call with dynamic linking, the number of jumps is one less than that of the solution with PLT. This is Figure 19 shown clearly in

[0236] Based on the same technical concept, Figure 20 exemplarily shows a device 2000 for expanding the user space provided by an embodiment of the present application. As Figure 20 shown, it includes: a determination unit 2001, a modification unit 2002, and an unloading unit 2003. The determination unit 2001 is configured to determine a first dynamic link library and a second dynamic link library when a memory application fails due to exhaustion of the user space; the first dynamic link library refers to a dynamic link library that has a dependency relationship with the caller of the memory application function; the second dynamic link library refers to a dynamic link library that has no dependency relationship with the caller of the memory application function; determine the address range that will be freed in memory if the second dynamic link library is unloaded, and determine the global offset table (GOT) entries to be modified according to the address range; the memory addresses recorded in the GOT entries to be modified fall within the address range, and the GOT entries to be modified are the GOT entries of objects that have a dependency relationship with the second dynamic link library; the modification unit 2002 is configured to modify the memory addresses recorded in the GOT entries to be modified to a set value; the set value is used to indicate the reloading of the second dynamic link library; the unloading unit 2003 is configured to unload the second dynamic link library.

[0237] In a possible implementation method, the determination unit 2001 is configured to determine the direct caller of the memory application function, determine the dynamic link library to which the direct caller of the memory application function belongs as the first dynamic link library, and determine one or more dynamic link libraries that are not the dynamic link libraries to which the direct caller of the memory application function belongs as the second dynamic link library; or, the determination unit 2001 is configured to analyze the call chain of the memory application function, determine the dynamic link libraries in the call chain as the first dynamic link libraries, and determine one or more dynamic link libraries not in the call chain as the second dynamic link libraries; the call chain includes the callers that directly or indirectly call the memory application function.

[0238] In a possible implementation method, a determination unit 2001 is configured to determine all loaded dynamic link libraries; for any dynamic link library among all the loaded dynamic link libraries, if the dynamic link library is a direct caller of the memory application function or is located in the call chain of the memory application function, then exclude the dynamic link library from all the loaded dynamic link libraries; select at least one dynamic link library from all the loaded dynamic link libraries after the exclusion, and determine it as the second dynamic link library.

[0239] In a possible implementation method, a determination unit 2001 is configured to analyze the call chain of the memory application function by means of stack backtracking.

[0240] In a possible implementation method, a determination unit 2001 is configured to determine an object having a dependency relationship with the second dynamic link library; the dependency relationship includes a direct dependency or an indirect dependency; the object includes a dynamic link library and / or the user program itself; scan all GOT tables of the object having a dependency relationship with the second dynamic link library, and determine any entry in any GOT table falling within the address range as a GOT table entry to be modified.

[0241] In a possible implementation method, a modification unit 2002 is configured to, for any GOT table entry to be modified, use the memory address for lazy binding in the procedure link table PLT entry corresponding to the GOT table entry or the memory address of the stub table entry corresponding to the GOT table entry as a set value, and fill it into the GOT table entry.

[0242] In a possible implementation method, an unloading unit 2003 is configured to, before unloading the second dynamic link library, establish a PLT table or a stub table for reloading for the second dynamic link library without a PLT table or a stub table, and create a corresponding PLT table entry or stub table entry for reloading.

[0243] In a possible implementation method, an unloading unit 2003 is configured to unload a section with non-writable permission in the second dynamic link library.

[0244] In a possible implementation method, an unloading unit 2003 is configured to unload a section with executable and non-writable permission in the second dynamic link library.

[0245] In a possible implementation method, an unloading unit 2003 is configured to set the address range vacated in the memory by unloading the executable and non-writable section to be non-executable.

[0246] In a possible implementation method, the above device further includes a reloading unit 2004, and the reloading unit 2004 is configured to reload the second dynamic link library.

[0247] In a possible implementation method, a reloading unit 2004 is configured to attempt to reload all unloaded dynamic link libraries according to the remaining user space; or reload a second dynamic link library currently required to be called by the user program.

[0248] In a possible implementation method, a determination unit 2001 is configured to determine a section header table of the second dynamic link library; according to the section header table, determine an offset, size, and / or permission attribute of a section to be reloaded in the second dynamic link library; a reloading unit 2004 is configured to request the kernel to load the section of the second dynamic link library according to the offset, size, and / or permission attribute of the section to be reloaded in the second dynamic link library.

[0249] In a possible implementation method, a reloading unit 2004 is configured to re - establish a binding relationship with the second dynamic link library for an object that has a dependency relationship with the second dynamic link library.

[0250] In a possible implementation method, the above - mentioned device further includes an execution unit 2005, and the execution unit 2005 is configured to execute any method of the first aspect through a dynamic linker.

[0251] In a possible implementation method, the above - mentioned device further includes a re - binding unit 2006. When an object that has a dependency relationship with the second dynamic link library needs to call any function in the second dynamic link library, the re - binding unit 2006 is configured to re - establish a binding relationship required for this call.

[0252] In a possible implementation method, the re - binding unit 2006 is configured to, after reloading the second dynamic link library, scan all GOT tables of an object that has a dependency relationship with the second dynamic link library, determine a linking target of all GOT table entries; if the linking target belongs to the second dynamic link library, determine the corresponding GOT table entry as a GOT table entry that needs to re - establish a binding relationship; for any GOT table entry that needs to re - establish a binding relationship, fill the memory address of the linking target into the GOT table entry.

[0253] Based on the same technical concept, an embodiment of the present application provides a device 2100 for expanding user space. The device 2100 for expanding user space may be, for example, a computing device. As Figure 21 shown, a device 2100 for expanding user space includes at least one processor 2101 and a memory 2102 connected to the at least one processor. In the embodiment of the present application, the specific connection medium between the processor 2101 and the memory 2102 is not limited. Figure 21Take the example of the connection between the central processing unit 2101 and the memory 2102 through a bus. The bus can be divided into an address bus, a data bus, a control bus, etc.

[0254] In the embodiments of the present application, the memory 2102 stores instructions executable by at least one processor 2101. By executing the instructions stored in the memory 2102, the at least one processor 2101 can execute the above method for expanding the user space.

[0255] Among them, the processor 2101 is the control center of a device 2100 for expanding the user space. It can use various interfaces and lines to connect various parts of the computer device, and perform resource settings by running or executing the instructions stored in the memory 2102 and calling the data stored in the memory 2102. Optionally, the processor 2101 may include one or more determination units. The processor 2101 may integrate an application processor and a modem processor. Among them, the application processor mainly processes the operating system, user interface, application programs, etc., and the modem processor mainly processes wireless communication. It can be understood that the above modem processor may not be integrated into the processor 2101. In some embodiments, the processor 2101 and the memory 2102 may be implemented on the same chip, and in some embodiments, they may also be separately implemented on independent chips.

[0256] The processor 2101 may 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 devices, discrete gate or transistor logic devices, discrete hardware components, and can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the method disclosed in combination with the embodiments of the present application may be directly embodied as being executed by a hardware processor, or executed by a combination of hardware and software modules in the processor.

[0257] The memory 2102, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. The memory 2102 can include at least one type of storage medium. For example, it can include flash memory, hard disks, multimedia cards, card-type memories, 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 memories, magnetic disks, optical discs, and so on. The memory 2102 is any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 2102 in the embodiments of the present application can also be a circuit or any other device capable of implementing a storage function, for storing program instructions and / or data.

[0258] The embodiments of the present application also provide a computer-readable storage medium storing a computer-executable program for causing a computer to execute a method for expanding a user space listed in any of the above manners.

[0259] The embodiments of the present application provide a computer program product including a computer program executable by a computer device. When the program runs on the computer device, it causes the computer device to execute a method for expanding a user space listed in any of the above manners.

[0260] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system, or a computer program product. Therefore, the present application can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memories, CD-ROMs, optical memories, etc.) containing computer-usable program code.

[0261] This application is described with reference to the flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to the application. It should be understood that each flow and / or block in the flowchart and / or block diagram, and the combination of flows 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 the processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing device to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing device produce means for implementing the functions specified in the Figure 1 one or more flows and / or blocks Figure 1 one or more blocks.

[0262] These computer program instructions can 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, such that the instructions stored in the computer-readable memory produce a manufactured article including instruction means that implement the functions specified in the Figure 1 one or more flows and / or blocks Figure 1 one or more blocks.

[0263] These computer program instructions can also be loaded onto a computer or other programmable data processing device, such that a series of operational steps are executed on the computer or other programmable device to generate a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in the Figure 1 one or more flows and / or blocks Figure 1 one or more blocks.

[0264] Obviously, those skilled in the art can 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 equivalent technologies, this application is also intended to include these changes and modifications.

Claims

1. A method for extending user space, characterized in that: include: When the memory application is not completed due to exhaustion of user space, a first dynamic link library and a second dynamic link library are determined; the first dynamic link library refers to a dynamic link library that has a dependency relationship with a caller of the memory application function; the second dynamic link library refers to a dynamic link library that has no dependency relationship with the caller of the memory application function; Determine an address range that will be vacated in the memory if the second dynamic link library is unloaded, and determine a global offset table GOT entry to be modified according to the address range; the memory address recorded in the GOT entry to be modified falls within the address range, and the GOT entry to be modified is a GOT entry of an object having a dependency relationship with the second dynamic link library; Modify the memory address recorded in the GOT table entry to be modified to a set value; the set value is used to indicate the reloading of the second dynamic link library; Unload the second dynamic link library.

2. The method according to claim 1, characterized in that The determining of the first dynamic link library and the second dynamic link library comprises: Determine a direct caller of the memory request function, determine the dynamic link library to which the direct caller of the memory request function belongs as the first dynamic link library, and determine one or more dynamic link libraries that are not the direct callers of the memory request function as the second dynamic link library; or, Analyze the call chain of the memory request function, determine the dynamic link library in the call chain as the first dynamic link library, and determine one or more dynamic link libraries not in the call chain as the second dynamic link library; the call chain includes callers that directly or indirectly call the memory request function.

3. The method according to claim 2, characterized in that The determining as the second dynamic link library comprises: Determine all loaded dynamic link libraries; For any dynamic link library among all the loaded dynamic link libraries, if the dynamic link library is a direct caller of the memory request function or is located in a call chain of the memory request function, then the dynamic link library is excluded from all the loaded dynamic link libraries; At least one dynamic link library is selected from all the loaded dynamic link libraries that have been excluded, and is determined as the second dynamic link library.

4. The method according to claim 2, characterized in that The analyzing the calling chain of the memory application function includes: The calling chain of the memory request function is analyzed by stack backtracing method.

5. The method according to claim 1, characterized in that The step of determining the global offset table GOT entry to be modified according to the address range includes: Determine an object having a dependency relationship with the second dynamic link library; the dependency relationship includes direct dependency or indirect dependency; the object includes the dynamic link library and / or the user program itself; All GOT tables of objects having a dependency relationship with the second dynamic link library are scanned, and any table entry of any GOT table falling within the address range is determined as a GOT table entry to be modified.

6. The method according to claim 1, characterized in that The step of modifying the memory address recorded in the GOT table entry to be modified to a set value includes: For any GOT entry that needs to be modified, the memory address for delayed binding in the procedure linkage table PLT entry corresponding to the GOT entry or the memory address of the stub entry corresponding to the GOT entry is used as a set value and filled into the GOT entry.

7. The method according to claim 6, characterized in that The method further comprises: Before unloading the second dynamic link library, a PLT table or a stub table for reloading is established for the second dynamic link library without a PLT table or a stub table, and a corresponding PLT table entry or a stub table entry for reloading is created.

8. The method according to any one of claims 1 to 7, characterized in that Unload the second dynamic link library, including: Unload the section in the second dynamic link library that has a non-writable permission.

9. The method according to claim 8, characterized in that The step of unloading the section in the second dynamic link library that is not writable includes: Unload the section in the second dynamic link library whose permission is executable but not writable.

10. The method according to claim 9, characterized in that After unloading the section in the second dynamic link library with the permission of being executable but not writable, the method further includes: Set the address range in memory freed by unloading the executable non-writable section to be non-executable.

11. The method according to any one of claims 1 to 7, characterized in that After unloading the second dynamic link library, it also includes: Reload the second dynamic link library.

12. The method according to claim 11, characterized in that The reloading of the second dynamic link library comprises: Depending on the remaining user space, try to reload all unloaded dynamic link libraries; or, Reload the second dynamic link library currently called by the user program.

13. The method according to claim 11, characterized in that The reloading of the second dynamic link library comprises: Determining a section header table of the second dynamic link library; Determine, according to the section header table, the offset, size and / or permission attribute of the section to be reloaded in the second dynamic link library; According to the offset, size and / or permission attribute of the section to be reloaded in the second dynamic link library, the kernel is requested to load the section of the second dynamic link library.

14. The method according to claim 11, characterized in that After reloading the second dynamic link library, the method further includes: For an object having a dependency relationship with the second dynamic link library, a binding relationship with the second dynamic link library is re-established.

15. The method according to any one of claims 1 to 7, characterized in that include: The method is executed by a dynamic linker.

16. A device for expanding user space, characterized in that: include: A determination unit is used to determine a first dynamic link library and a second dynamic link library when a memory application is not completed due to exhaustion of user space; the first dynamic link library refers to a dynamic link library that has a dependency relationship with a caller of a memory application function; the second dynamic link library refers to a dynamic link library that has no dependency relationship with the caller of the memory application function; determine an address range that will be vacated in the memory if the second dynamic link library is unloaded, and determine a global offset table GOT table entry to be modified according to the address range; the memory address recorded in the GOT table entry to be modified falls within the address range, and the GOT table entry to be modified is a GOT table entry of an object that has a dependency relationship with the second dynamic link library; A modification unit, used for modifying the memory address recorded in the GOT table entry to be modified to a set value; the set value is used to indicate the reloading of the second dynamic link library; The unloading unit is used to unload the second dynamic link library.

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

18. A computer-readable storage medium, characterized in that: The method comprises computer-readable instructions, and when a computer reads and executes the computer-readable instructions, the method according to any one of claims 1 to 15 is implemented.

19. A computer program product, characterized in that The invention comprises a computer program executable by a computer device, and when the program is run on the computer device, the computer device is caused to execute the steps of the method according to any one of claims 1 to 15.

Images