Data processing method and device, storage medium and electronic device

Abstract

The present application discloses a data processing method and device, a storage medium, and an electronic device. The method comprises: when a target process needs to load a dynamic link library, determining the variable identifier and the starting position of the assembly code corresponding to the target thread-local storage variable that the patch function needs to access based on the code snippet associated with the patch function; searching for target relocation information with the variable identifier in the executable file based on the variable identifier; if the target relocation information is not found, modifying the assembly code corresponding to the thread-local storage variable with the same name based on the target offset to obtain the target assembly code; replacing the initial assembly code with the target assembly code, and modifying the relocation type of the target thread-local storage variable to prohibit relocation, updating and loading the dynamic link library. The present application solves the technical problem of patch function loading failure caused by the different addressing methods of thread-local storage variables in conventional dynamic mode and local executable mode.

Description

Technical Field

[0001] The present application relates to the field of computers, and more specifically, to a data processing method and device, a storage medium, and an electronic device. Background Art

[0002] Currently, in existing dynamic link libraries, thread-local storage variables are usually relocated through the global offset table. When the dynamic link library is loaded into memory, the address of the thread-local storage variable will be filled in the global offset table, and the program accesses the thread-local storage variable through the global offset table during runtime.

[0003] However, when the patch function in the dynamic link library uses the conventional dynamic mode to address the thread-local storage variables, and the thread-local storage variables are addressed in the local executable mode in the executable file, the patch function fails to load due to the lack of relocation information in the local executable mode. That is, there is a technical problem in the related art that the patch function fails to load due to the different addressing methods of thread-local storage variables in the conventional dynamic mode and the local executable mode.

[0004] To address the above-mentioned problems, no effective solutions have been proposed so far. Summary of the Invention

[0005] The embodiments of the present application provide a data processing method and device, a storage medium, and an electronic device to at least solve the technical problem of patch function loading failure caused by the different addressing methods of thread-local storage variables in conventional dynamic mode and local executable mode.

[0006] According to one aspect of an embodiment of the present application, a data processing method is provided, comprising: when a target process needs to load a dynamic link library, determining, based on a code snippet associated with a patch function, a variable identifier and a starting position of a corresponding assembly code corresponding to a target thread-local storage variable that the patch function needs to access, wherein the dynamic link library includes the patch function; searching an executable file for target relocation information having the variable identifier, and if the target relocation information is not found, determining that an access mode of the target thread-local storage variable is a local executable mode; when the access mode of the target thread-local storage variable is the local executable mode, determining, based on the variable identifier, a thread-local storage variable with the same name having the variable identifier in the executable file, and a target offset of the thread-local storage variable with the same name; modifying the assembly code corresponding to the thread-local storage variable with the same name based on the target offset to obtain a target assembly code; replacing an initial assembly code corresponding to the starting position with the target assembly code, modifying the relocation type of the target thread-local storage variable to prohibit relocation, and updating and loading the dynamic link library.

[0007] According to another aspect of an embodiment of the present application, a data processing device is provided, comprising: a determination module for determining, when a target process needs to load a dynamic link library, a variable identifier and a starting position of a corresponding assembly code corresponding to a target thread-local storage variable that the patch function needs to access based on a code snippet associated with a patch function, wherein the dynamic link library includes the patch function; a search module for searching for target relocation information with the variable identifier in an executable file, and determining, if the target relocation information is not found, that the access mode of the target thread-local storage variable is a local executable mode; an execution module for determining, when the access mode of the target thread-local storage variable is the local executable mode, a thread-local storage variable with the variable identifier and a target offset of the thread-local storage variable with the same name in the executable file based on the variable identifier; a modification module for modifying the assembly code corresponding to the thread-local storage variable with the same name based on the target offset to obtain a target assembly code; and a replacement module for replacing the initial assembly code corresponding to the starting position with the target assembly code, modifying the relocation type of the target thread-local storage variable to prohibiting relocation, and updating and loading the dynamic link library.

[0008] Optionally, the device is used to determine the variable identifier corresponding to the target thread-local storage variable that the patch function needs to access and the starting position of the corresponding assembly code based on the code snippet associated with the patch function in the following manner: traverse the memory corresponding to the dynamic link library to search for the code snippet, wherein the first part of bytes of the code snippet is in a preset format, and the code snippet includes the first part of bytes; determine the variable identifier and the starting position based on the relocation table corresponding to the code snippet and the dynamic link library.

[0009] Optionally, the device is used to determine the variable identifier and the starting position based on the relocation table corresponding to the code snippet and the dynamic link library in the following manner, including: determining a first offset value between the code snippet and the register based on the second part of bytes of the code snippet, wherein the code snippet includes the second part of bytes; obtaining the address of the next operation instruction of the register; and determining the variable identifier and the starting position in the relocation table based on the sum of the first offset value and the address.

[0010] Optionally, the device is used to search for target relocation information with the variable identifier in the executable file in the following manner, and if the target relocation information is not found, determine that the access mode of the target thread-local storage variable is the local executable mode: obtain symbol information of the executable file; if the symbol information is of a preset type, determine that the executable file includes the target thread-local storage variable; search for target relocation information with the variable identifier in the executable file; if the target relocation information is not found, determine that the access mode of the target thread-local storage variable is the local executable mode.

[0011] Optionally, the apparatus is configured to, when the access mode of the target thread-local storage variable is the local executable mode, determine, in the executable file, a thread-local storage variable with the same name and the variable identifier, and a target offset of the thread-local storage variable with the same name, according to the variable identifier, in the following manner: when the access mode of the target thread-local storage variable is the local executable mode, determine, in the executable file, a thread-local storage variable with the same name and the variable identifier, according to the variable identifier; obtain a second offset of the thread-local storage variable with the same name in the thread-local storage space and an alignment size of the thread-local storage space; and determine the target offset according to the second offset and the alignment size.

[0012] Optionally, the device is configured to determine the target offset based on the second offset and the alignment size in the following manner: determining a third offset corresponding to the last thread local storage variable in the thread local storage space; determining a sum of the third offset and the alignment size as a pointer offset; and determining a difference between the second offset and the pointer offset as the target offset.

[0013] Optionally, the device is used to modify the assembly code corresponding to the thread-local storage variable with the same name according to the target offset to obtain the target assembly code: obtain the assembly code corresponding to the thread-local storage variable with the same name, wherein the assembly code corresponding to the thread-local storage variable with the same name includes at least 4 bytes; and modify the last 4 bytes of the assembly code corresponding to the thread-local storage variable with the same name according to the target offset to obtain the target assembly code.

[0014] According to another aspect of the embodiments of the present application, a computer-readable storage medium is provided, in which a computer program is stored. The computer program is configured to execute the above-mentioned data processing method when running.

[0015] According to another aspect of the embodiments of the present application, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the above data processing method.

[0016] According to another aspect of the embodiments of the present application, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the data processing method through the computer program.

[0017] In an embodiment of the present application, when a target process needs to load a dynamic link library, a variable identifier corresponding to a target thread local storage variable that the patch function needs to access and a starting position of the corresponding assembly code are determined based on a code snippet associated with the patch function, wherein the dynamic link library includes the patch function; a search is performed to determine whether there is target relocation information with a variable identifier in the executable file; if no target relocation information is found, the access mode of the target thread local storage variable is determined to be a local executable mode; if the access mode of the target thread local storage variable is a local executable mode, the thread with the same name as the variable identifier is determined in the executable file based on the variable identifier. Local storage variables, as well as the target offset of the thread-local storage variable with the same name; modifying the assembly code corresponding to the thread-local storage variable with the same name according to the target offset to obtain the target assembly code; using the target assembly code to replace the initial assembly code corresponding to the starting position, and modifying the relocation type of the target thread-local storage variable to prohibit relocation, updating and loading the dynamic link library, thereby releasing the relocation dependency of the target thread-local storage variable in the patch function, allowing the patch function to be successfully loaded, and further solving the technical problem of patch function loading failure caused by the different addressing methods of thread-local storage variables in conventional dynamic mode and local executable mode. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0019] Figure 1 is a schematic diagram of an application environment of an optional data processing method according to an embodiment of the present application;

[0020] Figure 2 is a flowchart of an optional data processing method according to an embodiment of the present application;

[0021] Figure 3 is a schematic diagram of an optional data processing method according to an embodiment of the present application;

[0022] Figure 4 is a schematic diagram of another optional data processing method according to an embodiment of the present application;

[0023] Figure 5 is a schematic diagram of another optional data processing method according to an embodiment of the present application;

[0024] Figure 6 is a schematic diagram of another optional data processing method according to an embodiment of the present application;

[0025] Figure 7 is a schematic diagram of another optional data processing method according to an embodiment of the present application;

[0026] Figure 8 is a schematic diagram of another optional data processing method according to an embodiment of the present application;

[0027] Figure 9 is a schematic diagram of another optional data processing method according to an embodiment of the present application;

[0028] Figure 10 is a schematic diagram of another optional data processing method according to an embodiment of the present application;

[0029] Figure 11 is a schematic diagram of another optional data processing method according to an embodiment of the present application;

[0030] Figure 12 is a schematic diagram of another optional data processing method according to an embodiment of the present application;

[0031] Figure 13 is a schematic structural diagram of an optional data processing device according to an embodiment of the present application;

[0032] Figure 14 is a schematic structural diagram of an optional data processing product according to an embodiment of the present application;

[0033] Figure 15 It is a schematic structural diagram of an optional electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0034] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0035] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in a sequence other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0036] The present application will be described below with reference to the following embodiments:

[0037] According to one aspect of an embodiment of the present application, a data processing method is provided. Optionally, in this embodiment, the data processing method can be applied to Figure 1 In the hardware environment composed of the server 101 and the terminal device 103 shown in FIG. Figure 1As shown, the server 101 is connected to the terminal device 103 via a network and can be used to provide services for the terminal device or the application installed on the terminal device. The application 107 can be a video application, instant messaging application, browser application, educational application, game application, etc. A database 105 may be set up on the server or independently of the server to provide data storage services for the server 101, for example, a game data storage server. The above-mentioned network may include but is not limited to: a wired network, a wireless network, wherein the wired network includes: a local area network, a metropolitan area network and a wide area network, and the wireless network includes: Bluetooth, WIFI and other networks that realize wireless communication. The terminal device 103 may be a terminal configured with an application, and may include but is not limited to at least one of the following: a mobile phone (such as an Android phone, an iOS phone, etc.), a laptop computer, a tablet computer, a PDA, a MID (Mobile Internet Devices), a PAD, a desktop computer, a smart TV, an intelligent voice interaction device, a smart home appliance, a vehicle-mounted terminal, an aircraft, a virtual reality (VR) terminal, an augmented reality (AR) terminal, a mixed reality (MR) terminal and other computer devices. The above-mentioned server may be a single server, a server cluster consisting of multiple servers, or a cloud server.

[0038] Combine Figure 1 As shown, the above data processing method can be executed by an electronic device, which can be a terminal device or a server. The above data processing method can be implemented by the terminal device or the server separately, or by the terminal device and the server together.

[0039] The above is only an example and is not specifically limited in this embodiment.

[0040] Alternatively, as an optional implementation, Figure 2 As shown, the method for processing the above data includes:

[0041] S202, when the target process needs to load a dynamic link library, determining, based on a code snippet associated with the patch function, a variable identifier corresponding to a target thread-local storage variable that the patch function needs to access and a starting position of the corresponding assembly code, wherein the dynamic link library includes the patch function;

[0042] Optionally, in an embodiment of the present application, the above-mentioned target process can be understood as an instance of a program running in a computer, which may include but is not limited to program code, data, and execution status, etc. Each process has an independent memory space, and multiple processes can run simultaneously without affecting each other. The above-mentioned dynamic link library refers to a library file containing code and data that can be dynamically loaded by the program at runtime, which can be shared by multiple programs and can be updated or replaced while the program is running without recompiling or restarting the program. The above-mentioned patch function refers to a defect repair function, which means a function that repairs erroneous logic and implements normal functions. The defect function here refers to a function with erroneous logic running in the target process.

[0043] Exemplarily, this may include, but is not limited to, replacing the instructions of the defective function with the instructions of the patch function when the target process is running, so as to ensure that the target process can run normally.

[0044] It should be noted that the above-mentioned dynamic link library may include but is not limited to pre-compiled functions, variables, classes or other code fragments, and this application does not limit the compilation process.

[0045] In an exemplary embodiment, assuming that there is a target process A that is running and executing business functions, a faulty logic in the target process A can be repaired by loading a dynamic link library B containing a patch function. Once the dynamic link library B is successfully loaded into the target process A, the patch file can be used to dynamically load the patched process, read the patch function information implemented in the patch file, and search for a function with the same name among all functions that can be used by the patched process based on the name of the patch function. If a function with the same name is found, it means that the function with the same name is the function that needs to be patched. Then, the assembly instruction at the function address entry of the function to be patched in the patched process is modified, and the assembly instruction content is modified to: jump to the address of the function with the same name implemented in the patch dynamic link library, thereby repairing the faulty logic. In other words, even if the target process A is running, the faulty logic can be repaired by loading the dynamic link library without stopping the operation of the target process A.

[0046] Optionally, in an embodiment of the present application, the above-mentioned code snippet may be located in the above-mentioned dynamic link library, the above-mentioned target thread local storage variable refers to a TLS (Thread Local Storage) variable, the above-mentioned variable identifier may include but is not limited to the variable name of the target thread local storage variable, and the above-mentioned dynamic link library may include the assembly code corresponding to the target thread local storage variable.

[0047] It should be noted that Thread Local Storage (TLS) is a thread-level storage mechanism that allows each thread in a process to have its own private variables at runtime. The target thread-local storage variables can only be accessed by the corresponding thread and will not be shared by other threads. In other words, the target thread-local storage variables are thread-private variables and will not be open to the target process. Global variables accessed by any thread in the target process are all in the same memory space.

[0048] In an exemplary embodiment, Figure 3 is a schematic diagram of an optional data processing method according to an embodiment of the present application, such as Figure 3 As shown, taking the target process in the X86-64-bit CPU (central processing unit) as an example, it includes but is not limited to:

[0049] S302, start;

[0050] S304, traversing the program code of the dynamic link library;

[0051] S306, determine whether there is a code segment in the program code where bytes 0 to 1 are 0x66 0x48 and bytes 8 to 10 are 0x66 0x66 0x48. If so, execute S308; if not, execute S314.

[0052] S308, determining whether the offset value of bytes 4 to 7 relative to rip in little-endian order is within the range of the GOT table after adding the offset value to the rip value. Rip refers to the instruction pointer register in the x86 architecture, which is used to store the memory address of the currently executed instruction. During program execution, rip is continuously updated to the address of the next instruction to be executed. The GOT (Global Offset Table) is a table that stores variable offset addresses and is used to store variable addresses in a dynamic link library. The variables here may include but are not limited to global variables and TLS variables. If so, executing S310; if not, executing S314;

[0053] S310, determine whether the offset value of bytes 4 to 7 relative to rip plus the rip value in little endian is consistent with the "offset" field in the relocation table of type R_X86_64_DTPMOD64 (64-bit data pointer module relocation of the x86_64 architecture). If so, execute S312; if not, execute S314;

[0054] Taking the X86-64 CPU as an example, the function __tls_get_addr is called with a pointer parameter pointing to an object of type tls_index, and the access address of the corresponding TLS variable (the target thread-local storage variable) in the current thread can be calculated. The function __tls_get_addr is expressed as "extern void*__tls_get_addr(tls_index*ti)", where the type tls_index is defined as follows:

[0055]

[0056]

[0057] When the linker links, the two members ti_module and ti_offset of the tls_index structure allocated to each TLS variable are stored in the GOT table (Global Offset Table), where the member ti_module is associated with the relocation type R_X86_64_DTPMOD64 of the TLS variable, and the member ti_offset is associated with the relocation type R_X86_64_DTPOFF64 of the TLS variable. ti_module is an index pointing to the TLS module, which is used to find the corresponding TLS variable in the TLS module; and ti_offset is the offset of the TLS variable in the TLS module, which is used to calculate the access address of the TLS variable in the current thread.

[0058] For example, the dynamic link library libtest.so in ELF (executable and link) format can be used to see the relocation information in the dynamic link library through the readelf-rlibtest.so command. Among them, the R_X86_64_DTPMOD64 type offset address of the TLS variable t_flg is 0x000000200fd0, indicating that the ti_module information of the t_flg variable is stored in the GOT table at the 0x000000200fd0 position, and the R_X86_64_DTPOFF64 type offset address of the TLS variable t_flg is 0x000000200fd8, indicating that the ti_offset information of the t_flg variable is stored in the GOT table at the 0x000000200fd8 position.

[0059] S312, determining the variable identifier and binary assembly code position of the TLS variable (target thread local storage variable) operated by the current code segment, that is, the above-mentioned starting position;

[0060] S314, end.

[0061] For example, Figure 4 This is a schematic diagram of another optional data processing method according to an embodiment of the present application. There is an ELF format dynamic link library libtest.so. The relocation information in the dynamic link library can be seen by the readelf-rlibtest.so command. Figure 4 As shown, the R_X86_64_DTPMOD64 type offset address of the target thread local storage variable t_flg is 0x000000200fd0, indicating that the ti_module information of the t_flg variable is stored in the GOT table at 0x000000200fd0, and the R_X86_64_DTPOFF64 type offset address of the target thread local storage variable t_flg is 0x000000200fd8, indicating that the ti_offset information of the t_flg variable is stored in the GOT table at 0x000000200fd8 (the GOT table (Global Offset Table) is a table that stores variable offset addresses and is used to store the addresses of various variables in the dynamic library.

[0062] Furthermore, there is an 8-byte difference from 0x000000200fd0 to 0x000000200fd8, and the length of the ti_module member is 8 bytes. Therefore, the 16-byte continuous space starting from the address 0x000000200fd0 in the GOT table is used to store the tls_index information of the t_flg variable. When implementing the assembly code, you can first find the address 0x000000200fd0 and store it in the register rdi that passes the first function parameter, and then call the __tls_get_addr function to get the access address of the target thread local storage variable t_flg in the current thread. Then, the compiled 16-byte binary assembly code is implemented as follows:

[0063] 8e5:66 48 8d 3d e3 06 20 00data16 lea 0x2006e3(%rip),%rdi#200fd0<_DYNAMIC+0x210>;

[0064] 8ed:66 66 48e8 bb fe ff ff data16 data16 callq 7b0<__tls_get_addr@plt>;

[0065] 8f5: ...

[0066] Among them, the first two bytes of the first line 0x66 0x48 are fixed to represent the prefix, 0x8d 0x3d 0xe3 0x06 0x20 0x00 implements the function of lea 0x2006e3 (%rip), %rdi, and the 4 bytes starting from the 4th byte 0xe3 0x06 0x20 0x00 are 0x2006e3 in little endian order. When calling the first line, rip represents the address 0x8ed of the next instruction, 0x2006e3+0x8ed=0x200fd0, which is exactly the address of the variable t_flg storing ti_offset information in the GOT table. The first three bytes of the second line 0x66 0x66 0x48 are fixed to represent the prefix, followed by e8 bb fe ff ff implements the function of calling the __tls_get_addr interface. Therefore, the code segment of the dynamic link library libtest.so is traversed in the ELF format. If the first two bytes of the code segment are 0x660x48, the 8th to 10th bytes (starting from 0) are 0x66 0x66 0x48, and the 4th to 7th bytes (starting from 0) are in little endian order, the offset value relative to rip (0x2006e3) plus the rip value (for example, 0x8ed) is 0x200fd0. Look up in the relocation table of type R_X86_64_DTPMOD64. If the Offset field value (0x200fd0) is consistent with the value of a target thread local storage variable in the relocation table (0x200fd0 of t_flg), it can be determined that the variable identifier operated in the code segment is t_flg and the starting position of the binary assembly code is 0x8e5.

[0067] S204, searching for target relocation information with a variable identifier in the executable file, and if no target relocation information is found, determining that the access mode of the target thread-local storage variable is a local executable mode;

[0068] Optionally, in the embodiment of the present application, the target relocation information may include but is not limited to: Figure 4 As shown, it includes the index of the target thread local storage variable, the offset of the target thread local storage variable, the storage address of the target thread local storage variable, etc.

[0069] It should be noted that the above-mentioned local executable mode refers to: through the strict limitation of the definition and usage scenarios of TLS variables (the above-mentioned thread-local storage variables of the same name), the local executable mode (abbreviated as LE) is optimized. This mode can only reference TLS variables defined in the executable file. When linking, the linker can calculate the relative offset of each TLS variable relative to the thread control block (TCB) pointer. When addressing, it can directly find the thread control block (TCB) pointer and add this offset value to find the address of the TLS variable without relocation. The most common application scenario of LE mode is the use of TLS variables defined in the executable file by functions compiled in a static linking manner.

[0070] For example, Figure 5 is a schematic diagram of another optional data processing method according to an embodiment of the present application, such as Figure 5 As shown in the figure, Thread 1 and Thread 2 each have their own Thread Local Storage (TLS) space for TLS variables at runtime. The corresponding TLS variable TLS thread local storage space can only be accessed by the thread to which it belongs and is not shared by other threads. When the linker links, the memory space of each thread variable and thread control block (TCB) is arranged.

[0071] For example, in the thread local storage space, the offset of TLS variable 1 is 0 and the length is 4, the offset of TLS variable 2 is 4 and the length is 4, the offset of TLS variable N is 28 and the length is 4, and the offset of the TCB pointer is 32 (0x20). When actually accessing the TLS variable, first get the address of the TCB pointer, add the relative offset, and you can get the address of the TLS variable, and then access the TLS variable.

[0072] For another example, the address of the TCB pointer of thread 1 is 0x40020. If TLS variable 1 needs to be accessed, the offset of TLS variable 1 is calculated to be 0–0x20=-0x20, and the address of TLS variable 1 can be calculated to be 0x40020-0x20=0x40000.

[0073] In an exemplary embodiment, Figure 6 is a schematic diagram of another optional data processing method according to an embodiment of the present application, such as Figure 6 As shown, whether the access mode of the target thread-local storage variable is the local executable mode may be determined by, but not limited to, the following methods:

[0074] S602, start;

[0075] S604, parse the executable file according to the ELF format to obtain symbol information, and determine whether the type of the symbol information is STT_TLS. If the variable identifier type is STT_TLS, it indicates that the variable identifier is a TLS variable (the above-mentioned target thread local storage variable);

[0076] S606, determine whether the symbol information indicates a target thread local storage variable, and search the relocation information for a variable identifier with the same name according to the variable identifier name. If not, execute S608; if so, execute S610;

[0077] S608, determining whether the target thread-local storage variable is used in a local executable mode;

[0078] S610: Determine that the target thread-local storage variable is not used in the local executable mode, and end.

[0079] In yet another exemplary embodiment, Figure 7 is a schematic diagram of another optional data processing method according to an embodiment of the present application, such as Figure 7 As shown, the variable identification information of the executable file is parsed according to the ELF format. If the variable identification is STT_TLS, it indicates that the variable identification is a TLS variable (the above-mentioned target thread local storage variable). The relocation table corresponding to the executable file is searched according to the variable identification name of the TLS variable. If there is no relocation information with the same name (such as Figure 7 If a thread-local storage variable with the same name is found, it means that the local executable mode in the executable file uses the TLS variable.

[0080] For example, Figure 8 is a schematic diagram of another optional data processing method according to an embodiment of the present application, such as Figure 8 As shown, use "readelf -r executable file name" to view the relocation information. For example, after confirming that t_InSoflg is the TLS variable of the executable file process_a, enter "readelf -r process_a" to search for the TLS variable in the output relocation information. No information with the same name is found, indicating that the TLS variable t_InSoflg is used in local executable mode.

[0081] S206, when the access mode of the target thread-local storage variable is the local executable mode, determining a thread-local storage variable with the same name as the variable identifier in the executable file according to the variable identifier, and a target offset of the thread-local storage variable with the same name;

[0082] Optionally, in an embodiment of the present application, the above-mentioned thread-local storage variable with the same name refers to a variable having the same variable identifier as the above-mentioned target thread-local storage variable, and the thread-local storage variable with the same name is defined in the above-mentioned thread-local storage variable with the same name. The above-mentioned target offset may include but is not limited to being determined by the offset of the thread-local storage variable with the same name in the thread-local storage space and the offset of the last TLS variable in the thread-local storage space.

[0083] Exemplarily, the above-mentioned starting position is 0x8e5 of the code segment, and the 16 bytes starting from 0x8e5 (66 48 8d 3de3 06 20 00 66 66 48e8 bb fe ff ff) are determined according to the variable identifier t_flg. The thread local storage variable t_flg with the same name exists in the executable file. The variable identifier is also t_flg. The thread local storage variable t_flg with the same name uses the local executable mode in the executable file.

[0084] Furthermore, the variable identifier t_flg is used to determine that the offset of the thread local storage variable t_flg with the same name in the thread local storage space is 8 in the executable file (process_a) in the ELF file format. The offset of the last TLS variable in the thread local storage space in the entire executable file is 8 and the length is 4. It is found that the TLS variable is aligned according to 4 bytes. Therefore, the above target offset value is 8+4=12.

[0085] S208, modifying the assembly code corresponding to the thread-local storage variable with the same name according to the target offset to obtain the target assembly code;

[0086] S210: Replace the initial assembly code corresponding to the starting position with the target assembly code, modify the relocation type of the target thread local storage variable to prohibit relocation, and update and load the dynamic link library.

[0087] Optionally, in an embodiment of the present application, the target assembly code is used to execute the functionality of the patch function.

[0088] In an exemplary embodiment, the offset 8 of the thread-local storage variable with the same name minus the offset 12 of the TCB (thread block) pointer can be used to obtain the target offset value of the target thread-local storage variable relative to the TCB pointer, which is 8-12=-4, and is represented as fc ff ff ff in hexadecimal complement.

[0089] Furthermore, the target offset value is used to replace the last four bytes of the binary assembly code 64 48 8b 04 25 00 00 00 00 48 8d 80f8ff ff ff (the last four bytes f8 ff ff ff are the offset value) used in the local executable mode to access the thread local storage variable of the same name, and generate the binary assembly code 64 48 8b 04 25 00 00 0000 48 8d 80fc ff ff ff used in the local executable mode of the TLS variable t_flg. Thus, the 16-byte LE mode is replaced starting from the above-mentioned starting position 0x8e5 in the dynamic link library using the assembly code of the t_flg variable, thereby realizing the update of the dynamic link library. Then, the dynamic link library can be successfully loaded in the above-mentioned target process.

[0090] Optionally, in an embodiment of the present application, the target assembly code and the initial assembly code may implement the same or different business functions, which is not limited in the present application.

[0091] Exemplarily, taking the X86-64-bit CPU as an example, the above relocation types may include but are not limited to R_X86_64_DTPMOD64, R_X86_64_DTPOFF64, R_X86_64_RELATIVE types, etc.

[0092] In an exemplary embodiment, Figure 9 This is a schematic diagram of another optional data processing method according to an embodiment of the present application, in which the relocation type in the target thread local storage variable is modified to the R_X86_64_RELATIVE type, so that the operating system does not relocate t_InSoflg, and then successfully loads the dynamic link library libhotpatchtest.so. The target thread local storage variable of the modified dynamic link library is as follows: Figure 9 shown.

[0093] In yet another exemplary embodiment, Figure 10 is a schematic diagram of another optional data processing method according to an embodiment of the present application, such as Figure 10 As shown, the patch file is dynamically loaded by the patched process in a dynamic loading manner, the patch function information implemented in the patch file is read, and the function with the same name is searched among all the functions used by the patched process according to the function name. If it is found, it is the function that needs to be patched, and the function that needs to be patched in the patched process is modified (such as Figure 10 The assembly instruction at the entry of the func A) address shown is modified to jump to the address of the function with the same name implemented in the patch dynamic link library, thereby replacing the patched function with the patch function and repairing the function defect problem.

[0094] For example, the data processing method proposed in this application can be applied to the hot patch loading process. Figure 11 is a schematic diagram of another optional data processing method according to an embodiment of the present application, such as Figure 11 As shown, including but not limited to:

[0095] S1102, start;

[0096] S1104, determining the variable identifier of the target thread local storage variable and the starting position of the binary assembly code according to the code fragment associated with the patch function;

[0097] S1106, determine whether the target thread local storage variable uses the local executable mode in the executable file, if so, execute S1108, if not, execute S1116.

[0098] S1108, searching for a thread-local storage variable with the same name and the same variable identifier as the target thread-local storage variable in the executable file in the ELF file format according to the variable identifier (for example, using the readelf -s executable file name method to obtain it), and determining the offset of the thread-local storage variable with the same name in the thread-local storage space;

[0099] S1110, determining the offset of the TCB (thread block) pointer based on the offset and length of the last TLS variable (thread local storage variable with the same name) in the executable file and the number of aligned bytes;

[0100] S1112, subtract the offset of the TCB pointer from the offset of the thread-local storage variable of the same name to obtain the offset of the TLS variable relative to the TCB pointer (the above-mentioned target offset). Use this offset value to replace the last four bytes of the binary assembly code 64 48 8b 04 25 00 00 00 00 48 8d80f8 ff ff ff (the last four bytes f8 ff ffff are the offset value) of the LE mode TLS variable access, and generate the local executable mode assembly code of the corresponding TLS variable (the above-mentioned target assembly code).

[0101] S1114, starting from the starting position of the binary assembly code corresponding to the target thread-local storage variable, replace the original binary assembly code corresponding to the target thread-local storage variable with the 16-byte local executable mode assembly code in the dynamic link library;

[0102] S1116, end.

[0103] According to the embodiment of the present application, when the target process needs to load a dynamic link library, the variable identifier corresponding to the target thread local storage variable that the patch function needs to access and the starting position of the corresponding assembly code are determined according to the code fragment associated with the patch function, wherein the dynamic link library includes the patch function; whether there is target relocation information with the variable identifier in the executable file, if the target relocation information is not found, it is determined that the access mode of the target thread local storage variable is the local executable mode; if the access mode of the target thread local storage variable is the local executable mode, the thread with the same name as the variable identifier is determined in the executable file according to the variable identifier. Local storage variables, as well as the target offset of the thread-local storage variable with the same name; modifying the assembly code corresponding to the thread-local storage variable with the same name according to the target offset to obtain the target assembly code; using the target assembly code to replace the initial assembly code corresponding to the starting position, and modifying the relocation type of the target thread-local storage variable to prohibit relocation, updating and loading the dynamic link library, thereby releasing the relocation dependency of the target thread-local storage variable in the patch function, allowing the patch function to be successfully loaded, and further solving the technical problem of patch function loading failure caused by the different addressing methods of thread-local storage variables in conventional dynamic mode and local executable mode.

[0104] As an optional solution, the above-mentioned method of determining the variable identifier corresponding to the target thread-local storage variable that the patch function needs to access and the starting position of the corresponding assembly code based on the code snippet associated with the patch function includes: traversing the memory corresponding to the above-mentioned dynamic link library to search for the above-mentioned code snippet, wherein the first part of bytes of the above-mentioned code snippet is in a preset format, and the above-mentioned code snippet includes the above-mentioned first part of bytes; and determining the above-mentioned variable identifier and the above-mentioned starting position based on the above-mentioned code snippet and the relocation table corresponding to the above-mentioned dynamic link library.

[0105] Optionally, in an embodiment of the present application, the above-mentioned relocation table refers to a data structure used to record the addresses and offsets of instructions, variables, functions, etc. that need to be relocated when the program is loaded. The above-mentioned preset format can be flexibly set, and this application does not limit this.

[0106] For example, the memory corresponding to the dynamic link library is traversed to obtain the location and storage status of each function, variable and other related data structures in the dynamic link library in the memory, and then the corresponding code segment in the memory is obtained. The code segment can be Figure 4 shown.

[0107] Further, in Figure 4In the example shown, the difference between 0x000000200fd0 and 0x000000200fd8 is 8 bytes, which is the length of the ti_module member. Therefore, the 16-byte continuous space starting from the address 0x000000200fd0 in the GOT table is used to store the tls_index information of the t_flg variable. When implementing the assembly code, the address 0x000000200fd0 is found and stored in the register rdi that passes the first function parameter. Then, the __tls_get_addr function is called to obtain the access address of the TLS variable t_flg in the current thread.

[0108] The following is an example of a 16-byte binary assembly code implementation:

[0109] 8e5:66 48 8d 3d e3 06 20 00data16 lea 0x2006e3(%rip),%rdi#200fd0<_DYNAMIC+0x210>;

[0110] 8ed:66 66 48e8 bb fe ff ff data16 data16 callq 7b0<__tls_get_addr@plt>;

[0111] 8f5: ...

[0112] Among them, the first two bytes of the first line 0x66 0x48 are fixed to represent the prefix, 0x8d 0x3d 0xe3 0x06 0x20 0x00 implements the function of lea 0x2006e3 (%rip), %rdi, and the 4 bytes starting from the 4th byte 0xe3 0x06 0x20 0x00 are 0x2006e3 in little endian order. When calling this line, rip represents the address 0x8ed of the next instruction, 0x2006e3+0x8ed=0x200fd0, which is exactly the address of the variable t_flg storing ti_offset information in the GOT table. The first three bytes of the second line 0x66 0x66 0x48 are fixed to represent the prefix, e8 bb fe ff ff implements the function of calling the __tls_get_addr interface.

[0113] Furthermore, the code segment of the dynamic link library libtest.so is traversed according to the ELF format. If there is a code segment whose 0th to 1st bytes are 0x66 0x48, and the 8th to 10th bytes are 0x66 0x66 0x48, the above first part of bytes is determined as the 0th to 1st bytes and the 8th to 10th bytes of the code segment. The above preset format indicates that the 0th to 1st bytes in the code segment are 0x66 0x48, and the 8th to 10th bytes are 0x66 0x66 0x48.

[0114] As an optional solution, the above-mentioned determination of the variable identifier and the above-mentioned starting position based on the relocation table corresponding to the above-mentioned code snippet and the above-mentioned dynamic link library includes: determining a first offset value between the register and the second part of bytes of the above-mentioned code snippet, wherein the above-mentioned code snippet includes the above-mentioned second part of bytes; obtaining the address of the next operation instruction of the above-mentioned register; and determining the above-mentioned variable identifier and the above-mentioned starting position in the above-mentioned relocation table according to the sum of the above-mentioned first offset value and the above-mentioned address.

[0115] Optionally, in an embodiment of the present application, the above-mentioned first part of bytes and second part of bytes can be flexibly set. Specifically, they can be related to the system, hardware equipment, central processing unit, etc. where the process is located. This application does not limit this.

[0116] Exemplarily, the little endian sequence means that the low-order bytes of the data are arranged at the low address of the memory, and the high-order bytes are arranged at the high address of the memory, and "8e5: 66 48 8d 3d e3 06 20 00data16lea 0x2006e3 (%rip), %rdi#200fd0<_DYNAMIC+0x210>;8ed:66 66 48e8bb fe ff ff data16 data16callq 7b0<__tls_get_addr@plt>;8f5:…" is used as an example to illustrate, where the 4 bytes starting from the 4th byte are 0xe3 0x06 0x20 0x00 is the second part of the bytes mentioned above, that is: 0x2006e3. When this line of instruction is called, rip represents the address 0x8ed of the next instruction. The sum of 0x2006e3 and 0x8ed is 0x200fd0, which is the address of the target thread local storage variable storing ti_offset (offset) information in the GOT table. Among them, 0x2006e3 is the first offset value mentioned above, and "0x2006e3" is the above address.

[0117] Furthermore, the relocation table of the R_X86_64_DTPMOD64 type is searched to see whether the sum of the first offset value and the address (0x200fd0) exists. If the offset field value (0x200fd0) is consistent with the value of a TLS variable in the relocation table (0x200fd0 of t_flg), it can be determined that the above variable identifier is t_flg and the above starting position is 0x8e5.

[0118] As an optional solution, the above-mentioned searching whether there is target relocation information with the above-mentioned variable identifier in the executable file, and determining that the access mode of the above-mentioned target thread-local storage variable is the local executable mode if the above-mentioned target relocation information is not found, includes: obtaining symbol information of the above-mentioned executable file; if the above-mentioned symbol information is of a preset type, determining that the above-mentioned executable file includes the above-mentioned target thread-local storage variable; searching whether there is the above-mentioned target relocation information with the above-mentioned variable identifier in the above-mentioned executable file; if the above-mentioned target relocation information is not found, determining that the access mode of the above-mentioned target thread-local storage variable is the above-mentioned local executable mode.

[0119] Optionally, in an embodiment of the present application, the above-mentioned symbolic information refers to the names, addresses and other related information of identifiers such as functions and variables stored in the executable file.

[0120] For example, Figure 12 is a schematic diagram of another optional data processing method according to an embodiment of the present application, such as Figure 12 As shown, assuming that there is an executable file, first obtain the symbol information corresponding to the executable file to determine whether it contains the target thread local storage variable. Assuming that a symbol named t_flg is found, which is the STT_TLS preset type, it can be determined that the executable file contains the target thread local storage variable.

[0121] Furthermore, it is checked whether there is target relocation information with the t_flg variable identifier in the executable file. If so, it can be determined that the access mode of the target thread-local storage variable is the relocation mode. If the target relocation information is not found, it can be determined that the access mode of the target thread-local storage variable is the local executable mode. That is, by searching the symbol information, relocation information and preset type, it is possible to determine the access mode of the above-mentioned target thread-local storage variable and whether the target thread-local storage variable is included in the executable file.

[0122] As an optional solution, when the access mode of the target thread-local storage variable is the local executable mode, determining, in the executable file, a thread-local storage variable with the same name and the variable identifier, and a target offset of the thread-local storage variable with the same name, according to the variable identifier, includes: when the access mode of the target thread-local storage variable is the local executable mode, determining, in the executable file, a thread-local storage variable with the same name and the variable identifier, according to the variable identifier; obtaining a second offset of the thread-local storage variable with the same name in the thread-local storage space and an alignment size of the thread-local storage space; and determining the target offset based on the second offset and the alignment size.

[0123] As an optional solution, determining the target offset based on the second offset and the alignment size includes: determining a third offset corresponding to the last thread-local storage variable in the thread-local storage space; determining the sum of the third offset and the alignment size as a pointer offset; and determining the difference between the second offset and the pointer offset as the target offset.

[0124] Optionally, in an embodiment of the present application, the second offset refers to the offset position of the thread-local storage variable with the same name in the thread-local storage space, which can be understood as the offset of the thread-local storage variable with the same name relative to the starting position of the thread-local storage space; the third offset refers to the offset position of the last thread-local storage variable in the thread-local storage space, which can be understood as the offset of the last thread-local storage variable relative to the starting position of the thread-local storage space.

[0125] Optionally, in an embodiment of the present application, the alignment size of the thread-local storage space can be understood as that the starting address of the data in the thread-local storage space needs to be aligned according to a certain byte alignment rule. The alignment size may include but is not limited to the byte size of the largest data type in the storage space to ensure that the data in the storage space can be stored according to the correct byte alignment rule, thereby achieving the purpose of improving the efficiency of memory access and reducing memory access time.

[0126] In an exemplary embodiment, assuming that there is a target thread-local storage variable with a variable identifier of "myVar", in the local executable mode of the executable file, it is necessary to determine the thread-local storage variable with the same variable identifier. First, the symbol table of the executable file is searched for the variable name "myVar" to find the corresponding thread-local storage variable with the same name. Assume that the address of the thread-local storage variable with the same name corresponding to "myVar" is 0x1000, the alignment size is 8, the second offset is 100, and the third offset corresponding to the last thread-local storage variable in the thread-local storage space is 200.

[0127] Furthermore, the pointer offset is calculated as 200 (third offset) + 8 (alignment size) = 208, and the target offset is obtained as 100 (second offset) - 208 (pointer offset) = -108.

[0128] As an optional solution, the above-mentioned modifying the assembly code corresponding to the above-mentioned thread-local storage variable with the same name according to the above-mentioned target offset to obtain the target assembly code includes: obtaining the assembly code corresponding to the above-mentioned thread-local storage variable with the same name, wherein the assembly code corresponding to the above-mentioned thread-local storage variable with the same name includes at least 4 bytes; and modifying the last 4 bytes of the assembly code corresponding to the above-mentioned thread-local storage variable with the same name according to the above-mentioned target offset to obtain the above-mentioned target assembly code.

[0129] In an exemplary embodiment, assuming that the assembly code corresponding to the thread-local storage variable with the same name is "64 488b 04 25 00 00 00 00 48 8d 80ff ff ff ff", and the target offset is "f8 ff ff ff", the last four bytes of the assembly code are replaced by the target offset to generate the target assembly code, which is expressed as "64 48 8b 0425 00 00 00 00 48 8d 80f8 ff ff ff". Specifically, the first 9 bytes "64 48 8b 04 25 00 00 0000" indicate that the address of the TCB pointer is obtained by using the fs register, and the next 6 bytes "48 8d 80f8 ff ff ff" represent the offset value represented according to the little-endian two's complement, and the address of the specific TLS variable is obtained by adding the offset value to the address of the TCB pointer.

[0130] For example, if there is a TLS variable with an offset value of 4 relative to the TCB pointer, the last four bytes can be modified to obtain the target assembly code represented as "64 48 8b 04 25 00 00 0000 48 8d 80 04 00 0000".

[0131] Exemplarily, the data processing method proposed in this application can be applied to the process of hot patch loading implementation. Specifically, the relocation addressing method of the TLS (thread local storage) thread variable in the GD mode (conventional dynamic mode) in the dynamic link library is defined in the LE mode (local executable mode) in the executable file, thereby removing the dependency on the relocation of the TLS variable in the patch function, so that the function patch using the TLS variable is successfully loaded.

[0132] In an exemplary embodiment, hot patching technology is used to implement the device without restarting. During process operation, instructions of the defective function are replaced by instructions of the defective function to repair the defective function. Here, the defective function refers to a function with erroneous logic running in the process. The defect repair function can also be understood as a patch function, which means a function that repairs the erroneous logic and implements normal functions. First, the terms appearing in the embodiments of this application are explained:

[0133] General Dynamic (GD) mode: TLS variables (the target thread-local storage variables mentioned above) require a separate memory space for each thread. Different threads access different TLS variables in different memory spaces. The most common way to access TLS variables is in General Dynamic (GD) mode. This mode passes two parameters, the module ID and the TLS block offset, determined during the dynamic linker's relocation, to the __tls_get_addr function. The __tls_get_addr function calculates the access address of the corresponding TLS variable in the current thread. The most common application of GD mode is the use of TLS variables by functions in dynamic link libraries.

[0134] It should be noted that since LE mode does not require relocation, while GD mode addressing relies on the module ID and TLS block offset used for relocation, TLS variables in GD mode cannot be relocated and addressed in LE mode. For example, the TLS variable t_flg in GD mode cannot be relocated and addressed in LE mode. This means that if the TLS variable t_flg is used in the patch function func_a, and if func_a is compiled as a dynamic link library, the patch function func_a in the dynamic link library uses GD mode to address the TLS variable t_flg, and t_flg is defined in the executable file, and the executable file is compiled in a statically linked manner to address t_flg in LE mode, resulting in t_flg having no relocation information. In other words, in the related art, there is a technical problem that the TLS variable t_flg used in the patch function func_a using GD mode addressing cannot be relocated and addressed because t_flg is defined in the executable file in LE mode and has no relocation information, resulting in patch loading failure.

[0135] Specifically, embodiments of the present application may include but are not limited to:

[0136] S1, determine the method of using TLS variable names for functions in the dynamic link library:

[0137] Traverse the code segment and follow the matching conditions: bytes 0 to 1 are 0x66 0x48, bytes 8 to 10 are 0x66 0x66 0x48, and bytes 4 to 7 are the offset values ​​relative to rip in little endian order. After adding the rip value, determine whether it is within the range of the GOT table. If it is within the range of the GOT table, then take its value and search it in the relocation table of type R_X86_64_DTPMOD64. If the Offset field value is consistent, the variable name information of the TLS variable and the location of the binary assembly code that needs to be obtained in the current code segment can be matched.

[0138] In an exemplary embodiment, taking an X86-64-bit CPU (central processing unit) as an example, the function __tls_get_addr is called with a pointer parameter pointing to an object of type tls_index, and the access address of the corresponding TLS variable in the current thread can be calculated:

[0139] extern void*__tls_get_addr(tls_index*ti);

[0140] The tls_index type is defined as follows:

[0141]

[0142] Indicates that when the linker is linking, the two members ti_module and ti_offset of the tls_index structure allocated to each TLS variable are stored in the GOT table (Global Offset Table), where the member ti_module is associated with the relocation type R_X86_64_DTPMOD64 of the TLS variable, and the member ti_offset is associated with the relocation type R_X86_64_DTPOFF64 of the TLS variable.

[0143] S2: Determine the access method for TLS variables in Local Executable (LE) mode, which may include but is not limited to:

[0144] By strictly limiting the definition and usage scenarios of TLS variables, for example, the use of TLS variables defined in executable files by functions compiled in static linking mode is optimized to Local Executable mode (LE). This mode can only use TLS variables defined in executable files. The linker can calculate the relative offset of each TLS variable relative to the Thread Control Block (TCB) pointer. When addressing, it directly queries the Thread Control Block (TCB) pointer and adds this offset value to determine the address of the TLS variable for access without relocation.

[0145] In an exemplary embodiment, taking the X86-64 bit CPU compilation product as an example, the information of each TLS variable defined in the executable file can be seen through "readelf -s executable file (such as process_a)", such as Figure 7As shown, the value of the Type item in the fourth column is TLS, indicating that the variable is a TLS variable. The value of the Name item in the eighth column is the TLS variable name. The value of the Size item in the third column is the length of the TLS variable in bytes. The value of the Value item in the second column is the offset of each TLS variable in the thread-local storage space. For example, the offset of the TLS variable t_flg2 in the thread-local storage space is 4, and the length is 4.

[0146] For example, in an X86-64-bit CPU, the fs register (a special-purpose register used to store the address of a thread control block (TCB) pointer) can be used to store the address of a TCB pointer. To access a TLS variable, first obtain the value of the fs register to obtain the address of the TCB pointer, then obtain the offset of the TLS variable in the thread-local storage space and the offset of the TCB pointer, calculate the offset difference, and add the value of the TCB pointer to this offset difference to obtain the address of the TLS variable, thereby accessing the corresponding content of the TLS variable.

[0147] The 16-byte binary assembly code compiled to access the TLS variable t_flg2 is as follows:

[0148] 400ce2: 64 48 8b 04 25 00 00 00 00mov%fs: 0x0, %rax;

[0149] 400ceb: 48 8d 80f8 ff ff ff lea-0x8(%rax),%rax;

[0150] The first line of instruction 64 48 8b 04 25 00 00 00 00 indicates that the TCB pointer address stored in the fs register is obtained and stored in the rax register. The offset of the t_flg2 variable in the thread-local storage space is 4. The offset of the last TLS variable t_flg in the thread-local storage space of the entire executable file is 8, and the length is 4. The TLS variable is aligned to 4 bytes, so the offset of the TCB pointer is 8 + 4 = 12.

[0151] Furthermore, we can calculate that the offset from the t_flg2 variable to the TCB pointer is 4-12=-8. The instruction 48 8d 80f8 ff ff ff in the second line of the assembly code subtracts 8 from the TCB pointer address stored in the rax register (the last four bytes of the instruction f8 ff ff ff represent the value of -8 represented by the two's complement), and then stores it back in the rax register to obtain the address of the t_flg2 variable, which can be used to access the t_flg2 variable.

[0152] S3, determining whether the executable file uses TLS variables in LE mode, which may include but is not limited to:

[0153] First, parse the executable file's symbol information according to the ELF format. If the symbol type is STT_TLS, it indicates that the symbol is a TLS variable. Search the relocation table corresponding to the executable file according to the symbolic name of the TLS variable. If there is no relocation information with the same name, it means that the LE mode in the executable file uses the TLS variable.

[0154] For another example, use "readelf -r executable file name" to view the relocation information. For example, after confirming that t_InSoflg is the TLS variable of the executable file process_a, enter "readelf -rprocess_a" and search for the TLS variable in the output relocation information. No information with the same name is found, indicating that the TLS variable t_InSoflg is used in LE mode.

[0155] S4. Since the length of the binary assembly code compiled for accessing TLS variables in GD mode and LE mode is the same as 16 bytes, the TLS variables in the dynamic link library can be switched from GD mode to LE mode, including but not limited to:

[0156] S4-1, according to S2 "the method of determining the TLS variable name used by the function in the dynamic link library", obtain the variable name and the starting position of the binary assembly code;

[0157] S4-2, judging whether the TLS variable in the executable file uses the LE mode according to S3 "a method for determining whether the variable name uses the LE mode for the TLS variable in the executable file";

[0158] S4-3, if the TLS variable does not use LE mode in the executable file, it means that there is relocation information in the dynamic link library and there is no need to switch to LE mode;

[0159] S4-4, if the mode is LE, then search for a TLS variable with the same name in the executable file in the ELF file format according to the variable name (for example, using the "readelf -s executable file name method" instruction to obtain it), and determine the offset of the TLS variable in the thread local storage space;

[0160] S4-5, determine the offset of the TCB pointer based on the offset and length of the last TLS variable and the number of aligned bytes;

[0161] S4-6, subtract the offset of the TCB pointer from the offset of the TLS variable to get the target offset of the TLS variable relative to the TCB pointer. This target offset value replaces the last four bytes of the binary assembly code 64 48 8b 04 25 00 0000 00 48 8d 80f8 ff ff ff (the last four bytes f8 ff ff ff are the offset value) for accessing the TLS variable in LE mode to generate the corresponding binary assembly code in LE mode for the TLS variable.

[0162] S4-7, replace the starting position of the binary assembly code obtained from the 16-byte LE mode assembly code of "Method for determining the TLS variable name used by the function in the dynamic link library" to achieve the purpose of changing the TLS variable used in the GD mode in the dynamic library to the TLS variable used in the LE mode.

[0163] For example, according to the “Method for Determining the TLS Variable Name Used by a Function in a Dynamic Link Library”, the 16 bytes (66 48 8d 3d e3 0620 00 66 66 48e8 bb feff ff) starting from the code segment 0x8e5 in the dynamic link library libtest.so are the TLS variable t_flg used in the GD mode. According to the variable name t_flg, the “Method for Determining Whether a TLS Variable in an Executable File Uses LE Mode” is used to determine that the variable t_flg uses the LE mode in the executable file. The variable name t_flg is determined in the ELF file format executable file (process_a) to have an offset of 8 in the thread local storage space. Furthermore, the offset of the last TLS variable t_flg in the thread local storage space in the entire executable file is 8, and the length is 4. It is determined that the TLS variable is aligned to 4 bytes. Therefore, the offset of the TCB pointer is 8+4=12.

[0164] Furthermore, the offset 8 of the TLS variable t_flg minus the offset 12 of the TCB pointer can be obtained as the target offset value of the TLS variable t_flg relative to the TCB pointer, which is 8-12=-4. The hexadecimal complement is fc ff ff ff. This target offset value is used to replace the last four bytes of the binary assembly code 64 48 8b 04 25 00 00 00 00 48 8d 80f8ff ff ff for LE mode TLS variable access (the last four bytes f8 ff ff ff are the offset value), and the binary assembly code 64 48 8b 04 25 00 00 00 00 48 8d 80fc ff ff used in LE mode of the TLS variable t_flg is generated. ff, replace the 16-byte assembly code of the t_flg variable used in LE mode starting from the code segment 0x8e5 in libtest.so, and then the t_flg variable used in GD mode in the dynamic link library libtest.so can be modified to the t_flg variable used in LE mode.

[0165] In an exemplary embodiment, the steps of creating a patch file using the data processing method proposed in this application may include but are not limited to:

[0166] S1. A patch function (a function that repairs a defect) is compiled into a dynamic link library in a manner of a dynamic link library with the same name as the patched function (the defective function).

[0167] S2, according to the above S4 "the method of switching TLS variables in dynamic link libraries from GD mode to LE mode", switch the TLS variables used in the code segments of the functions in the dynamic link library from GD mode to LE mode;

[0168] S3: Switch the TLS variables in the dynamic link library from GD mode to LE mode. Change the R_X86_64_DTPMOD64 and R_X86_64_DTPOFF64 types in the relocation information to R_X86_64_RELATIVE types to indicate to the operating system that the TLS variables do not need to be relocated. Otherwise, the operating system will still search according to the relocation type, causing the dynamic link library to fail to load.

[0169] For example, after modifying the TLS variable t_InSoflg in libhotpatchtest.so (dynamic link library) from GD mode to LE mode, the relocation information is obtained through the instruction "readelf -r libhotpatchtest.so". In the relocation information, the type of t_InSoflg is still R_X86_64_DTPMOD64 and R_X86_64_DTPOFF64. After dynamically loading the libhotpatchtest.so, the operating system still searches for the t_InSoflg variable according to the relocation type, resulting in loading failure. Therefore, the relocation type in t_InSoflg is modified to R_X86_64_RELATIVE type, so that the operating system will not relocate t_InSoflg, and then successfully load the dynamic link library libhotpatchtest.so. The modified relocation information of the dynamic link library is as follows: Figure 9 shown.

[0170] Optionally, in the embodiments of the present application, the following may be included but not limited to:

[0171] S1. The patch function is compiled into a dynamic link library in the form of a dynamic link library with the same name as the patched function. The code segment of the patch file in the form of a dynamic link library is traversed in the ELF format. According to the matching conditions: the 0th to 1st bytes are 0x66 0x48, the 8th to 10th bytes are 0x66 0x66 0x48, and the 4th to 7th bytes are the little endian rip offset value plus the rip value is within the range of the GOT table. The value is searched in the relocation table of type R_X86_64_DTPMOD64. If the Offset field value is consistent, the variable name of the TLS variable to be obtained in the current code segment and the location of the binary assembly code can be matched. According to the variable name, the symbol information is searched in the ELF format executable file to see if it is STT_TLS. If so, the relocation information is searched to see if there is a variable with the same name. Otherwise, it means that the variable is used in LE mode in the executable file, and the TLS variable needs to be switched from GD mode to LE mode in the dynamic link state library.

[0172] S2, according to the TLS variable name that needs to be switched, search for the TLS variable with the same name in the executable file in the ELF file format, obtain the offset of the TLS variable in the thread local storage space, determine the offset of the TCB pointer according to the offset and length of the last TLS variable in the executable file and the number of aligned bytes, subtract the offset of the TCB pointer from the offset of the TLS variable to obtain the offset of the TLS variable relative to the TCB pointer, and replace the last four bytes of the binary assembly code 64 48 8b0425 00 00 00 00 48 8d 80f8 ff ff ff for accessing the TLS variable in LE mode with this value, generate the corresponding LE mode binary assembly code of the TLS variable, replace the 16-byte LE mode assembly code from the starting position of the GD mode binary assembly code, and complete the switching of the TLS variable from GD mode to LE mode in the dynamic link state library;

[0173] S3, when the GD mode in the dynamic link library is successfully switched to the LE mode TLS variable, the relocation type of the TLS variable in the relocation information is changed from R_X86_64_DTPMOD64 and R_X86_64_DTPOFF64 to R_X86_64_RELATIVE, completing the patch file production. Finally, the patch file is dynamically loaded by the patched process in a dynamic loading manner, and the patch function information implemented in the patch file is read. According to the function name, a function with the same name is searched among all functions used by the patched process. If a function is found, it is the function that needs to be patched. The assembly instruction at the function address entry of the patched function in the patched process is modified, and the assembly instruction content is modified to jump to the address of the function with the same name implemented in the patch dynamic link library, thereby implementing the relocation addressing method of the TLS thread variable in the GD mode in the dynamic link library to the TLS variable in the LE mode defined in the executable file.

[0174] It is understandable that in the specific implementation of this application, related data such as user information is involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards of relevant countries and regions.

[0175] It should be noted that for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that this application is not limited by the order of the actions described, because according to this application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by this application.

[0176] According to another aspect of the embodiment of the present application, a data processing device for implementing the above-mentioned data processing method is also provided. Figure 13 As shown, the device includes:

[0177] a determination module 1302 for determining, when a target process needs to load a dynamic link library, a variable identifier corresponding to a target thread-local storage variable that the patch function needs to access and a starting position of the corresponding assembly code based on a code snippet associated with the patch function, wherein the dynamic link library includes the patch function;

[0178] A search module 1304 is configured to search the executable file for target relocation information with a variable identifier, and if no target relocation information is found, determine that the access mode of the target thread-local storage variable is a local executable mode;

[0179] An execution module 1306 is configured to determine, in the executable file, a thread-local storage variable with the same name as the variable identifier and a target offset of the thread-local storage variable with the same name according to the variable identifier, when the access mode of the target thread-local storage variable is the local executable mode;

[0180] A modification module 1308 is configured to modify the assembly code corresponding to the thread-local storage variable with the same name according to the target offset to obtain the target assembly code;

[0181] The replacement module 1310 is configured to replace the initial assembly code corresponding to the starting position with the target assembly code, modify the relocation type of the target thread local storage variable to prohibit relocation, and update and load the dynamic link library.

[0182] As an optional solution, the device is used to determine the variable identifier corresponding to the target thread-local storage variable that the patch function needs to access and the starting position of the corresponding assembly code based on the code snippet associated with the patch function in the following manner: traverse the memory corresponding to the dynamic link library and search for the code snippet, wherein the first part of the bytes of the code snippet is in a preset format and the code snippet includes the first part of the bytes; determine the variable identifier and the starting position based on the relocation table corresponding to the code snippet and the dynamic link library.

[0183] As an optional solution, the device is used to determine the variable identifier and starting position based on the relocation table corresponding to the code fragment and the dynamic link library in the following manner, including: determining a first offset value between the code fragment and the register based on the second part of bytes, wherein the code fragment includes the second part of bytes; obtaining the address of the next operation instruction of the register; and determining the variable identifier and starting position in the relocation table based on the sum of the first offset value and the address.

[0184] As an optional solution, the device is used to search for target relocation information with a variable identifier in the executable file in the following manner, and if the target relocation information is not found, determine that the access mode of the target thread local storage variable is the local executable mode: obtain symbol information of the executable file; if the symbol information is of a preset type, determine that the executable file includes the target thread local storage variable; search for target relocation information with a variable identifier in the executable file; if the target relocation information is not found, determine that the access mode of the target thread local storage variable is the local executable mode.

[0185] As an optional solution, the apparatus is configured to determine, in a case where the access mode of a target thread-local storage variable is a local executable mode, a thread-local storage variable with the same name and a target offset of the thread-local storage variable with the same name based on the variable identifier in an executable file in the following manner: in a case where the access mode of the target thread-local storage variable is a local executable mode, determining, in the executable file, a thread-local storage variable with the same name and the variable identifier based on the variable identifier; obtaining a second offset of the thread-local storage variable with the same name in a thread-local storage space and an alignment size of the thread-local storage space; and determining a target offset based on the second offset and the alignment size.

[0186] As an optional solution, the device is used to determine the target offset based on the second offset and the alignment size in the following manner: determining a third offset corresponding to the last thread local storage variable in the thread local storage space; determining the sum of the third offset and the alignment size as the pointer offset; and determining the difference between the second offset and the pointer offset as the target offset.

[0187] As an optional solution, the device is used to modify the assembly code corresponding to the thread-local storage variable with the same name according to the target offset to obtain the target assembly code: obtain the assembly code corresponding to the thread-local storage variable with the same name, wherein the assembly code corresponding to the thread-local storage variable with the same name includes at least 4 bytes; modify the last 4 bytes of the assembly code corresponding to the thread-local storage variable with the same name according to the target offset to obtain the target assembly code.

[0188] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program that has a predetermined function and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories) or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be part of an overall module or unit that includes the function of the module or unit.

[0189] Regarding the apparatus in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0190] According to one aspect of the present application, a computer program product is provided, which includes a computer program.

[0191] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0192] Figure 14 The block diagram schematically shows a computer system structure of an electronic device used to implement an embodiment of the present application.

[0193] It should be noted that Figure 14 The computer system 1400 of the electronic device shown is only an example and should not limit the functions and scope of use of the embodiments of the present application.

[0194] like Figure 14 As shown, the computer system 1400 includes a central processing unit 1401 (CPU), which can perform various appropriate actions and processes according to the program stored in the read-only memory 1402 (ROM) or the program loaded from the storage part 1408 into the random access memory 1403 (RAM). Various programs and data required for system operation are also stored in the random access memory 1403. The central processing unit 1401, the read-only memory 1402 and the random access memory 1403 are connected to each other via a bus 1404. An input / output interface 1405 (i.e., an I / O interface) is also connected to the bus 1404.

[0195] The following components are connected to the input / output interface 1405: an input section 1406 including a keyboard, a mouse, and the like; an output section 1407 including devices such as a cathode ray tube (CRT), a liquid crystal display (LCD), and a speaker; a storage section 1408 including a hard disk; and a communication section 1409 including a network interface card such as a local area network card or a modem. The communication section 1409 performs communication processing via a network such as the Internet. A drive 1410 is also connected to the input / output interface 1405 as needed. Removable media 1411, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is installed in the drive 1410 as needed, so that computer programs read therefrom can be installed into the storage section 1408 as needed.

[0196] In particular, according to an embodiment of the present application, the processes described in the various method flow charts can be implemented as computer software programs. For example, an embodiment of the present application includes a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for executing the methods shown in the flow charts. In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 1409 and / or installed from a removable medium 1411. When the computer program is executed by the central processing unit 1401, the various functions defined in the system of the present application are performed.

[0197] In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 1409 and / or installed from the removable medium 1411. When the computer program is executed by the central processing unit 1401, various functions provided by the embodiments of the present application are performed.

[0198] According to another aspect of the embodiment of the present application, an electronic device for implementing the above data processing method is also provided. The electronic device may be Figure 1 The terminal device or server shown in FIG. This embodiment is described by taking the electronic device as a terminal device as an example. Figure 13 As shown, the electronic device includes a memory 1302 and a processor 1304. The memory 1302 stores a computer program, and the processor 1304 is configured to execute the steps in any of the above method embodiments through the computer program.

[0199] Optionally, in this embodiment, the electronic device may be located in at least one network device among a plurality of network devices of a computer network.

[0200] Optionally, in this embodiment, the above-mentioned processor can be configured to execute the methods in each embodiment of the present application through a computer program.

[0201] Alternatively, those skilled in the art will appreciate that Figure 15 The structure shown is for illustration only. Figure 15 It does not limit the structure of the above electronic device. For example, the electronic device may also include Figure 15 More or fewer components (such as network interfaces, etc.) as shown in, or with Figure 15 Different configurations shown.

[0202] Among them, the memory 1502 can be used to store software programs and modules, such as the program instructions / modules corresponding to the data processing method and device in the embodiments of the present application. The processor 1504 executes various functional applications and data processing by running the software programs and modules stored in the memory 1502, that is, realizes the above-mentioned data processing method. The memory 1502 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 1502 may further include a memory remotely located relative to the processor 1504, and these remote memories may be connected to the terminal via a network. Examples of the above-mentioned networks include but are not limited to the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. Among them, the memory 1502 can be used to store, but is not limited to, dynamic link libraries, executable files and other information. As an example, if Figure 15 As shown, the memory 1502 may include, but is not limited to, the determination module 1302, search module 1304, execution module 1306, modification module 1308, and replacement module 1310 in the data processing device. In addition, it may also include, but is not limited to, other module units in the data processing device, which will not be repeated in this example.

[0203] Optionally, the transmission device 1506 is used to receive or send data via a network. Specific examples of the network may include a wired network and a wireless network. In one embodiment, the transmission device 1506 includes a network interface controller (NIC), which can be connected to other network devices and a router via a network cable to communicate with the Internet or a local area network. In one embodiment, the transmission device 1506 is a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0204] In addition, the electronic device further includes: a display 1508 for displaying the dynamic link library and executable files; and a connection bus 1510 for connecting various module components in the electronic device.

[0205] In other embodiments, the terminal device or server may be a node in a distributed system, wherein the distributed system may be a blockchain system, and the blockchain system may be a distributed system formed by connecting multiple nodes via network communication. The nodes may form a peer-to-peer network, and any computing device, such as a server, terminal, or other electronic device, may become a node in the blockchain system by joining the peer-to-peer network.

[0206] According to one aspect of the present application, a computer-readable storage medium is provided, and a processor of an electronic device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the electronic device executes the data processing method provided in various optional implementations of the above-mentioned data processing.

[0207] Optionally, in this embodiment, the above-mentioned computer-readable storage medium can be configured to store data for executing the methods in various embodiments of the present application.

[0208] Optionally, in this embodiment, a person of ordinary skill in the art may understand that all or part of the steps in the various methods of the above embodiments may be completed by instructing the hardware related to the terminal device through a program, and the program may be stored in a computer-readable storage medium, which may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0209] The serial numbers of the above embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0210] If the integrated units in the above embodiments are implemented in the form of software functional units and sold or used as independent products, they can be stored in the above-mentioned computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a number of instructions for causing one or more electronic devices to execute all or part of the steps of the method described in each embodiment of the present application.

[0211] In the above embodiments of the present application, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0212] In the several embodiments provided in this application, it should be understood that the disclosed applications can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0213] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0214] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0215] The above is only a preferred embodiment of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A data processing method, characterized in that: include: In a case where the target process needs to load a dynamic link library, determining, based on a code snippet associated with a patch function, a variable identifier corresponding to a target thread local storage variable that the patch function needs to access and a starting position of the corresponding assembly code, wherein the dynamic link library includes the patch function; Searching for target relocation information with the variable identifier in the executable file, and if the target relocation information is not found, determining that the access mode of the target thread-local storage variable is a local executable mode; When the access mode of the target thread-local storage variable is the local executable mode, determining, in the executable file according to the variable identifier, a thread-local storage variable with the same name as the variable identifier and a target offset of the thread-local storage variable with the same name; Modify the assembly code corresponding to the thread local storage variable with the same name according to the target offset to obtain the target assembly code; The target assembly code is used to replace the initial assembly code corresponding to the starting position, and the relocation type of the target thread local storage variable is modified to prohibit relocation, and the dynamic link library is updated and loaded; The method further includes: when the access mode of the target thread-local storage variable is the local executable mode, determining, in the executable file, a thread-local storage variable with the same name and the variable identifier according to the variable identifier; obtaining a second offset of the thread-local storage variable with the same name in the thread-local storage space and an alignment size of the thread-local storage space; determining a third offset corresponding to the last thread-local storage variable in the thread-local storage space; determining a sum of the third offset and the alignment size as a pointer offset; determining a difference between the second offset and the pointer offset as the target offset; obtaining assembly code corresponding to the thread-local storage variable with the same name, wherein the assembly code corresponding to the thread-local storage variable with the same name includes at least 4 bytes; and modifying the last 4 bytes of the assembly code corresponding to the thread-local storage variable with the same name according to the target offset to obtain the target assembly code, including: replacing the last 4 bytes with the value of the target offset to obtain the target assembly code.

2. The method according to claim 1, characterized in that The step of determining, based on the code snippet associated with the patch function, a variable identifier corresponding to a target thread local storage variable that the patch function needs to access and a starting position of the corresponding assembly code includes: Traversing the memory corresponding to the dynamic link library to search for the code snippet, wherein a first portion of bytes of the code snippet is in a preset format, and the code snippet includes the first portion of bytes; The variable identifier and the starting position are determined based on the relocation table corresponding to the code fragment and the dynamic link library.

3. The method according to claim 2, characterized in that The determining the variable identifier and the starting position based on the relocation table corresponding to the code fragment and the dynamic link library includes: Determine a first offset value from the register according to a second portion of bytes of the code snippet, wherein the code snippet includes the second portion of bytes; Obtaining the address of the next operation instruction of the register; The variable identifier and the starting position are determined in the relocation table according to the sum of the first offset value and the address.

4. The method according to claim 1, wherein The searching for target relocation information with the variable identifier in the executable file, and determining that the access mode of the target thread-local storage variable is a local executable mode if the target relocation information is not found, includes: Obtaining symbolic information of the executable file; In a case where the symbol information is of a preset type, determining that the executable file includes the target thread local storage variable; Searching the executable file for the target relocation information having the variable identifier; If the target relocation information is not found, it is determined that the access mode of the target thread local storage variable is the local executable mode.

5. A data processing device, characterized in that: include: a determination module configured to determine, when a target process needs to load a dynamic link library, a variable identifier corresponding to a target thread-local storage variable that the patch function needs to access and a starting position of the corresponding assembly code based on a code snippet associated with the patch function, wherein the dynamic link library includes the patch function; a search module, configured to search for target relocation information having the variable identifier in the executable file, and determine that the access mode of the target thread-local storage variable is a local executable mode if the target relocation information is not found; an execution module, configured to determine, in the executable file, a thread-local storage variable with the same name as the variable identifier and a target offset of the thread-local storage variable with the same name according to the variable identifier, when the access mode of the target thread-local storage variable is the local executable mode; A modification module, configured to modify the assembly code corresponding to the thread-local storage variable with the same name according to the target offset to obtain a target assembly code; a replacement module, configured to replace the initial assembly code corresponding to the starting position with the target assembly code, modify the relocation type of the target thread local storage variable to prohibit relocation, and update and load the dynamic link library; The apparatus is further configured to: determine, in the executable file, a thread-local storage variable with the same name and the variable identifier according to the variable identifier, when the access mode of the target thread-local storage variable is the local executable mode; obtain a second offset of the thread-local storage variable with the same name in the thread-local storage space and an alignment size of the thread-local storage space; determine a third offset corresponding to the last thread-local storage variable in the thread-local storage space; determine a sum of the third offset and the alignment size as a pointer offset; determine a difference between the second offset and the pointer offset as the target offset; obtain assembly code corresponding to the thread-local storage variable with the same name, wherein the assembly code corresponding to the thread-local storage variable with the same name includes at least 4 bytes; and modify the last 4 bytes of the assembly code corresponding to the thread-local storage variable with the same name according to the target offset to obtain the target assembly code, including: replacing the last 4 bytes with the value of the target offset to obtain the target assembly code.

6. A computer-readable storage medium, characterized in that The computer-readable storage medium includes a stored computer program, wherein the computer program can be executed by an electronic device to perform the method according to any one of claims 1 to 4.

7. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 4 are implemented.

8. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to execute the method according to any one of claims 1 to 4 through the computer program.

Images