A method, apparatus, computing device, and storage medium for expanding user space.

Abstract

This application provides a method, apparatus, computing device, and storage medium for expanding user space, comprising: when memory allocation is not completed due to user space exhaustion, determining a first dynamic link library and a second dynamic link library; the second dynamic link library refers to a dynamic link library that has no dependency relationship with the caller of the memory allocation function; determining the address range in memory that would be freed up if the second dynamic link library is unloaded, and determining the Global Offset Table (GOT) entry to be modified based on 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 that has a dependency relationship with the second dynamic link library; modifying the memory address recorded in the GOT entry to be modified to a set value; the set value is used to indicate the reloading of the second dynamic link library; and unloading the second dynamic link library. This scheme can effectively expand virtual memory.

Description

Technical Field

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

[0002] Virtual memory is generally divided into non-overlapping kernel space and user space. User programs can only access user space. In other words, 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 2GB is user space and 2GB is kernel space. If the 2GB of user space has been completely used up by the user program, then when the user program requests virtual memory from the kernel, the kernel will no longer be able to allocate virtual memory to the user program, eventually causing the program to crash.

[0003] Therefore, 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 user space, which can effectively expand virtual memory.

[0005] In a first aspect, embodiments of this application provide a method for expanding user space. This method can be executed by a device for expanding user space, which 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 executing entity of this method. The method includes: when memory allocation is not completed due to exhaustion of 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 allocation function; the second dynamic link library refers to a dynamic link library that does not have a dependency relationship with the caller of the memory allocation function; determining the address range that would be freed up in memory if the second dynamic link library is unloaded, and determining a Global Offset Table (GOT) entry to be modified based on 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 that has a dependency relationship with the second dynamic link library; modifying the memory address recorded in the GOT entry to be modified to a set value; the set value is used to indicate the reloading of the second dynamic link library; and unloading the second dynamic link library.

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

[0007] In one possible implementation, the direct caller of the memory allocation function is determined, and the dynamic link library to which the direct caller of the memory allocation function belongs is identified as a first dynamic link library, while one or more dynamic link libraries not to which the direct caller of the memory allocation function belongs are identified as second dynamic link libraries; or, the call chain of the memory allocation function is analyzed, and the dynamic link libraries located in the call chain are identified as first dynamic link libraries, while one or more dynamic link libraries not in the call chain are identified as second dynamic link libraries; the call chain includes callers who directly or indirectly call the memory allocation function.

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

[0009] In one possible implementation, all loaded dynamic link libraries are identified; for any dynamic link library among all loaded dynamic link libraries, if the dynamic link library is the direct caller of the memory allocation function, or is located in the call chain of the memory allocation function, then the dynamic link library is excluded from all loaded dynamic link libraries; at least one dynamic link library is selected from all the excluded dynamic link libraries and determined as the second dynamic link library.

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

[0011] One possible implementation involves analyzing the call chain of the memory allocation function using stack backtracking.

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

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

[0014] The above scheme can accurately and effectively identify the GOT entries that need to be modified.

[0015] In one possible implementation, for any GOT entry that needs to be modified, the memory address used for delayed binding in the process link 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.

[0016] The above scheme sets the memory address used for delayed binding in the process link table PLT entry corresponding to the GOT entry or the memory address of the stub entry corresponding to the GOT entry as a set value, so that any GOT entry that needs to be modified can be automatically reloaded when it is used again in the future.

[0017] In one possible implementation, before unloading the second dynamic link library, a PLT table or stub table is created for reloading the second dynamic link library that does not have a PLT table or stub table, and corresponding PLT table entries or stub table entries are created for reloading.

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

[0019] One possible implementation involves unloading sections in the second dynamic link library that are not writable.

[0020] One possible implementation involves unloading the sections in the second dynamic link library that have executable but not writable permissions.

[0021] In one possible implementation, the executable but not writable section is specifically a code section, i.e., a ".text section".

[0022] One possible implementation involves setting the memory address range freed up by unloading executable but not writable sections to be non-executable.

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

[0024] One possible implementation involves reloading the second dynamic link library.

[0025] One possible implementation involves attempting to reload all deloaded dynamic link libraries based on the remaining user space; or reloading the second dynamic link library that the user program currently needs to call.

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

[0027] In one possible implementation, the section header table of the second dynamic link library is determined; based on 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; based on 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 one possible implementation, the section that needs to be reloaded is the section of the second link library that was previously unloaded.

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

[0030] In one possible implementation, for objects that have a dependency relationship with the second dynamic link library, the binding relationship with the second dynamic link library is re-established.

[0031] The above solution re-establishes the binding relationship between the objects that depend on the second dynamic link library and the second dynamic link library, which can ensure the correctness of the program's execution effect.

[0032] In one possible implementation, 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-establishing the binding relationship required to complete the call.

[0033] In one possible implementation, re-establishing the binding relationship with the second dynamic link library includes: after reloading the second dynamic link library, scanning all GOT tables of objects that have a dependency relationship with the second dynamic link library, and determining the link targets of all GOT table entries; if the link target belongs to the second dynamic link library, then determining the corresponding GOT table entry as the GOT table entry that needs to have its binding relationship re-established; for any GOT table entry that needs to have its binding relationship re-established, filling the memory address of the link target into the GOT table entry.

[0034] The above solution can efficiently and with low overhead re-establish the binding relationship between objects that depend on the second dynamic link library and the second dynamic link library, thereby reducing the impact of rebinding on program operation and improving program efficiency.

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

[0036] The above solution can improve its general applicability.

[0037] Secondly, embodiments of this application provide an apparatus for expanding user space, comprising: a determining unit, a modifying unit, and a deloading unit. The determining unit is configured to, when memory allocation is not completed due to exhaustion of user space, determine 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 allocation function; the second dynamic link library refers to a dynamic link library that does not have a dependency relationship with the caller of the memory allocation function; determine the address range that would be freed up in memory if the second dynamic link library is deloaded, and determine the Global Offset Table (GOT) entry to be modified based on 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 that has a dependency relationship with the second dynamic link library; the modifying unit is configured to modify the memory address recorded in the GOT entry to be modified to a set value; the set value is used to indicate the reloading of the second dynamic link library; the deloading unit is configured to deload the second dynamic link library.

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

[0039] In one possible implementation, a determining unit is used to determine all loaded dynamic link libraries; for any dynamic link library among all loaded dynamic link libraries, if the dynamic link library is the direct caller of the memory allocation function, or is located in the call chain of the memory allocation function, then the dynamic link library is excluded from all loaded dynamic link libraries; at least one dynamic link library is selected from all the excluded dynamic link libraries and determined as the second dynamic link library.

[0040] In one possible implementation, a determining unit is used to analyze the call chain of the memory allocation function by stack backtracking.

[0041] In one possible implementation, a determining unit is used to determine objects that have a dependency relationship with the second dynamic link library; the dependency relationship includes direct dependency or indirect dependency; the objects include the dynamic link library and / or the user program itself; scanning all GOT tables of objects that have a dependency relationship with the second dynamic link library, and determining any entry in any GOT table that falls within the address range as a GOT entry that needs to be modified.

[0042] In one possible implementation, the modification unit is used to fill in the memory address used for delayed binding in the process link table (PLT) entry corresponding to the GOT entry or the memory address of the stub entry corresponding to the GOT entry as a set value for any GOT entry that needs to be modified.

[0043] In one possible implementation, the unloading unit is used to create a PLT table or stub table for reloading a second dynamic link library that does not have a PLT table or stub table before unloading the second dynamic link library, and to create corresponding PLT table entries or stub table entries for reloading.

[0044] In one possible implementation, a deloading unit is used to deload sections in the second dynamic link library that have non-writable permissions.

[0045] In one possible implementation, a deloading unit is used to deload sections in the second dynamic link library that have executable but not writable permissions.

[0046] In one possible implementation, an unloading unit is used to set the address range in memory freed up by unloading executable but not writable sections to be non-executable.

[0047] In one possible implementation, the above apparatus further includes a reloading unit for reloading the second dynamic link library.

[0048] In one possible implementation, the reloading unit is used to attempt to reload all deloaded dynamic link libraries based on the remaining user space; or, to reload a second dynamic link library that the user program currently needs to call.

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

[0050] In one possible implementation, a reloading unit is used to re-establish the binding relationship between objects that have a dependency relationship with the second dynamic link library and the second dynamic link library. In another possible implementation, the above apparatus further includes an execution unit, which is used to execute any method of the first aspect through the dynamic linker.

[0051] In one possible implementation, the above-mentioned device further includes a rebinding unit, which is used to re-establish the binding relationship required to complete the call 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.

[0052] In one possible implementation, the rebinding unit is used to scan all GOT tables of objects that have dependencies on the second dynamic link library after the second dynamic link library is reloaded, and determine the link targets of all GOT table entries; if the link target belongs to the second dynamic link library, then the corresponding GOT table entry is determined to be a GOT table entry that needs to re-establish the binding relationship; for any GOT table entry that needs to re-establish the binding relationship, the memory address of the link target is filled into the GOT table entry.

[0053] Thirdly, embodiments of this application also provide a computing device, including:

[0054] Memory, used to store program instructions;

[0055] The processor is configured to invoke program instructions stored in the memory and execute any method for implementing the first aspect described above, according to the obtained program instructions.

[0056] Fourthly, embodiments of this application also provide a computer-readable storage medium storing computer-readable instructions, which, when read and executed by a computer, implement any of the methods described in the first aspect.

[0057] Fifthly, embodiments of this application provide a computer program product, including a computer program executable by a computer device, which, when run on the computer device, causes the computer device to perform any of the methods described in the first aspect. Attached Figure Description

[0058] Figure 1 A flowchart illustrating a method for expanding user space provided in an embodiment of this application;

[0059] Figure 2 A flowchart illustrating a method for determining a second dynamic link library provided in an embodiment of this application;

[0060] Figure 3A and Figure 3B A flowchart illustrating a method for determining a second dynamic link library provided in an embodiment of this application;

[0061] Figure 4A and Figure 4B A flowchart illustrating a method for determining a second dynamic link library provided in an embodiment of this application;

[0062] Figure 5 A flowchart illustrating a method for determining GOT entries that need to be modified, provided as an embodiment of this application;

[0063] Figure 6 A schematic diagram of a dependency relationship provided in an embodiment of this application;

[0064] Figure 7A and Figure 7B A flowchart illustrating a method for determining a set of potential reverse dependencies, provided as an embodiment of this application;

[0065] Figure 8A and Figure 8B A flowchart illustrating a method for determining a set of potential reverse dependencies, provided as an embodiment of this application;

[0066] Figure 9A and Figure 9B A flowchart illustrating a method for determining GOT entries that need to be modified, provided as an embodiment of this application;

[0067] Figure 10A and Figure 10B A flowchart illustrating a method for modifying a GOT entry as provided in an embodiment of this application;

[0068] Figure 11 A flowchart illustrating a method for removing a loading target provided in an embodiment of this application;

[0069] Figure 12 A flowchart illustrating a method for reloading a second dynamic link library, provided as an embodiment of this application;

[0070] Figure 13 A flowchart illustrating a method for reloading a second dynamic link library, provided as an embodiment of this application;

[0071] Figure 14 A flowchart illustrating a method for unloading a second dynamic link library, provided as an embodiment of this application;

[0072] Figure 15 A flowchart illustrating a method for unloading a second dynamic link library, provided as an embodiment of this application;

[0073] Figure 16A flowchart illustrating a method for modifying a memory allocation function provided in an embodiment of this application;

[0074] Figure 17 This application provides a schematic diagram of a program dependency structure.

[0075] Figure 18 A schematic diagram of the structure of a PLT table and a GOT table provided in an embodiment of this application;

[0076] Figure 19 A schematic diagram of the structure of a stub table and a GOT table provided in an embodiment of this application;

[0077] Figure 20 A schematic diagram of the structure of an apparatus for expanding user space provided in an embodiment of this application;

[0078] Figure 21 This is a schematic diagram of a device for expanding user space provided in an embodiment of this application. Detailed Implementation

[0079] The basic terminology used in the embodiments of this application will be briefly introduced below.

[0080] Kernel Space / User Space: Virtual memory is divided into two segments: kernel space and user space. Since both the kernel and user programs require memory to run, they each need to occupy a certain amount of virtual memory space. Therefore, it can be said that the kernel runs in kernel space, and user programs run in user space. Due to its privileges, the kernel can access user space; however, due to the lack of privileges, accessing kernel space from user space will result in an exception. The size of these two spaces in virtual memory is usually architecture-specific. For example, in 32-bit MIPS architecture, the kernel space and user space are each allocated 4 GiB of 32-bit virtual memory, with each allocated 2 GiB (high) and 2 GiB (low). For x86, kernel space occupies 1 GiB (high) and user space occupies 3 GiB (low).

[0081] Dynamic linking or static linking: used to link object files and their dependent function libraries together to form an executable file or function library.

[0082] When performing dynamic linking, the linker only writes some characteristic information of the dynamic link library into the executable file or function library, without writing the dynamic link library itself into the latter. This characteristic information is used to guide the dynamic linker. Therefore, the actual linking work (loading and binding) is left to the dynamic linker to perform at runtime.

[0083] When the linker completes static linking, it first merges the various object files and static libraries into a single binary file (similar to loading in dynamic linking). Then, based on the offset positions of the merged object files and static libraries, it corrects the address references in the machine code (similar to binding in dynamic linking).

[0084] 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 size as an example, which has several source code files, the following situations are possible, including but not limited to:

[0085] 1. The object files compiled from these source code files are often statically linked together to form a single executable file (single artifact) or a function library (single artifact). These object files become part of the single artifact.

[0086] 2. In rare cases, some object files may be statically linked into a function library (dynamic link library, product 1), and the remaining object files may be statically linked into an executable program (product 2), which is then dynamically linked back to the former (product 1).

[0087] 3. Such software, in addition to its own source code, may also depend on some external function libraries. Depending on the linking options passed to the linker, some function libraries may be statically linked, becoming part of one or more of the aforementioned products (which could be a single product of case 1, or product 1 and / or product 2 of case 2); another part may be dynamically linked to one or more of the aforementioned products (as before). Depending on the linking options passed to the linker, all external function libraries may also be statically linked or dynamically linked.

[0088] The PLT table, also known as the Procedure Linkage Table, extracts the lengthy indirect jumps based on the GOT table. This allows the main instruction flow to simply jump to PLT entries, and it also functions as a stub during the first call in lazy binding scenarios. The PLT table is executable but not writable during program execution to prevent accidental overwriting that could lead to errors or security vulnerabilities. The instructions (clusters) in the PLT table used for second-level jumps are optional (they can be embedded into the main instruction flow), and the stubs within them are also optional in immediate binding.

[0089] The GOT table, also known as the Global Offset Table, is the heart of dynamic linking. The dynamic linker uses it to fill in various addresses that are determined at runtime, especially the addresses of bound symbols, which are absolute addresses (hence the name "global offset"). At program startup, the GOT table is readable and writable but not executable. For lazy binding, because the program can modify the GOT table at any time during runtime, it will remain readable and writable but not executable. For immediate binding, preferably, it should be set to readable but not writable or executable after binding is complete (i.e., immediately after program startup and the dynamic linker has completed its initial work). This prevents accidental overwriting of the GOT table, which could lead to program execution errors or even security vulnerabilities.

[0090] The initial value of the GOT entry is crucial for delayed binding. Since the addresses stored in the GOT table are absolute addresses, for dynamic link libraries (DLLs) that have GOT tables (or certain programs that allow execution at arbitrary addresses, i.e., position-independent executables (PIEs), often used to implement address space layout randomization (ASLR)), the address they are loaded at runtime cannot be determined at compile time (including the linking stage). Therefore, the initial value of the GOT entry will be a relative address. After the DLL is loaded (or after the aforementioned special programs start), the dynamic linker will correct this initial value to an absolute address (simply by adding the starting address of the DLL / program to the entry). It's important to note that this correction does not imply symbol binding. This correction is only one part of the preparatory work for delayed binding.

[0091] Dynamic linker: The dynamic linker (or loader) is responsible for performing dynamic linking during program execution. On GNU / Linux, this is ld.so. A particularly popular implementation is ld.so, implemented by the GNU LIBC (GLIBC) project, which is also used as an example in this application.

[0092] Figure 1 This is a flowchart illustrating a method for expanding user space according to an embodiment of this application. This method can be executed by a device for expanding user space, which 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 entity executing this method.

[0093] The method includes the following steps:

[0094] Step 101: When memory allocation is not completed due to exhaustion of user space, determine the first dynamic link library and the second dynamic link library.

[0095] The first dynamic link library refers to a dynamic link library that has a dependency relationship with the caller of the memory allocation function; the second dynamic link library refers to a dynamic link library that does not have a dependency relationship with the caller of the memory allocation function.

[0096] Step 102: Determine the address range that will be freed up in memory if the second dynamic link library is unloaded, and determine the Global Offset Table (GOT) entries that need to be modified based on the address range.

[0097] Wherein, 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.

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

[0099] The setting value is used to instruct the reloading of the second dynamic link library. This application does not limit the specific method of obtaining the setting value, nor does it limit the specific value of the setting value.

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

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

[0102] In one possible implementation, in step 101 above, a dynamic link library can be unloaded at any time as long as it is not currently in use. This application does not limit the timing of unloading dynamic link libraries.

[0103] However, a more efficient approach would be to unload only when user space is exhausted and memory allocation cannot be completed. In other words, when processing memory allocation, if the allocation fails, user space may be exhausted, at which point unloading can be triggered. Furthermore, unloading can be triggered implicitly or explicitly: if implicitly, it can be triggered by the memory allocation function when memory allocation fails; if explicit, it can be triggered by the caller of the memory allocation function after receiving a memory allocation failure indication (including errors) returned by the memory allocation function.

[0104] The embodiments in this application are all described according to the implicit unloading trigger. The explicit case is similar and will not be described again here.

[0105] In one possible implementation, step 101 above, determining the first dynamic link library and the second dynamic link library, includes: determining the direct caller of the memory allocation function, identifying the dynamic link library to which the direct caller of the memory allocation function belongs as the first dynamic link library, and identifying 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, identifying the dynamic link library located in the call chain as the first dynamic link library, and identifying one or more dynamic link libraries not in the call chain as the second dynamic link library; the call chain includes callers who directly or indirectly call the memory allocation function.

[0106] One possible implementation method is to determine the method as the second dynamic link library, such as... Figure 2 As shown, it includes the following steps:

[0107] Step 201: Identify all loaded dynamic link libraries.

[0108] Step 202: For any dynamic link library among all the loaded dynamic link libraries, if the dynamic link library is the direct caller of the memory allocation function, or is located in the call chain of the memory allocation function, then the dynamic link library is excluded from all the loaded dynamic link libraries.

[0109] Step 203: Select at least one dynamic link library from all the excluded dynamic link libraries and determine it as the second dynamic link library.

[0110] The two scenarios in step 202 will be analyzed below.

[0111] In the first scenario, the dynamic link library is the direct caller of the memory allocation function.

[0112] We know that when unloading dynamic link libraries to free up user space, we can only select those dynamic link libraries that are not currently in use.

[0113] A function call is essentially a process where one function (caller) jumps to another function (callee), the callee completes its execution, and then the caller jumps back to the caller, allowing the caller to continue execution. Before making a function call, the caller must store the return address (usually pointing to the instruction after the function call or n instructions after it, and this address must belong to the caller) somewhere in memory (usually somewhere on the stack) or in a register (it may eventually be backed up to the stack). Only in this way can the callee, after completing its execution, read this address and jump back to the caller, allowing the caller to continue execution. Therefore, by reading the return address, the callee can determine its caller at any time. And given an address, the dynamic linker can determine the dynamic link library from which it comes.

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

[0115] Based on this, this application proposes an embodiment that, in addition to the first case of loading dynamic link libraries, when user space is exhausted and memory allocation cannot be completed, identifies the direct caller of the memory allocation function and unloads one or more dynamic link libraries that are not direct callers of the memory allocation function. It is not necessary to unload all dynamic link libraries that are not direct callers of the memory allocation function; only one or more can be selected. This is because memory allocation often does not require a large memory area, so it is possible to first try unloading a smaller number of dynamic link libraries to see if this is sufficient for successful memory allocation. If, after excluding the direct caller of the memory allocation function, there are no more dynamic link libraries that can be unloaded, an indication of unloading failure is returned. Furthermore, the caller of the memory allocation function can interpret this indication as a memory allocation failure (a memory allocation error occurred).

[0116] One possible implementation involves unloading one or more dynamic link libraries that are not direct callers of the memory allocation function, such as... Figure 3A and Figure 3B As shown, the method includes the following steps:

[0117] Step 301: When deloading is triggered, identify all loaded dynamic link libraries (excluding dynamic linkers).

[0118] In theory, the dynamic linker should not be unloaded.

[0119] Step 302: Determine the caller of the memory allocation function.

[0120] Step 303: Determine the dynamic link library mentioned by the caller.

[0121] Step 304: Remove the dynamic link library mentioned by the caller from the set of unloadable dynamic link libraries.

[0122] Step 305: Determine whether the collection of unloadable dynamic link libraries is empty.

[0123] Optionally, if the set of unloadable dynamic link libraries is empty, an indication of unloading failure is returned; if it is not empty, one or more dynamic link libraries are selected from the set of unloadable dynamic link libraries to generate a set of dynamic link libraries to be unloaded, wherein the set of dynamic link libraries to be unloaded is the second dynamic link library, and all loaded dynamic link libraries minus the second dynamic link library are the first dynamic link library.

[0124] In the second scenario, the dynamic link library is located in the call chain of the memory allocation function.

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

[0126] This call chain means:

[0127] 1. The program executed a function within the program itself;

[0128] 2. A function from the program itself called a function from dynamic link library A as needed;

[0129] 3. A function from dynamic link library A called a function from dynamic link library B as needed;

[0130] 4. A function from dynamic link library B called a function from dynamic link library C as needed;

[0131] 5. The function mentioned above, which comes from the dynamic link library C, calls a memory allocation function to request a block of memory as needed.

[0132] Once the memory allocation function has finished executing, then:

[0133] 1. After the memory allocation function returns, a function from the C dynamic link library mentioned above continues to complete the remaining work (if any);

[0134] 2. The function from dynamic link library C returns, and the function from dynamic link library B continues to complete the remaining work (if any);

[0135] 3. If a function from dynamic link library B returns, a function from dynamic link library A continues to complete the remaining work (if any).

[0136] 4. The function from dynamic link library A returns, and the function from the program itself continues to complete the remaining work (if any).

[0137] 5. The program continues to execute.

[0138] When the memory allocation function returns, it will return to a function in the aforementioned dynamic link library C; and so on, successively returning to a function in the aforementioned dynamic link library B, a function in the aforementioned dynamic link library A, and finally returning to a function in the aforementioned program itself.

[0139] As can be seen from the above process, dynamic link library C is the direct caller of the memory allocation function. If only the direct caller of the memory allocation function (i.e., dynamic link library C in this example) is excluded from the list of candidate dynamic link libraries that can be unloaded, then dynamic link libraries A and B are still in the candidate list. Imagine that if dynamic link library B is unloaded, although the memory allocation function returns to the aforementioned "function in dynamic link library C" after execution, and the program can continue to run normally at this time because dynamic link library C has not been unloaded; however, once the aforementioned "function in dynamic link library C" finishes execution and returns to the aforementioned "function in dynamic link library B", because dynamic link library B has been unloaded, the corresponding memory area has been allocated to other memory allocations, and the returned location is no longer "the function in dynamic link library B", thus leading to memory misuse. Similarly, if dynamic link library A is unloaded, once the execution of the aforementioned "function in dynamic link library B" is completed and the return is made to the aforementioned "function in dynamic link library A", the corresponding memory area has already been allocated to other memory allocations. Therefore, the place returned to is no longer the "function in dynamic link library A", which also leads to memory misuse.

[0140] Based on this, this application proposes a second scenario for unloading dynamic link libraries: when user space is exhausted and memory allocation cannot be completed, the call chain of the memory allocation function is analyzed, and one or more dynamic link libraries not in the call chain are unloaded. That is, when determining the candidate list of dynamic link libraries that can be unloaded, not only the direct caller of the memory allocation function (such as "a function in dynamic link library C" in the example above) must be identified, but also all indirect callers (such as "a function in dynamic link library A" and "a function in dynamic link library B" in the example above) must be identified in a chain-like manner. The dynamic link libraries corresponding to these direct and indirect callers are then excluded from the candidate list (corresponding to the example above, this means excluding dynamic link libraries A, B, and C). In other words, all dynamic link libraries in the call chain are excluded.

[0141] One possible implementation involves unloading one or more dynamic link libraries that are not in the call chain, such as... Figure 4A and Figure 4B As shown, the method includes the following steps:

[0142] Step 401: When unloading is triggered, determine the initial members of the set of dynamic link libraries that can be unloaded.

[0143] One possible implementation involves identifying all loaded dynamic link libraries (excluding dynamic linkers) as the initial members of the set of dynamic link libraries that can be unloaded.

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

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

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

[0147] If the function to be analyzed does not have a caller, proceed to step 406; if the function to be analyzed has a caller, proceed to step 404.

[0148] Step 404: Determine the caller's dynamic link library and remove the caller's dynamic link library from the set of unloadable dynamic link libraries.

[0149] Step 405: The caller is selected as the function to be analyzed.

[0150] In one possible implementation, the caller is treated as the function to be analyzed, and step 403 is re-executed.

[0151] This application does not limit the execution order of steps 404 and 405, and steps 404 and 405 can be executed simultaneously.

[0152] Step 406: Determine whether the set of unloadable dynamic link libraries is empty.

[0153] Optionally, if the set of unloadable dynamic link libraries is empty, an indication of unloading failure is returned; if it is not empty, one or more dynamic link libraries are selected from the set of unloadable dynamic link libraries to generate a set of dynamic link libraries to be unloaded, wherein the set of dynamic link libraries to be unloaded is the second set of dynamic link libraries.

[0154] One possible implementation involves analyzing the call chain of the memory allocation function using stack backtracking. This application does not limit the method used to analyze the call chain of the memory allocation function.

[0155] Stack backtracking involves reconstructing the current and all previous stack frames based on the program's state at a given moment. Each stack frame corresponds to a function in the call chain, and specifically, a return address is stored at a particular location within the stack frame. Since the return address can be used to determine the caller, the program's call chain at that particular moment can be determined.

[0156] In one possible implementation, the frame pointer register (also called the stack frame pointer register, framepointer, FP, BP, EBP, RBP) is used in conjunction with the previously backed-up frame pointers in the stack to trace back sequentially. The frame pointers determine the starting address of the current stack frame.

[0157] Specifically, the end address of the current stack frame can be determined through the stack pointer register. Then, the frame pointer of the backed-up previous stack frame can be obtained at a specific position in the current stack frame, and the start address of the previous stack frame can be determined. Then, the start address of the stack frame before that can be obtained in the same way in the previous stack frame, and so on.

[0158] In another possible implementation, the stack pointer registers (SP, ESP, RSP) are used in conjunction with the frame mapping table (e.g., .eh_frame) in the program (executable file) or dynamic link library's debugging information (e.g., DWARF) to sequentially backtrack. The stack pointer can be used to determine the end address of the current stack frame.

[0159] Specifically, the value in the stack pointer register is always reliable; it always points to the end address of the current stack frame. However, the stack pointer register alone is insufficient to trace back to the previous stack frame, as we do not know the start address of the current stack frame (and therefore cannot calculate the end address of the previous stack frame). We still need to determine the start position of the current stack frame, or the size of the current stack frame, or the end position of the previous stack frame (knowing any one of these three allows us to calculate the other two by combining them with the stack pointer) in order to locate the previous stack frame. For the previous stack frame, we also need to know any one of the aforementioned three attributes to locate the stack frame before that, and so on.

[0160] Alternatively, this information can be provided in the frame mapping table (e.g., .eh_frame) in debugging information (such as DWARF).

[0161] In one embodiment, the GOT table is rewritten so that subsequent use of the unloaded dynamic link library can trigger a reload. After reloading, the corresponding symbols in these rewritten GOT entries must be bound, i.e., rebinded. In other words, reloading and rebinding are dynamically triggered by subsequent use of the unloaded dynamic link library, and we need to perform some preparatory work to make such dynamic triggering possible.

[0162] In one possible implementation, step 102 above, the method for determining the GOT entry to be modified based on the address range, is as follows: Figure 5 As shown, the method includes the following steps:

[0163] Step 501: Identify objects that have dependencies on the second dynamic link library.

[0164] The dependencies include direct or indirect dependencies; the objects include dynamic link libraries and / or the user program itself.

[0165] Step 502: Scan all GOT tables of objects that have dependencies on the second dynamic link library, and determine any entry in any GOT table that falls within the address range as the GOT entry that needs to be modified.

[0166] The following explains the objects that have dependencies on the second dynamic link library.

[0167] Figure 6The example illustrates the dependencies between the program itself and dynamic link libraries A, B, C, and D. 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; and dynamic link library C depends on dynamic link library D. If described as reverse dependencies, the following direct reverse dependencies can be determined: dynamic link library A is depended upon by the program itself; dynamic link library B is depended upon by dynamic link library A; dynamic link library C is depended upon by both dynamic link libraries A and B; and dynamic link library D is depended upon by both dynamic link library C and the program itself. The definition of reverse dependency is that X is a dependency of Y, meaning that if X depends on Y, then Y is a dependency of X. Therefore, we have: Y is a positive dependency of X, and X is a reverse dependency of Y.

[0168] One possible implementation involves determining the method for objects that have a direct dependency on the second dynamic link library, such as... Figure 7A and Figure 7B As shown, the method includes the following steps:

[0169] Step 701: Select any dynamic link library from the unloaded dynamic link set.

[0170] Among them, unloading the dynamic link collection is the second dynamic link library.

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

[0172] The potential reverse dependency set contains objects that have dependencies on the second dynamic link library.

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

[0174] Analyze the dependencies of the current program and all dynamic link libraries (DLLs), identify all DLLs that directly depend on the unloaded DLL, and add them to the potential reverse dependency set. If the program also directly depends on the unloaded DLL, add the program to the potential reverse dependency set as well. This is because the GOT table of a DLL (or the program itself) that directly depends on the unloaded DLL will have entries bound to the unloaded DLL. The unloaded DLL itself should also be added to the potential reverse dependency set, as the DLL itself will have some GOT entries bound to its own symbols; in other words, the DLL is also an implicit potential reverse dependency of itself.

[0175] This set is called the potential reverse dependency set because the effect of unloading a second dynamic link library depends on the section chosen during unloading: if only writable data reverse dependencies exist, these dependencies will not be broken as long as the unloaded sections do not contain writable sections; if only data (writable or read-only) reverse dependencies exist, these dependencies will not be broken as long as the unloaded sections are limited to executable but not writable sections (especially .text sections, i.e., code sections). Nevertheless, even if a potential reverse dependency is one that will not be broken by unloading, adding it to the potential reverse dependency set will not cause any harm.

[0176] based on Figure 6 For 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 and D, and the program itself will be added to the potential reverse dependency set.

[0177] In one possible implementation, direct reverse dependencies are determined recursively, which in turn identifies all indirect reverse dependencies. Methods for identifying objects with indirect reverse dependencies on the second dynamic link library include, for example... Figure 8A and Figure 8B As shown, the method includes the following steps:

[0178] Step 801: Select any dynamic link library from the unloaded dynamic link set.

[0179] Step 802: Add the current program and all dynamic link libraries that are recursively dependent on by the dynamic link library to the potential reverse dependency set until the dynamic link set is unloaded and empty.

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

[0181] In one possible implementation, step 502 above, which involves scanning all GOT tables of objects that have dependencies on the second dynamic link library, and identifying any entry in any GOT table falling within the address range as a GOT entry that needs to be modified, is as follows: Figure 9A and Figure 9B As shown, the method includes the following steps:

[0182] Step 901: Select any dynamic link library (or the program itself) from the set of potential reverse dependencies.

[0183] Step 902: Scan all GOT tables of the dynamic link library (or the program itself).

[0184] Step 903: Based on the set of address ranges freed up due to unloading, add all entries whose values ​​fall into the address range set to the affected GOT entry set.

[0185] Step 904: Repeat steps 901 to 903 until the set of potential reverse dependencies is empty.

[0186] Each dynamic link library and / or current program in the potential reverse dependency set will have at least one GOT table, which is called the "affected GOT table". Analyze the entries in the GOT tables of these dynamic link libraries and / or current programs, and if the value of an entry falls within the address range where the unloaded section was originally located, add it to the "affected GOT entry" set.

[0187] In one possible implementation, for any GOT entry that needs modification, the memory address used for delayed binding in the Process Link 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 setting value and filled into the GOT entry. This application does not limit the specific content of the setting value.

[0188] In one possible implementation, the value is set to the initial value under delayed binding. This application does not limit how the initial value is restored. For example, the initial value can be calculated, or it can be obtained 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.

[0189] In one possible implementation, the set value is a fixed identifier used to indicate the initial value for obtaining the delayed binding case. That is, when the program obtains this set value, it triggers the execution of an instruction to obtain the initial value for the delayed binding case based on this set value.

[0190] Since the dynamic link library may not be loaded at the same address when it is reloaded later, the old value of the affected GOT entry may become an incorrect value at that time, requiring rebinding. Therefore, we should prepare these GOT entries now to trigger rebinding in the future. Modify the values ​​of the affected GOT entries to restore them to their initial values ​​under the case of delayed binding. That is, for cases using the PLT table, point to the trampoline used for delayed binding in the corresponding PLT entry; for cases 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 used for delayed 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; this is not a conflict.

[0191] One possibility is that the implementation method modifies the GOT entry as follows: Figure 10A As shown, the method includes the following steps:

[0192] Step 1001: Select any GOT entry from the set of affected GOT entries.

[0193] Step 1002: Restore the value of the GOT entry to the initial value of the delayed binding.

[0194] In one possible implementation, it is determined whether the dynamic link library corresponding to the GOT entry uses the PLT table. If it does, the PLT entry corresponding to the GOT entry is determined, and the trampoline address used for delayed binding in the PLT entry is determined. The value of the GOT entry is then modified according to the trampoline address. If it does not use the PLT table, the address of the stub entry corresponding to the GOT entry is determined, and the value of the GOT entry is modified according to the address of the stub entry.

[0195] One possible implementation involves creating a PLT table or stub table for reloading the second dynamic link library before unloading it, and then creating corresponding PLT table entries or stub table entries for reloading. This will be explained in detail later.

[0196] Step 1003: Repeat steps 1001 to 1002 until the set of affected GOT entries is empty.

[0197] The specific implementation of the above steps is as follows: Figure 10B As shown, it will not be elaborated further here.

[0198] In one possible implementation, when a function in an unloaded dynamic link library is used, since the value in the corresponding GOT entry has been rewritten to the initial value under the case of lazy binding, the call to the function ("target function") in the unloaded dynamic link library will eventually lead to the call of the dynamic link library runtime resolution function (_dl_runtime_resolve).

[0199] One possible implementation involves modifying the behavior of the runtime resolution function of the dynamic link library so that it can load the corresponding dynamic link library before it is loaded, and then perform the binding. In this case, the dynamic linker can reload the dynamic link library and rebind the target function, allowing the actual target function to be called normally.

[0200] In one embodiment, the second dynamic link library is not completely unloaded, but only some components of the second dynamic link library, namely certain sections, are unloaded.

[0201] One possible implementation involves unloading sections in the second dynamic link library that are not writable.

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

[0203] One possible implementation involves unloading the sections in the second dynamic link library that have executable but not writable permissions.

[0204] If a section containing read-only data is unloaded, it cannot be reloaded the next time it is used. Executable sections, on the other hand, contain various functions. After being unloaded, proper modifications to the GOT table (e.g., restoring to the initial state of lazy binding) can redirect subsequent calls to these functions to the dynamic linker, triggering a reload. Limiting execution to executable-only sections has an additional benefit: to jump to a specific address for execution, that address must have executable properties; otherwise, it's a memory misuse. For unloaded executable-only sections, the kernel can be requested to set the corresponding region as non-executable after unloading. Thus, when this region is subsequently used for memory allocation, since memory allocation is generally for data, the region will not be reset to executable, preventing accidental jumps to this region and execution of data as instructions. This helps in early detection of errors in the program.

[0205] One possible implementation involves setting the memory address range freed up by unloading executable but not writable sections to be non-executable.

[0206] In one possible implementation, the .text section (code segment) in the second dynamic link library is unloaded; and after unloading, the kernel is requested to set the memory area where the .text section was originally located to be non-executable.

[0207] Some programs may have custom executable non-writable sections, and unloading them can carry unforeseen risks. Therefore, we might want to unload only the well-known executable non-writable sections. The most representative executable non-writable section is the .text section (also called a code segment, code block, or .text segment), which is usually the largest section in a dynamic link library. Unloading it offers the greatest benefits and relatively predictable risks.

[0208] One possible implementation involves unloading the contents of some components of the second dynamic link library, such as... Figure 11 As shown, it will not be elaborated further here.

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

[0210] One possible implementation involves attempting to reload all unloaded dynamic link libraries based on the remaining user space. If there is sufficient remaining user space, all unloaded dynamic link libraries can be reloaded; if there is insufficient remaining user space to reload all unloaded dynamic link libraries, then based on the remaining user space and the amount of memory required for the unloaded dynamic link libraries, a portion of the unloaded dynamic link libraries can be reloaded.

[0211] Another possible implementation involves reloading the second dynamic link library that the user program currently needs to call. That is, when the user program needs to use a function from the unloaded dynamic link library, the unloaded second dynamic link library is reloaded.

[0212] In one possible implementation, the method for reloading the second dynamic link library is as follows: Figure 12 As shown, it includes the following steps:

[0213] Step 1201: Determine the header table of the second dynamic link library.

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

[0215] Step 1203: Based on 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.

[0216] Alternatively, the data in the section can be copied directly into memory, or the kernel can be requested to establish a named memory mapping to load the section that needs to be reloaded.

[0217] In one possible implementation, after reloading the second dynamic link library, the method further includes: re-establishing the binding relationship between objects that have a dependency relationship with the second dynamic link library and the second dynamic link library.

[0218] After a reload, all affected GOT entries related to these sections can be rebound immediately (analogous to immediate binding), or only the GOT entry that triggered the reload can be rebound (analogous to delayed binding). In the latter case, the remaining unreloaded affected GOT 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.

[0219] In one possible implementation, the setting value of the GOT entry triggers rebinding, and after rebinding, conditionally triggers reloading.

[0220] In one possible implementation, the method for reloading the second dynamic link library is as follows: Figure 13 As shown, this method is executed by the runtime resolution function of the dynamic link library, and the method includes the following steps:

[0221] Step 1301: Determine the GOT entry that triggers delayed binding (rebinding) and the symbol to be bound.

[0222] Step 1302: Determine that the symbol is located on a section that has already been loaded.

[0223] In one possible implementation, if the symbol is on a loaded section, then step 1304 is executed; otherwise, step 1303 is executed.

[0224] Step 1303: Determine the various attributes of the section based on the information in the second dynamic link library section header table, and load the section using the aforementioned attributes.

[0225] In one possible implementation, the specific behavior of step 1303 is as follows: Figure 12 And as shown in steps 1201~1023.

[0226] Step 1304: Bind the symbol.

[0227] In one possible implementation, all affected GOT entries related to the symbol are bound.

[0228] In another possible implementation, all affected GOT entries related to the second dynamic link library are bound.

[0229] In another possible implementation, only the symbol corresponding to the GOT entry that triggers delayed binding (rebinding) is bound. Other symbols can be left unbound temporarily, and bound later when the delayed binding (rebinding) corresponding to that symbol is triggered again (equivalent to the other symbols subsequently triggering delayed binding (rebinding) and then executing the same procedure again for those other symbols). Figure 13 (and the process shown in steps 1301-1305).

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

[0231] Any dynamic link library (and in fact, programs and executables, which are collectively called relocatable files (ELF)) can be divided into many sections. The purpose of each section is different; some sections are used to store read-only data, while others are used to store the initial values ​​of readable and writable data. Generally speaking, the largest section is the code section (also called the code segment), which stores the machine code that can be executed by the CPU.

[0232] Metadata exists to describe each section, and this metadata is usually stored in the form of section headers. A collection of section headers is called a section header table. The section header describes the attributes of the section, the most important of which are:

[0233] 1. The permission attributes of this section. That is, whether it is writable and whether it is executable; these correspond to the flags W and X in the section header, respectively.

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

[0235] Both the kernel and the dynamic linker rely on this attribute information to correctly perform the loading process when loading executable files (programs).

[0236] 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 type of dynamic link library, since it is often loaded by the kernel, we will not discuss how it is loaded here; we focus on how the dynamic linker loads other dynamic link libraries, especially how it loads a dynamic link library into memory once it finds one to be loaded.

[0237] 1. Open the dynamic link library and find the section header table.

[0238] 2. The location, size, and permission attributes of each section in the dynamic link library within the file can be determined from the section headers in the section header table.

[0239] 3. For each section, its position in the file, section size, permission attributes, and the file descriptor of the opened dynamic link library are passed to the kernel as parameters for the system call, requesting the kernel to establish a named memory mapping (file mapping).

[0240] This application provides another embodiment that can be used in the case of immediate binding.

[0241] A crucial step in lazy binding is determining which GOT entry in which dynamic link library (or the current program) triggered the lazy binding. Without this information, it's impossible to determine which symbol to bind or which GOT entry to modify to complete the binding. The instruction (family) in the trampoline used for lazy loading within the PLT (or stub) entry (excluding entry 0) corresponding to the GOT entry resolves the "which GOT entry" problem. Furthermore, since entry 0 of the PLT (or stub) contains the instruction (family) to load the link_map address into a specified register or push it onto the stack, the problem of "determining which dynamic link library (or the current program)" is thus solved.

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

[0243] In one possible implementation, before unloading the second dynamic link library, a PLT table or stub table is created for reloading the second dynamic link library that does not have a PLT table or stub table, and corresponding PLT table entries or stub table entries are created for reloading.

[0244] Specifically, for each affected GOT entry, if it omits any of the aforementioned elements used for delayed binding (e.g., the corresponding PLT entry lacks a trampoline for delayed binding; or the corresponding PLT table lacks entry 0; or both the corresponding PLT table and stub table are missing), a "stub table for reloading and rebinding" is created for the dynamic link library from which it originates (note, not to which it is bound) or for the current program. If such a stub table has already been created for this dynamic link library and / or the current program, that stub table can be reused. If a dynamic link library or the current program uses delayed binding for some symbols and does not use a PLT table, then it will have a stub table for delayed binding.

[0245] Alternatively, the newly created stub table here is specifically designed for the reloading and rebinding of symbols that must be immediately bound due to the omission of the aforementioned elements for delayed binding, and is different from the original stub table for delayed binding.

[0246] One possible implementation involves creating a corresponding stub entry in the corresponding stub table for each affected GOT entry, and then modifying the value of the affected GOT entry to the address of the corresponding stub entry. If a corresponding stub table has already been created and a corresponding stub entry already exists for a certain GOT entry, it is not necessary to create the stub entry again; the value of the affected GOT entry can be directly modified to the address of the corresponding stub entry.

[0247] In one possible implementation, when a function in the unloaded dynamic link library is used, since the value in the corresponding GOT entry has been rewritten to the address of the corresponding entry in the newly created stub table, the call to the function ("target function") in the unloaded dynamic link library will eventually lead to the call of the dynamic link library runtime resolution function (_dl_runtime_resolve).

[0248] In one possible implementation, delayed binding and immediate binding can coexist. Even for the same dynamic link library, some symbols can use delayed binding while others use immediate binding.

[0249] In one possible implementation, the structure of each newly created stub table is as follows: the contents of the 0th item are "instructions (family) that load the identifier of the corresponding dynamic link library (or the current program) into a specified register or push it onto the stack" and "instructions (family) that jump to the runtime resolution function of the dynamic link library".

[0250] The "identifier of the corresponding dynamic link library (or current program)" is used to determine which dynamic link library (or current program) triggered the rebinding or reloading. For example, it can be the link_map address of the corresponding dynamic link library (or current program). It should be noted that if the link_map address is loaded, it can be loaded from entry 0 of the GOT table used for lazy binding in that dynamic link library (or current program), or from elsewhere in memory, or even using an immediate value; this application does not limit this. If another identifier is loaded, it can be loaded from somewhere in memory, or even using an immediate value; this application does not limit this.

[0251] The "instruction (cluster) for jumping to the runtime resolution function of the dynamic link library" can be: first loading the address of the runtime resolution function of the dynamic link library from an entry (such as entry 2) in the GOT table used for lazy binding, and then jumping there (which is equivalent to the "instruction (cluster) for jumping to the address pointed to by GOT entry 2" mentioned above, where this GOT refers to the GOT used for lazy binding); or loading the address of the runtime resolution function of the dynamic link library from elsewhere in memory and then jumping there; or it can be a jump instruction (cluster) using immediate values, which is not limited in this application.

[0252] This application provides another embodiment, which differs from the above embodiment in that a portion of the section is skipped when the dynamic link library is loaded for the first time.

[0253] In one possible implementation, when the runtime resolution function of the dynamic linker implements the function of loading the corresponding dynamic link library before it has been loaded, a portion of the sections is skipped during the initial loading of the dynamic link library. The selection method for these sections is similar to that described above for deloading sections, and will not be elaborated further here.

[0254] Specifically, for delayed binding, since the affected GOT entries were already unbound and maintained their initial lazy loading values, and the dynamic link library runtime resolution function in the dynamic linker has been modified to load the dynamic link library from which the symbol to be bound originates if it has not yet been loaded, then if a portion of the dynamic link library is not loaded at startup, these unloaded dynamic link libraries can naturally be loaded on demand when delayed binding is triggered. In this way, we achieve a dynamic, on-demand initial load, rather than an immediate one at startup. Simply put, as long as we make the dynamic link library runtime resolution function in the dynamic linker load the dynamic link library from which the symbol to be bound originates if it has not yet been loaded, then without any additional modifications, we can benefit from this implementation method of skipping a portion of the dynamic link library during the initial load in the case of delayed binding.

[0255] In one possible implementation, for the case of immediate binding (more precisely, when a section that is skipped during the first load contains elements omitted for lazy binding), we only need to build a stub table (different from the stub table used for lazy binding) for each dynamic link library and / or the current program that has affected GOT entries and where immediate binding exists. Then, for each GOT entry that uses immediate binding, we create a corresponding stub entry in the stub table and modify the value of the affected GOT entry to the address of the corresponding stub entry.

[0256] Optionally, the creation of the stub table is the same operation as the creation of the PLT table or stub table for reloading for a second dynamic link library that does not have a PLT table or stub table, as described above; the same table is created. In other words, in the case of immediate binding, the stub table we create here is also the stub table for reloading.

[0257] The following analysis further explains how to trigger the unloading of dynamic link libraries when memory cannot be allocated.

[0258] One possible implementation involves modifying existing memory allocation functions or writing new ones to trigger the unloading of dynamic link libraries when memory allocation is not completed due to exhaustion of user space.

[0259] One possible implementation involves triggering the unloading of the dynamic link library (DLL) when it cannot allocate the required amount of memory from the kernel. If unloading succeeds, it re-attempts to allocate the required amount of memory from the kernel. If the re-attempt also fails, the DLL unloading is triggered again, thus achieving incremental unloading (in other words, only a small number of sections from the DLL can be unloaded each time). A certain number of retries is set. If, after exceeding this set number of retries, all attempts to allocate the required amount of memory from the kernel fail, the user space exhaustion is considered severe, and an error is returned or raised. The specific implementation details are as follows: Figure 14 As shown, it will not be elaborated further here.

[0260] Another possible implementation involves retaining the original memory allocation function and adding a wrapper layer to trigger the unloading of the dynamic link library when memory allocation is not completed due to exhaustion of user space.

[0261] In one possible implementation, when the required memory size cannot be allocated from the existing memory allocation function, the dynamic link library is unloaded. If unloading succeeds, the system re-attempts to allocate the required memory size from the existing memory allocation function. If the re-attempt also fails, the dynamic link library is unloaded again, thus achieving gradual unloading. A certain number of retries is set. If, after exceeding the set number of retries, allocating the required memory size from the existing memory allocation function still fails, the user space exhaustion is considered severe, and an error is returned or raised. The specific implementation of this method is as follows: Figure 15 As shown, it will not be elaborated further here.

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

[0263] Since the deloading trigger in the above scheme is located within the memory allocation function, this function needs to be capable of triggering deloading. An existing executable file might use a memory allocation function that originates from the executable file itself, a dynamic link library, or in some cases, the dynamic linker. In some cases, it might be a combination of these, such as the executable file using its own memory allocation function, but the dynamic link library linked to by the executable file using a memory allocation function from another dynamic link library.

[0264] In other words, for memory allocation functions originating from the executable itself, memory allocations made through those functions cannot benefit from this allocation without recompiling the executable. Put another way, if an existing executable only uses memory allocation functions from its own source (including cases where only static linking is used), it cannot benefit from this allocation without recompiling it.

[0265] As long as an executable file directly or indirectly (e.g., via its dependent or recursively dependent dynamic link libraries) uses memory allocation functions from dynamic link libraries or dynamic linkers, memory allocations via memory allocation functions from dynamic link libraries or dynamic linkers can benefit from this application.

[0266] If an executable file directly or indirectly uses memory allocation functions from the dynamic linker, then since the allocation itself is intended to modify the dynamic linker, it is only necessary to modify the memory allocation functions in the dynamic linker so that they have the ability to trigger unloading when memory cannot be allocated.

[0267] If an executable file directly or indirectly uses a memory allocation function from a dynamic link library (DLL), since this function can only be used after being loaded and bound by the DLL, the DLL can bind it to another memory allocation function with the ability to trigger unloading when binding this function. This allows the DLL to hijack the call to the memory allocation function. This other memory allocation function with the ability to trigger unloading can, for example, come from a DLL, the DLL, or be created on-premises; no particular limitation is made here. For example, this other memory allocation function with the ability to trigger unloading can be a memory allocation function independent of the existing memory allocation function, but with the ability to trigger unloading (as in the first example in the previous section), which we call an independent memory allocation function with the ability to trigger unloading; or it can be a wrapper created for an existing memory allocation function from a DLL, which is equivalent to adding the ability to trigger unloading to the existing memory allocation function from the DLL. We call this a wrapper function. The specific method is as follows: Figure 16 As shown, it will not be elaborated further here.

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

[0269] The following is a specific example to illustrate this.

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

[0271] At a certain point during the execution of program A, it has not yet directly called function 1 from function library C, but it has already called function 2 from function library B. Since function 2 will call function 1, then: function 2 is already bound from the perspective of program A because it was called by program A; function 1 is also already bound from the perspective of function library B because it was called by function 2 from function library B. Therefore, at this point, both functions 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 program A's GOT table, function 2 is already bound, while function 1 is not yet bound; in function library B's GOT table, function 1 is already bound.

[0272] Program A continues execution and eventually directly calls function 1 from function library C. At this point, function 1 is already in memory, and the dynamic linker doesn't need to perform the loading step again; all it needs to do is correctly fill in its address in program A's GOT table. Now, functions 1 and 2 are bound in program A's GOT table; and function 1 is bound in function library B's GOT table.

[0273] As we can see, the GOT table and the PLT table (which will be discussed below) are not globally shared. Instead, program A, library B, and library C each have their own copy, and their contents are different. In other words, not only do programs that use dynamic linking have their own GOT and PLT tables, but the linked dynamic link libraries also have their own, and even the dynamic linker itself has its own.

[0274] The following section uses the x86 GNU LIBC dynamic linker as an example to explain the data structures and processes involved in lazy binding. The names used below may vary depending on the architecture and the dynamic linker employed, but the overall concept remains the same.

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

[0276] What's particularly special is the address of dynamically linked functions (for...). Figure 18In the GOT entries (3-4), the GOT table pre-fills them with default values, which are the addresses of the instructions following the "instruction (family) that jumps to the address pointed to by GOT entry n" in the corresponding PLT entry, and the addresses of the first instruction of the "instruction (family) that loads the function number into a specified register or pushes it onto the stack".

[0277] This is a very ingenious design. The idea is:

[0278] Because the corresponding dynamically linked function is not bound, when execution reaches the instruction (family) that "jumps 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 (family) that "loads the function number into a specified register or pushes it onto the stack", and then continues to jump to PLT entry 0, finally entering _dl_runtime_resolve (the dynamic link library runtime resolution function) to complete the delayed binding. This is the basis for the automatic triggering of the rebinding mentioned earlier. However, this does not mean that the default value of the GOT entry can be arbitrarily selected to achieve this goal. After jumping to the address pointed to by the default value, when execution continues at that address, the function number must be loaded into a specified register or pushed onto the stack, and it must ultimately jump to the dynamic link library runtime resolution function.

[0279] After the delayed binding is completed, when the instruction (cluster) that "jumps to the address pointed to by GOT entry n" is executed again, the corresponding GOT entry is loaded (its value is already the correct address of the corresponding function), so that the jump to the corresponding function can be achieved.

[0280] The contents of PLT entries are often called trampolines, meaning "jumping platform," indicating their function as a "stepping stone." In this example, the PLT entries (excluding entry 0) have two trampolines: the first is the instruction (family) that jumps to the address pointed to by GOT entry n, and the remaining content used for delayed binding is the second. Therefore, the cleverness of delayed binding lies in this: when the first trampoline is used for the first time, the jump destination is the second trampoline, and the latter jumps to _dl_runtime_resolve, thus completing the delayed binding. After delayed binding, the jump destination of the first trampoline is the linked function, and the second trampoline becomes obsolete.

[0281] Figure 19The structure of the stub table is shown. A significant difference between this approach and the approaches described above is that, after function binding, each dynamically linked function call requires one fewer jump than the approach with PLT. This is... Figure 19 It is clearly shown in the text.

[0282] Based on the same technological concept Figure 20 An exemplary embodiment of this application illustrates a device 2000 for expanding user space. For example... Figure 20 The device includes: a determining unit 2001, a modifying unit 2002, and a deloading unit 2003. The determining unit 2001 is used to determine a first dynamic link library and a second dynamic link library when memory allocation 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 the caller of the memory allocation function; the second dynamic link library refers to a dynamic link library that does not have a dependency relationship with the caller of the memory allocation function; determining the address range that would be freed up in memory if the second dynamic link library is deloaded, and determining the Global Offset Table (GOT) entry to be modified based on 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 that has a dependency relationship with the second dynamic link library; the modifying unit 2002 is used to modify the memory address recorded in the GOT entry to be modified to a set value; the set value is used to indicate the reloading of the second dynamic link library; the deloading unit 2003 is used to deload the second dynamic link library.

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

[0284] In one possible implementation, the determining unit 2001 is used to determine all loaded dynamic link libraries; for any dynamic link library among all loaded dynamic link libraries, if the dynamic link library is the direct caller of the memory allocation function, or is located in the call chain of the memory allocation function, then the dynamic link library is excluded from all loaded dynamic link libraries; at least one dynamic link library is selected from all the excluded dynamic link libraries and determined as the second dynamic link library.

[0285] In one possible implementation, the determining unit 2001 is used to analyze the call chain of the memory allocation function by stack backtracking.

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

[0287] In one possible implementation, the modification unit 2002 is used to fill in the memory address used for delayed binding in the process link table PLT entry corresponding to the GOT entry or the memory address of the stub entry corresponding to the GOT entry as a set value for any GOT entry that needs to be modified.

[0288] In one possible implementation, the unloading unit 2003 is used to create a PLT table or stub table for reloading a second dynamic link library that does not have a PLT table or stub table before unloading the second dynamic link library, and to create corresponding PLT table entries or stub table entries for reloading.

[0289] In one possible implementation, the unloading unit 2003 is used to unload sections in the second dynamic link library that have non-writable permissions.

[0290] In one possible implementation, the unloading unit 2003 is used to unload sections in the second dynamic link library that have executable but not writable permissions.

[0291] In one possible implementation, the unloading unit 2003 is used to set the address range in memory freed up by unloading executable but not writable sections to be non-executable.

[0292] In one possible implementation, the above-mentioned apparatus further includes a reloading unit 2004, which is used to reload the second dynamic link library.

[0293] In one possible implementation, the reloading unit 2004 is used to attempt to reload all deloaded dynamic link libraries based on the remaining user space; or, to reload the second dynamic link library that the user program currently needs to call.

[0294] In one possible implementation, a determining unit 2001 is used to determine the section header table of the second dynamic link library; based on the section header table, determine the offset, size, and / or permission attributes of the section to be reloaded in the second dynamic link library; and a reloading unit 2004 is used to request the kernel to load the section of the second dynamic link library based on the offset, size, and / or permission attributes of the section to be reloaded in the second dynamic link library.

[0295] In one possible implementation, the reloading unit 2004 is used to 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.

[0296] In one possible implementation, the above-described apparatus further includes an execution unit 2005, which is used to execute any method of the first aspect via a dynamic linker.

[0297] In one possible implementation, the above-mentioned device further includes a rebinding unit 2006, which is used to re-establish the binding relationship required to complete the call 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.

[0298] In one possible implementation, the rebinding unit 2006 is used to scan all GOT tables of objects that have dependencies on the second dynamic link library after the second dynamic link library is reloaded, and determine the link targets of all GOT table entries; if the link target belongs to the second dynamic link library, then the corresponding GOT table entry is determined to be a GOT table entry that needs to re-establish the binding relationship; for any GOT table entry that needs to re-establish the binding relationship, the memory address of the link target is filled into the GOT table entry.

[0299] Based on the same technical concept, embodiments of this application provide a device 2100 for expanding user space, which may be, for example, a computing device. Figure 21 As shown, an apparatus 2100 for expanding user space includes at least one processor 2101 and a memory 2102 connected to the at least one processor. In this embodiment, the specific connection medium between the processor 2101 and the memory 2102 is not limited. Figure 21Taking the connection between the processor 2101 and the memory 2102 via a bus as an example, the bus can be divided into address bus, data bus, control bus, etc.

[0300] In this embodiment of the application, the memory 2102 stores instructions that can be executed by at least one processor 2101. By executing the instructions stored in the memory 2102, at least one processor 2101 can perform the above-described method for expanding user space.

[0301] The processor 2101 serves as the control center of the device 2100, which extends the user space. It can connect to various parts of the computer device via various interfaces and lines, and performs resource settings by running or executing instructions stored in the memory 2102 and accessing data stored in the memory 2102. Optionally, the processor 2101 may include one or more determining units. The processor 2101 may integrate an application processor and a modem processor, wherein the application processor primarily handles the operating system, user interface, and applications, while the modem processor primarily handles wireless communication. It is understood that the 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; in some embodiments, they may also be implemented on separate chips.

[0302] Processor 2101 can be a general-purpose processor, such as a central processing unit (CPU), digital signal processor, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0303] 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. Memory 2102 may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic memory, magnetic disk, optical disk, etc. Memory 2102 can be any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. In the embodiments of this application, memory 2102 can also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0304] This application also provides a computer-readable storage medium storing a computer-executable program, which is used to cause a computer to perform a method for expanding user space as listed in any of the above embodiments.

[0305] This application provides a computer program product including a computer program executable by a computer device. When the program is run on the computer device, it causes the computer device to perform a method for expanding user space as listed in any of the above methods.

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

[0307] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0308] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0309] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0310] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for expanding user space, characterized in that, include: When a memory allocation 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 the caller of the memory allocation function; the second dynamic link library refers to a dynamic link library that does not have a dependency relationship with the caller of the memory allocation function. Determine the address range that will be freed up in memory if the second dynamic link library is unloaded, and determine the Global Offset Table (GOT) entries that need to be modified based on the address range; the memory address recorded in the GOT entries to be modified falls within the address range, and the GOT entries to be modified are GOT entries of objects that have a dependency relationship with the second dynamic link library; Modify the memory address recorded in the GOT entry that needs 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 as described in claim 1, characterized in that, The determination of the first dynamic link library and the second dynamic link library includes: Determine the direct caller of the memory allocation function, identify the dynamic link library to which the direct caller of the memory allocation function belongs as the first dynamic link library, and identify 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, Analyze the call chain of the memory allocation function, identify the dynamic link library located in the call chain as the first dynamic link library, and identify one or more dynamic link libraries not in the call chain as the second dynamic link library; the call chain includes callers who directly or indirectly call the memory allocation function.

3. The method as described in claim 2, characterized in that, The determination of the second dynamic link library includes: Identify 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 allocation function, or is located in the call chain of the memory allocation function, then the dynamic link library is excluded from all the loaded dynamic link libraries. Select at least one dynamic link library from all the excluded loaded dynamic link libraries and determine it as the second dynamic link library.

4. The method as described in claim 2, characterized in that, The analysis of the call chain of the memory allocation function includes: The call chain of the memory allocation function is analyzed using stack backtracking.

5. The method as described in claim 1, characterized in that, The step of determining the Global Offset Table (GOT) entries to be modified based on the address range includes: Identify objects that have dependencies on the second dynamic link library; the dependencies include direct or indirect dependencies; the objects include the dynamic link library and / or the user program itself. Scan all GOT tables of objects that have dependencies on the second dynamic link library, and identify any entry in any GOT table that falls within the address range as the GOT entry that needs to be modified.

6. The method as described in 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 used for delayed binding in the PLT entry of the corresponding process link table or the memory address of the stub entry of the corresponding GOT entry is used as the setting value and filled into the GOT entry.

7. The method as described in claim 6, characterized in that, The method further includes: Before unloading the second dynamic link library, create a PLT table or stub table for reloading the second dynamic link library that does not have a PLT table or stub table, and create the corresponding PLT table entry or stub table entry for reloading.

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

9. The method as described in claim 8, characterized in that, The step of unloading the non-writable section in the second dynamic link library includes: Unload the section in the second dynamic link library that has executable but not writable permissions.

10. The method as described in claim 9, characterized in that, After unloading the section in the second dynamic link library that has executable but not writable permissions, the process also includes: Set the memory address range freed up by unloading executable but not writable sections 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 as described in claim 11, characterized in that, The reloading of the second dynamic link library includes: Based on the remaining user space, attempt to reload all unloaded dynamic link libraries; or, Reload the second dynamic link library that the user program currently needs to call.

13. The method as described in claim 11, characterized in that, The reloading of the second dynamic link library includes: Determine the section header table of the second dynamic link library; Based on the section header table, determine the offset, size, and / or permission attributes of the section that needs to be reloaded in the second dynamic link library; Based on the offset, size, and / or permission attributes of the section that needs to be reloaded in the second dynamic link library, request the kernel to load the section of the second dynamic link library.

14. The method as described in claim 11, characterized in that, After reloading the second dynamic link library, the process also includes: For objects that have a dependency relationship with the second dynamic link library, re-establish the binding relationship with the second dynamic link library.

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

16. A device for expanding user space, characterized in that, include: The determining unit is configured to determine a first dynamic link library and a second dynamic link library when memory allocation 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 the caller of the memory allocation function; the second dynamic link library refers to a dynamic link library that does not have a dependency relationship with the caller of the memory allocation function; determine the address range in memory that would be freed up if the second dynamic link library is unloaded, and determine the Global Offset Table (GOT) entries that need to be modified based on the address range; the memory address recorded in the GOT entries to be modified falls within the address range, and the GOT entries to be modified are GOT entries of objects that have a dependency relationship with the second dynamic link library; The modification unit is used to modify the memory address recorded in the GOT 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: Memory, used to store program instructions; A processor is configured to invoke program instructions stored in the memory and execute the method as described in any one of claims 1 to 15 according to the obtained program instructions.

18. A computer-readable storage medium, characterized in that, Includes computer-readable instructions that, when read and executed by a computer, cause the method as described in any one of claims 1 to 15 to be implemented.

19. A computer program product, characterized in that, It includes a computer program executable by a computer device, which, when run on the computer device, causes the computer device to perform the steps of the method according to any one of claims 1 to 15.

Images