Hot patch loading method and device, electronic equipment and storage medium

Abstract

The invention relates to the technical field of computers, in particular to a hotfix loading method and device, electronic equipment and a storage medium so as to determine the offset of a TLS variable. Comprising the steps of compiling a patch function into a dynamic link library; obtaining a target offset of a thread local storage TLS variable in the patch function from the static link executable file, and obtaining relocation information of the TLS variable from the dynamic link library; after the patch file containing the patch function is dynamically loaded, a target memory address in the dynamic link library is determined based on the relocation information, and the target offset is stored in the target memory address; and when the to-be-repaired process is loaded to the to-be-repaired function, skipping to the patch function, and when the patch function is loaded, obtaining the target offset from the target memory address, and accessing the TLS variable of the patch function according to the target offset.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, in particular to a hot patch loading method and device, electronic equipment and storage medium. BACKGROUND

[0002] With the development of computer technology and the increase of software functions, defects inevitably exist in software, and therefore, the software with defects needs to be repaired. In the related art, under the premise that the device does not restart, the instructions of a patch function are replaced with the instructions of a function to be repaired through instruction replacement when the process runs, so as to realize the repair of the defective function.

[0003] In the process of loading the patch function, a Thread Local Storage (TLS) variable needs to be accessed to complete the loading of the patch function. However, due to the difference of the library to which the patch function is linked and the difference of the executable file of the process to be repaired, the state of the offset of the TLS variable is different. When the patch function is compiled into a dynamic link library and the executable file of the process to be repaired is dynamically linked, the offset of the TLS variable can be determined through relocation when the dynamic link library is loaded. When the patch function is compiled into a static link library and the executable file of the process to be repaired is statically linked, the offset of the TLS variable can be directly read from the executable file. Therefore, in the case that the patch function is compiled into a dynamic link library and the executable file of the process to be repaired is statically linked, the operating system will still perform relocation due to the existence of the dynamic link library, but the executable file is statically linked, and the relocation information required for relocation cannot be found, so that the relocation cannot be performed, the offset of the TLS variable cannot be obtained, and further, the address of the TLS variable cannot be determined, and the loading of the patch function fails.

[0004] In summary, when facing the executable file compiled without adding the -rdynamic compilation option and the patch function compiled into a dynamic link library, how to determine the offset of the TLS variable and realize the loading of the patch function is an urgent problem to be solved. SUMMARY

[0005] The embodiments of the present application provide a hot patch loading method and device, electronic equipment and storage medium, to determine the offset of the TLS variable and realize the loading of the patch function when facing the executable file compiled without adding the -rdynamic compilation option and the patch function compiled into a dynamic link library.

[0006] The embodiments of the present application provide a hot patch loading method, which comprises:

[0007] compiling a patch function into a dynamic link library; the patch function is used for repairing a statically linked executable file of a process to be repaired;

[0008] The obtaining unit is configured to obtain a target offset of a thread local storage (TLS) variable in the patch function from the statically linked executable file, and obtain relocation information of the TLS variable from the dynamic link library;

[0009] The determining unit is configured to determine a target memory address in the dynamic link library based on the relocation information after dynamically loading a patch file containing the patch function, and store the target offset into the target memory address;

[0010] The jumping unit is configured to jump to the patch function when the process to be repaired is loaded to the function to be repaired, and access the TLS variable of the patch function according to the target offset after obtaining the target offset from the target memory address when the patch function is loaded, so as to complete loading of the patch function.

[0011] The embodiment of the application provides a hot patch loading device, and the device comprises:

[0012] The compiling unit is configured to compile a patch function into a dynamic link library; the patch function is used for repairing a statically linked executable file of a process to be repaired;

[0013] The obtaining unit is configured to obtain a target offset of a thread local storage (TLS) variable in the patch function from the statically linked executable file, and obtain relocation information of the TLS variable from the dynamic link library;

[0014] The determining unit is configured to determine a target memory address in the dynamic link library based on the relocation information after dynamically loading a patch file containing the patch function, and store the target offset into the target memory address;

[0015] The jumping unit is configured to jump to the patch function when the process to be repaired is loaded to the function to be repaired, and access the TLS variable of the patch function according to the target offset after obtaining the target offset from the target memory address when the patch function is loaded, so as to complete loading of the patch function.

[0016] Optionally, the obtaining unit is specifically configured to:

[0017] According to a variable name of the TLS variable, find an initial offset of the TLS variable in a thread local storage (TLS) space according to symbol information in the statically linked executable file;

[0018] Take a sum of the initial offset and a first preset offset as the target offset; the target offset is an offset of the TLS variable relative to a thread control block (TCB) pointer.

[0019] Optionally, the jump unit is specifically configured to:

[0020] sum the TCB pointer address and the target offset as the TLS variable address;

[0021] access the TLS variable according to the TLS variable address.

[0022] Optionally, the obtaining unit is specifically configured to:

[0023] when it is determined that the relocation type of the TLS variable is a first type, obtain the relocation information of the TLS variable from the dynamic link library; the first type is a type representing that relocation is needed.

[0024] Optionally, after the obtaining unit obtains the relocation information of the TLS variable from the dynamic link library, before the determining unit dynamically loads the patch file containing the patch function, the apparatus further comprises a first modifying unit, and the first modifying unit is configured to:

[0025] modify the relocation type of the TLS variable from the first type to a second type representing that no relocation is needed.

[0026] Optionally, the determining unit is specifically configured to:

[0027] when it is determined that the relocation type of the TLS variable is the second type, determine the starting virtual memory address of the dynamic link library;

[0028] determine a target information address according to the relocation information and the starting virtual memory address, and fill a memory address of a preset function into the target information address;

[0029] determine the target memory address according to a sum of the target information address and a second preset offset.

[0030] Optionally, before the jump unit jumps to the patch function when the process to be repaired is loaded to the function to be repaired, the apparatus further comprises a second modifying unit, and the second modifying unit is specifically configured to:

[0031] if there is a target function having the same function name as the function name of the patch function in each function of the process to be repaired, the target function is taken as the function to be repaired;

[0032] modify assembly instructions at a function address entry of the function to be repaired to assembly instructions jumping to the patch function.

[0033] An electronic device provided by an embodiment of the present application includes a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, the computer program causes the processor to perform the steps of any of the hot patch loading methods described above.

[0034] A computer readable storage medium provided by an embodiment of the present application includes a computer program, and when the computer program is run on an electronic device, the computer program is configured to cause the electronic device to perform the steps of any of the hot patch loading methods described above.

[0035] A computer program product provided by an embodiment of the present application includes a computer program, and the computer program is stored in a computer readable storage medium; when a processor of an electronic device reads the computer program from the computer readable storage medium, the processor executes the computer program, so that the electronic device performs the steps of any of the hot patch loading methods described above.

[0036] The present application has the following beneficial effects:

[0037] Embodiments of the present application provide a hot patch loading method, device, electronic device and storage medium. The present application compiles a patch function into a dynamic link library; the present application considers that due to the delay binding mechanism, the patch function of the dynamic link library can be normally loaded by the statically linked executable file even if the TLS variable used by the patch function lacks relocation information in the statically linked executable file before the patch function is called, and if the patch function needs to be called, the self-relocation of the TLS variable in the dynamic link library in the statically linked executable file needs to be completed first, otherwise the function call fails. Therefore, the present application obtains the target offset of the thread local storage TLS variable in the patch function from the statically linked executable file, and obtains the relocation information of the TLS variable from the dynamic link library. After the patch file containing the patch function is dynamically loaded, the target memory address in the dynamic link library is determined based on the relocation information, and the target offset is stored in the target memory address, so as to realize the self-relocation of the TLS variable in the statically linked executable file. Further, when the to-be-repaired process is loaded to the to-be-repaired function, the patch function is jumped to, and when the patch function is loaded, the target offset is obtained from the target memory address, and the TLS variable of the patch function is accessed according to the target offset, so as to complete the loading of the patch function, thereby realizing the replacement of the to-be-repaired function and the repair of the defect problem.

[0038] Other features and advantages of the present application will be set forth in the following description, and in part will become apparent to those skilled in the art from the description, or can be learned by practice of the present application. The objects and other advantages of the present application can be realized and achieved by the structure particularly pointed out in the written description, claims, and drawings. BRIEF DESCRIPTION OF DRAWINGS

[0039] The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiments of the application and together with the description serve to explain the application. In the drawings:

[0040] Figure 1 A schematic diagram of a memory address of a TLS variable provided for an embodiment of the application;

[0041] Figure 2 An implementation flowchart of a hot patch loading method provided for an embodiment of the application;

[0042] Figure 3 A schematic diagram of a symbol table of an executable file provided for an embodiment of the application;

[0043] Figure 4 A schematic diagram of a GOT table provided for an embodiment of the application;

[0044] Figure 5 A flowchart of obtaining a target offset provided for an embodiment of the application;

[0045] Figure 6 A schematic diagram of a dynamic link library provided for an embodiment of the application;

[0046] Figure 7A A schematic diagram of a dynamic link library provided for an embodiment of the application;

[0047] Figure 7B A schematic diagram of another dynamic link library provided for an embodiment of the application;

[0048] Figure 8 A schematic diagram of a starting virtual memory address provided for an embodiment of the application;

[0049] Figure 9 A schematic diagram of target information provided for an embodiment of the application;

[0050] Figure 10 A schematic diagram of another target information provided for an embodiment of the application;

[0051] Figure 11 A flowchart of determining a target memory address provided for an embodiment of the application;

[0052] Figure 12 A schematic diagram of a function to be repaired replacement provided for an embodiment of the application;

[0053] Figure 13 A structural schematic diagram of a hot patch loading device in an embodiment of the application;

[0054] Figure 14 A hardware component structure diagram of an electronic device applying an embodiment of the present application;

[0055] Figure 15 A hardware component structure diagram of a computing device applying an embodiment of the present application. DETAILED DESCRIPTION

[0056] To make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions of the present application will be described below in connection with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments described in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative work fall within the scope of protection of the technical solutions of the present application.

[0057] Some concepts involved in the embodiments of the present application will be introduced below.

[0058] Dynamic linking: refers to compiling and linking functions into a dynamic link library, and the running address of the function is not determined after compiling and linking, and the final running address of the function can be determined only after the process is loaded. Dynamic linking can realize that a dynamic library code is shared in each loaded process, thereby saving memory addresses.

[0059] TLS variable: TLS is a thread-level storage mechanism that allows each thread to have its own private variable at runtime, which can only be accessed by the thread and cannot be shared by other threads. These private variables are called TLS variables. Thread-local storage TLS variables are not as simple as ordinary global variables that are simply open to the process. The global variables accessed by any thread in the process are the same memory address. TLS variables need to create a separate space for each thread, and the memory addresses of the TLS variables accessed by different threads are different.

[0060] TLS variable access mode: the access mode of a TLS variable determines how to access the data in thread-local storage. In different programming environments and compilers, the access mode of a TLS variable may be different. The following are some common access modes of a TLS variable:

[0061] General Dynamic (GD): In this mode, the access of TLS variable is realized through global indirect reference. Generally, each thread has a Thread Control Block (TCB) pointer pointing to its TLS data, and the access of the TLS variable needs to be offset calculated through the TCB pointer. This mode is suitable for the TLS variable needing to cross multiple modules or libraries.

[0062] Local Executable (LE): It is for the TLS variable inside a module or library. In this mode, the address of the TLS variable is determined when the module or library is loaded and remains unchanged. This mode has high performance because the TLS variable is also accessed through a direct address. This mode is suitable for the TLS variable inside a module or library.

[0063] Global Offset Table (GOT): It includes a space for functions to store the actual running virtual address. When linking external functions, the jump instruction does not directly jump to the final address of the external function, but jumps to the space for the external function allocated by the GOT table to store the actual running virtual address.

[0064] The design idea of the embodiments of the present application is briefly introduced as follows:

[0065] With the development of computer technology and the increase of software functions, defects inevitably exist in software, and some scenarios with high requirements for software reliability require that the device cannot be restarted and the business function cannot be interrupted. Under the premise that the device cannot be restarted, implementing the repair of the defect function is a very necessary function. The industry implements the repair of the defect function by replacing the instructions of the patch function with the instructions of the to-be-repaired function through instruction replacement while the process is running under the premise that the device cannot be restarted. The to-be-repaired function refers to a function with error logic running in a process, the patch function is also called a defect repair function, which refers to a function that implements normal functions to repair error logic.

[0066] Thread-local storage is a thread-level storage mechanism that allows each thread to have its own private variables at runtime, which can only be accessed by the thread and cannot be shared by other threads. These thread-private variables are called TLS variables, and the TLS variables of thread-local storage are not as simple as ordinary global variables that are simply exposed to the process. The global variables accessed by any thread in the process are the same memory address. TLS variables need to create a separate space for each thread, and the memory addresses of the TLS variables accessed by different threads are different.

[0067] In an aarch64-type central processing unit (CPU), the TCB pointer is obtained through the tpidr_el0 register. When accessing a TLS variable, the TLS variable can be accessed by directly offsetting from the TCB pointer to the offset of the TLS variable relative to the TCB pointer.

[0068] For example, Figure 1 During runtime, thread 1 and thread 2 each have their own thread-local memory addresses for TLS variables. These TLS variable thread-local memory addresses are accessible only to their own threads and are not shared with other threads. During linking, the linker arranges the memory addresses of the thread variables and thread control blocks. For example, in the thread-local memory address, TLS variable 1 has an offset of 0 and a length of 4; TLS variable 2 has an offset of 4 and a length of 4; TLS variable N has an offset of 28 and a length of 4; and the TCB pointer has an offset of 32 (0x20). When accessing TLS variables, the address of the TCB pointer is first obtained through the tpidr_el0 register. This is then added to the offset to obtain the address of the TLS variable, allowing access to the TLS variable. For example, if the TCB pointer address of thread 1 is 0x40020 and TLS variable 1 needs to be accessed, the offset of TLS variable 1 is calculated as 0 - 0x20 = -0x20, resulting in the address of TLS variable 1 being 0x40020 - 0x20 = 0x40000.

[0069] In aarch64 type CPU, the most common access mode of TLS variable is GD mode, and the most common application of GD mode is the use of patch function in dynamic link library to TLS variable. The mode gets the TCB pointer through tpidr_el0 register. In order to realize dynamic link and delay binding, the calculation method of the offset of the TLS variable relative to the TCB pointer is saved in the GOT. Procedure Linkage Table (PLT) table, and the position of the calculation method in the table is associated with the relocation information of the relocation type R_AARCH64_TLSDESC. The position of the calculation method of the offset in the GOT. PLT table is written in the offset field of the relocation information of the relocation type R_AARCH64_TLSDESC. In the GD mode, when accessing the TLS variable, the address of the TCB pointer is first obtained from the tpidr_el0 register, then the Offset field of the same named TLS variable is found from the R_AARCH64_TLSDESC type relocation information, and the position of the calculation method of the offset of the TLS variable relative to the TCB pointer in the GOT. PLT table is obtained from the Offset field. The memory value at the position is read to obtain the calculation method of the offset, the offset is obtained by reading the calculation method, and the address of the TLS variable is obtained by adding the offset to the TCB pointer address, so that the subsequent access operation is performed.

[0070] In addition to GD mode, the compiler optimizes LE mode, which can only reference the TLS variable defined in the static link executable file compiled without the-rdynamic compilation option. The most common application scenario of LE mode is the use of patch function in the static link executable file compiled without the-rdynamic compilation option to the TLS variable. Since the patch function is compiled in static link mode, it does not need dynamic loading and delay binding, and the offset of the TLS variable relative to the TCB pointer is saved in the GOT table, and it does not need to be relocated like GD mode.

[0071] Because the LE mode does not need relocation, and the GD mode determines the TLS variable address by relying on the relocation information for relocation, the TLS variable of the GD mode cannot be obtained by relocation addressing in the LE mode. For example, the TLS variable t_flg of the GD mode cannot be addressed by the LE mode, that is, if the patch function func_a uses the TLS variable t_flg, when the func_a is compiled into a dynamic link library, the patch function func_a in the dynamic link library uses the GD mode to address the TLS variable t_flg, and the t_flg is defined in the statically linked executable file compiled without adding the -rdynamic compilation option, so the t_flg is addressed in the LE mode, but the t_flg has no relocation information, so that the patch function func_a uses the GD mode to address the TLS variable t_flg, and because the t_flg is defined in the statically linked executable file compiled without adding the -rdynamic compilation option, there is no relocation information, so the relocation addressing cannot be performed, resulting in the failure of the patch function loading.

[0072] Therefore, the present application obtains the target offset of the thread local storage TLS variable in the patch function from the statically linked executable file, and obtains the relocation information of the TLS variable from the dynamic link library. After the patch file containing the patch function is dynamically loaded, the target memory address in the dynamic link library is determined based on the relocation information, and the target offset is stored in the target memory address, so as to realize the self-relocation of the TLS variable in the statically linked executable file. Further, when the process to be repaired loads the function to be repaired, the patch function is jumped to, and when the patch function is loaded, the target offset is obtained from the target memory address, and the TLS variable of the patch function is accessed according to the target offset, so as to complete the loading of the patch function, thereby realizing the replacement of the function to be repaired and the repair of the defect problem.

[0073] Referring to Figure 2 As shown in the figure, the embodiment of the present application provides an implementation flowchart of a hot patch loading method, and the specific implementation flowchart of the method comprises S201-S204:

[0074] S201: compile the patch function into a dynamic link library.

[0075] The patch function is used to repair the static link executable file of the process to be repaired.

[0076] Since the patch function is used to replace the to-be-repaired function in the process to be repaired, in order to avoid the jump or loading failure of the process to be repaired due to the different names of the patch function and the to-be-repaired function, when the patch function is compiled into a dynamic link library, the patch function has the same name as the to-be-repaired function, and is compiled into a dynamic link library in a dynamic link manner.

[0077] S202: Obtain the target offset of the thread local storage (TLS) variable in the patch function from the static link executable file, and obtain the relocation information of the TLS variable from the dynamic link library.

[0078] S203: After dynamically loading the patch file containing the patch function, determine the target memory address in the dynamic link library based on the relocation information, and store the target offset into the target memory address.

[0079] By compiling the patch function into a dynamic link library, after the patch file is made, due to the lazy binding mechanism, the patch function in the dynamic link library can be normally loaded by the static link executable file even if the TLS variable used by the patch function lacks the relocation information in the static link executable file before the patch function is called. If the patch function needs to be called, the self-relocation of the TLS variable in the dynamic link library in the static link executable file needs to be completed, otherwise the patch function call fails.

[0080] The self-relocation of the TLS in the present application first needs to obtain the target offset, therefore, the access method of the TLS variable in the static link executable file compiled without the -rdynamic compilation option is introduced below.

[0081] In the aarch64 type CPU, the access method of the TLS variable in the static link executable file compiled without the -rdynamic compilation option is different from the access method of the TLS variable in the GD mode introduced above. Since the executable file is compiled in a static link manner, dynamic loading and lazy binding are not needed, and the offset of the TLS variable relative to the TCB pointer is still saved in the GOT table, and does not need to be relocated in the GD mode. Therefore, the relocation information needed by the dynamic link library to access the TLS variable is also not in the static link executable file compiled without the -rdynamic compilation option.

[0082] In an optional embodiment, the present application determines the target offset of the TLS variable relative to the TCB pointer in the static link executable file compiled without the -rdynamic compilation option as follows:

[0083] According to the variable name of the TLS variable and the symbol information in the statically linked executable file, the initial offset of the TLS variable in the thread local storage TLS space is found; the sum of the initial offset and the first preset offset is used as the target offset; the target offset is the offset of the TLS variable relative to the thread control block TCB pointer.

[0084] The symbol information is information in the symbol table of the statically linked executable file, which stores metadata of the symbol, such as name, type, size, binding attributes, and segment. The first preset offset can be the management header length of the TCB pointer.

[0085] In the symbol table, the initial offset of the TLS variable in the TLS space can be determined based on the TLS variable name, and then the initial offset is added to the first preset offset, and the resulting sum is the target offset.

[0086] Specifically, by parsing a statically linked executable file (such as process_a) using the readelf-s tool, you can see the information of each TLS variable defined in the statically linked executable file.

[0087] as follows Figure 3 As shown, it is a schematic diagram of a symbol table of an executable file provided in an embodiment of the present application, Figure 3 The symbol table of the executable file process_a is shown in the figure. When the value in the fourth column of the symbol table is TLS, it indicates that the variable is a TLS variable. The value in the eighth column of the name is the variable name of the TLS variable. The value in the second column of the value is the initial offset of the TLS variable in the thread-local memory address. For example, Figure 3 The initial offset of the TLS variable named t_InProcflg in the thread local memory address is 0000000000000000, which is 0.

[0088] Secondly, the assembly code for obtaining the target offset is introduced.

[0089] In an optional embodiment, the statically linked executable file compiled without adding the -rdynamic compilation option is Figure 3 The following is an example of the assembly code implementation of the TLS variable t_InProcflg operation:

[0090] 401250: 90000080 adrp x0, 411000<__FRAME_END__+0xf680>

[0091] 401254: f947d800 ldr x0, [x0, #4016]

[0092] 401258: d503201f nop

[0093] 40125c: d503201f nop

[0094] 401260: d53bd042 mrs x2, tpidr_el0

[0095] 401264: 8b000040 add x0, x2, x0

[0096] The first line at 401250: indicates that 0x411000 is assigned to the x0 register, at this time the value of the x0 register is 0x411000;

[0097] The second line at 401254: indicates that the value of the x0 register (0x411000) is added by 4016 to obtain 0x411Fb0 (0x411000+4016=0x411Fb0), and the data in the memory pointed to by 0x411Fb0 is assigned to the x0 register, as shown below, which is a schematic diagram of a GOT table provided by an embodiment of the application. The memory address of the target offset of the TCB pointer of the TLS variable t_InProcflg at 0x411Fb0 in the GOT table stores a target offset of 0x10, and after the second line of instructions, the value of the x0 register is 0x10. Figure 4 The first preset offset 0x10 is different from the initial offset value 0 shown in the TLS variable t_InProcflg in the thread local memory address by 0x10, which is a rule that exists when accessing the TLS variable in the LE mode. Generally, the first preset offset 0x10 is the size of the TCB pointer management header, that is, when accessing the TLS variable in the binary assembly code of the statically linked executable file compiled without the -rdynamic compilation option, the target offset (0x10) of the TLS variable relative to the TCB pointer calculated can be equivalently obtained by adding the initial offset value (0x0) of the TLS variable in the thread local memory address displayed after the statically linked executable file is parsed by readelf-s and the preset offset value (0x10).

[0098] Figure 3 The third line at 401258: d503201f nop indicates no operation.

[0099] The fourth line at 40125c: d503201f nop indicates no operation, and the third line and the fourth line do not perform any operation in order to fill up the 24 bytes of accessing the TLS variable.

[0100] ​​

[0101] The fifth row 401260: d53bd042 mrs x2, tpidr_el0 indicates that the value of the TCB pointer is assigned to the x2 register, and the value of the x2 register is the value of the TCB pointer at this time.

[0102] The sixth row 401264: 8b000040 add x0, x2, x0 indicates that the value of the x2 register is added to the value of the x0 register and assigned to the x0 register, the value of the x0 register is the target offset 0x10 of the TLS variable relative to the TCB pointer, the value of the x2 register is the value of the TCB pointer, and the memory address of the TLS variable is obtained after the two are added and assigned to the x0 register. At this time, the x0 register obtains the memory address of the TLS variable t_InProcflg, and subsequent operations on the x0 register are operations on the TLS variable t_InProcflg.

[0103] Further, the method for determining the offset of the TLS variable relative to the TCB pointer of the statically linked executable file compiled without adding the -rdynamic compilation option can be obtained through the above rules:

[0104] As shown in the following Figure 5 It is a flowchart for obtaining a target offset provided by an embodiment of the application.

[0105] S501: Start;

[0106] S502: The symbol information in the symbol table is parsed from the executable and linkable format (ELF) to obtain the symbol information in the symbol table, and it is judged whether the type is TLS.

[0107] Specifically, if the type is TLS, jump to S503; otherwise, jump to S505.

[0108] S503: Determine that the variable is a TLS variable, obtain the value of the Value field to obtain the initial offset value of the TLS variable in the TLS space;

[0109] S504: The initial offset value is added to the first preset offset 0x10 to obtain the target offset of the TLS variable relative to the TCB pointer.

[0110] S505: End.

[0111] The access method of the TLS variable in the dynamic link library will be introduced below.

[0112] Step 1: When it is determined that the relocation type of the TLS variable is the first type, obtain the relocation information of the TLS variable from the dynamic link library;

[0113] Among them, the first type is a type that characterizes the need for relocation, which can refer to the R_AARCH64_TLSDESC type in this application. The relocation information includes the relocation type and the memory address of the calculation method of the target offset of the TLS variable. Since the hot patch loading method adopted in this application does not require the offset to be obtained by calculation, the memory address of the calculation method of the target offset of the TLS variable can also refer to the information used to determine the target memory address of the target offset in the dynamic link library in this application.

[0114] Specifically, in aarch64 CPUs, the TCB pointer is obtained through the tpidr_el0 register. When accessing a TLS variable, the TLS variable can be accessed by directly offsetting from the TCB pointer to the offset of the TLS variable relative to the TCB pointer. During linking, the linker allocates space in the TCB structure for each TLS variable. The offset calculation method of this space relative to the TCB pointer is associated with the relocation type R_AARCH64_TLSDESC of the TLS variable and is reflected in the Offset field.

[0115] like Figure 6 As shown, it is a schematic diagram of a dynamic link library provided in an embodiment of the present application. Figure 6 The dynamic link library in the ELF format is libtest.so. The relocation information in the dynamic link library can be seen by using the readelf -Wr libtest.so command. The value of the Offset field of the TLS variable t_InProcflg of the R_AARCH64_TLSDESC type is 0x0000000000012078, indicating that the target offset of the TLS variable t_InProcflg relative to the TCB pointer is calculated at 0x0000000000012078.

[0116] Step 2: Change the relocation type of the TLS variable from the first type to the second type indicating that no relocation is required.

[0117] Among them, the second type in this application can be the R_AARCH64_JUMP_SLOT type.

[0118] This application takes into account that if the relocation type is still the first type, in the subsequent steps, the operating system will still be relocated according to the existing relocation mechanism. Since the static link executable file compiled without adding the -rdynamic compilation option lacks relocation information, the relocation fails, which in turn leads to the failure of loading the dynamic link library.

[0119] like Figure 7AAs shown in the figure, it is a schematic diagram of a dynamic link library provided by an embodiment of the present application. In FIG. 7, after the readelf-r tool parses the dynamic link library libtest.so, it is found that the relocation type of the TLS variable t_InProcflg in the relocation information is R_AARCH64_TLSDESC type. After the dynamic link library libtest.so is dynamically loaded, the operating system still repositions t_InProcflg according to the existing repositioning mechanism, which will cause positioning failure due to the lack of repositioning information in the statically linked executable file compiled without the -rdynamic compilation option.

[0120] Therefore, the present application modifies the relocation type of the accessed TLS variable in the dynamic link library from R_AARCH64_TLSDESC type to R_AARCH64_JUMP_SLOT type, so that the operating system accessing the TLS variable will not be repositioned according to the existing repositioning mechanism of the operating system.

[0121] As shown in the figure, it is another schematic diagram of a dynamic link library provided by an embodiment of the present application. Figure 7B As shown in the figure, it is another schematic diagram of a dynamic link library provided by an embodiment of the present application. Figure 7B As shown in the figure, it is another schematic diagram of a dynamic link library provided by an embodiment of the present application. Figure 7A As shown in the figure, it is another schematic diagram of a dynamic link library provided by an embodiment of the present application.

[0122] Step 3: When it is determined that the relocation type of the TLS variable is the second type, the starting virtual memory address of the dynamic link library is determined; the target information address is determined according to the relocation information and the starting virtual memory address, and the memory address of the preset function is filled into the target information address; and the target memory address is determined according to the sum of the target information address and the second preset offset.

[0123] The target information address is the memory address of the calculation method of the target offset of the TCB pointer of the TLS variable when the process to be repaired is loaded, which is also referred to as the final memory address in the present application. The preset function is the _dl_tlsdesc_return function, and the second preset offset is 8.

[0124] Since each memory address in the dynamic link library is not the final memory address during program running, the final memory address is determined after the dynamic library is loaded during program running. Therefore, the present application first obtains the starting memory address from the dynamic link library after the patch file containing the patch function is dynamically loaded, and then determines the target memory address according to the starting virtual memory address and the relocation information.

[0125] As shown in the figure, it is another schematic diagram of a dynamic link library provided by an embodiment of the present application. Figure 8As shown, it is a diagram of a starting virtual memory address provided by an embodiment of the present application. The to-be-repaired process loads the dynamic link library libtest.so. After the dynamic link library is loaded, the dynamic link library has a starting virtual memory address after loading, which is embodied in the / proc / <running program pid> / maps table, Figure 8 In the process maps table in the / proc / <running program pid> / maps table, the starting virtual memory address of the dynamic link library libtest.so after loading is 0xfffff7f77000.

[0126] Although the address A in the ELF format dynamic link library is not the final memory address B at the running time of the to-be-repaired process, the final memory address B can be obtained by adding the address A to the starting virtual memory address C of the dynamic link library after loading at the running time of the to-be-repaired process, that is, the final memory address B = address A + address C.

[0127] Therefore, the final memory address of each memory address in the dynamic link library libtest.so at the running time of the to-be-repaired process needs to be added to the starting virtual memory address after loading the dynamic link library.

[0128] Following the assumption of Figure 6 and Figure 8 , the calculation method of the ELF format dynamic link library libtest.so obtaining the target offset of the TCB pointer of the TLS variable t_InProcflg is at 0x0000000000012078, the virtual starting memory address at the running time of the to-be-repaired process is 0xfffff7f77000, and the final memory address is 0x0000000000012078+0xfffff7f77000 = 0xfffff7f89078.

[0129] Next, the access method of the TLS variable in the dynamic link library is introduced.

[0130] In an optional embodiment, the assembly code sample of the dynamic link library libtest.so operating on the TLS variable t_InProcflg is as follows:

[0131] 0x0000fffff7f77e2c<+256>:adrp x0,0xfffff7f89000<func3@got.plt>

[0132] 0x0000fffff7f77e30<+260>:ldr x2,[x0,#120]

[0133] 0x0000fffff7f77e34<+264>:add x0,x0,#0x78

[0134] 0x0000fffff7f77e38 <+268> : blr x2

[0135] 0x0000fffff7f77e3c <+272> : mrs x2, tpidr_el0

[0136] 0x0000fffff7f77e40 <+276> : add x0, x2, x0

[0137] The first line at 0x0000fffff7f77e2c: adrp x0, 0xfffff7f89000 <func3@got.plt> indicates that 0xfffff7f89000 is assigned to the x0 register, and the value of the x0 register at this time is 0xfffff7f89000.

[0138] The second line at 0x0000fffff7f77e30: ldr x2, [x0, #120] indicates that the value of the x0 register (0xfffff7f89000) is added to the memory value at the address of 120 to be loaded into the x2 register, and the value of the x2 register at this time is the memory value at 0xfffff7f89078 (0xfffff7f89000+120 = 0xfffff7f89078) in the GOT.PLT table, which can be obtained by parsing the relocation information 0x0000000000012078 of the TLS variable t_InProcflg of the relocation type R_AARCH64_TLSDESC in the ELF format dynamic library libtest.so and adding the starting virtual memory address 0xfffff7f77000 after the dynamic library libtest.so is loaded (0x0000000000012078+0xfffff7f77000 = 0xfffff7f89078), as shown in Figure 9 Printing the memory value at 0xfffff7f89078 can see that the memory value is 0x0000fffff7fe272c. Therefore, the value of the x2 register after executing this line is 0x0000fffff7fe272c.

[0139] The third row at 0x0000fffff7f77e34: add x0, x0, #0x78 indicates that the value of the x0 register (0xfffff7f89000) is added by 0x78 to be assigned to the x0 register, at which time the value of the x0 register is the memory value at 0xfffff7f89078 (0xfffff7f89000+120=0xfffff7f89078) in the GOT.PLT table, which can be obtained by parsing the relocation information 0x0000000000012078 of the TLS variable t_InProcflg of the relocation type R_AARCH64_TLSDESC in the ELF format dynamic link library libtest.so and adding the starting virtual memory address 0xfffff7f77000 after the dynamic link library libtest.so is loaded (0x0000000000012078+0xfffff7f77000=0xfffff7f89078)

[0140] The fourth row at 0x0000fffff7f77e38: blr x2 indicates jumping to the value 0x0000fffff7fe272c in the x2 register to continue executing the instructions, that is, executing the instructions at 0x0000fffff7fe272c, as shown in Figure 10 By disassembling 0x0000fffff7fe272c, it can be seen that the function at 0x0000fffff7fe272c is to return after executing the ldr x0, [x0, #8] instruction, and the ldr x0, [x0, #8] instruction is to add 8 to the value of the x0 register (0xfffff7f89078) to obtain the memory value at the address 0xfffff7f89080, and then assign the value to the x0 register, as shown in Figure 9 By checking the memory at 0xfffff7f89080, it can be seen that the value is 0x0000000000000010, and after the command is executed, the calculation of the target offset of the TLS variable t_InProcflg relative to the TCB pointer is completed, and the x0 register obtains the target offset of the TLS variable t_InProcflg relative to the TCB pointer as 0x10.

[0141] The fifth row at 0x0000fffff7f77e3c: mrs x2, tpidr_el0 indicates that the value of the TCB pointer is assigned to the x2 register, and at this time the value of the x2 register is the TCB pointer value.

[0142] The sixth row at 0x0000fffff7f77e40: add x0, x2, x0 indicates that the value of the x2 register is added to the value of the x0 register to assign the x0 register, the value of the x0 register is the target offset of the TLS variable relative to the TCB pointer 0x10, the value of the x2 register is the value of the TCB pointer, and the sum of the two is the memory address of the TLS variable and is assigned to the x0 register. Subsequent operations on the x0 register are operations on the TLS variable t_InProcflg

[0143] In summary, according to the ELF format analysis of the dynamic link library libtest.so, the relocation information can be obtained, if the relocation type is R_AARCH64_TLSDESC, it indicates that the variable is a TLS variable, and the value (0x0000000000012078) of the Offset field can be obtained to obtain the calculation method of the target offset of the TLS variable relative to the TCB pointer. The value of the Offset field is added to the starting virtual memory address (0xfffff7f77000) of the dynamic link library libtest.so obtained from the maps table when the process to be repaired runs, and the final memory address (0x0000000000012078+0xfffff7f77000=0xfffff7f89078) of the calculation method of the target offset of the TLS variable relative to the TCB pointer is obtained. This method is equivalent to the following method: through the 1st and 3rd lines of instructions of the assembly code of the TLS variable, the value of the x0 register can be calculated as the final running address (0xfffff7f89000+120=0xfffff7f89078) of the calculation method of the target offset of the TLS variable relative to the TCB pointer.

[0144] Through the 1st, 2nd and 4th lines of instructions of the assembly code of the TLS variable, it can be known that the instruction executed at the final running address (0x0000fffff7fe272c) of the calculation method of the target offset of the TLS variable relative to the TCB pointer is ldr x0, [x0, #8], that is, the memory value (0x0000000000000010) of the address (0xfffff7f89080) obtained by adding 8 to the value (0xfffff7f89078) of the x0 register, that is, the memory value (0x0000000000000010) of the address (0xfffff7f89080) obtained by adding 8 to the final running address (0xfffff7f89078) of the calculation method of the target offset of the TLS variable relative to the TCB pointer. Through the 5th and 6th lines of instructions of the assembly code of the TLS variable, it can be known that the target memory address of the TLS variable can be obtained by adding the TCB pointer to the memory value, and the access to the TLS variable is realized through the target memory address.

[0145] Therefore, the final memory address (0xfffff7f89078) of the calculation method for the target offset of the TLS variable relative to the TCB pointer plus 8 (0xfffff7f89080) is the memory address where the target offset of the TLS variable relative to the TCB pointer is stored. If the target offset of the TLS variable is clear and filled in the memory space, the memory address of the TLS variable can be obtained according to the assembly code for operating the TLS variable, and subsequent access operations can be performed.

[0146] According to the above rules, the method for determining the target memory address of the target offset of the TLS variable relative to the TCB pointer in the dynamic link library in step 3 of this application is as follows:

[0147] By obtaining the starting virtual address of the dynamic link library and adding it to the value of the relocation information, the target information address (i.e., the final memory address) is obtained. The target information address needs to be written into the address of the function (_dl_tlsdesc_return function) that calculates the additional offset of the TLS variable when the assembly instruction is executed so that the assembly instruction that accesses the TLS variable can be executed correctly. The target memory address can be determined based on the sum of the target information address and the second preset offset.

[0148] like Figure 11 As shown, it is a flowchart of determining the target memory address provided by an embodiment of the present application.

[0149] S1101: Start;

[0150] S1102: ELF format parses the dynamic link library to obtain relocation information and determines whether the relocation type is R_AARCH64_TLSDESC;

[0151] Specifically, if the relocation type is R_AARCH64_TLSDESC, jump to S1103; otherwise, jump to 1106.

[0152] S1103: Determine that the variable is a TLS variable and obtain the value of the Offset field;

[0153] S1104: Change the relocation type of the TLS variable from R_AARCH64_TLSDESC to R_AARCH64_JUMP_SLOT. After dynamically loading the patch file containing the patch function, read the running process maps table to obtain the starting virtual memory address after the dynamic link library is loaded;

[0154] S1105: The value of the Offset field of the TLS variable is added to the start virtual memory address of the dynamic link library to obtain the final memory address of the Offset field of the TLS variable, and the memory address of the _dl_tlsdesc_return function is filled into the target information address; the target memory address of the target offset of the TLS variable relative to the TCB pointer is obtained according to the sum of the target information address and the second preset offset;

[0155] S1106: End.

[0156] According to the method for determining the target offset of the TLS variable relative to the TCB pointer in the static link executable file compiled without adding the -rdynamic compilation option, the target offset of the TLS variable relative to the TCB pointer in the static link executable file is determined, the target memory address of the target offset of the TLS variable relative to the TCB pointer in the dynamic link library file is determined by the method for determining the target memory address of the target offset of the TLS variable relative to the TCB pointer in the dynamic link library, and the target offset is filled into the target memory address.

[0157] For example, according to the method for determining the target offset of the TLS variable relative to the TCB pointer in the static link executable file compiled without adding the -rdynamic compilation option, the target offset of the TLS variable relative to the TCB pointer in the executable file is determined to be 0+0x10=0x10.

[0158] The target memory address of the target offset of the TLS variable relative to the TCB pointer in the dynamic link library file is determined by the method for determining the target memory address of the target offset of the TLS variable relative to the TCB pointer in the dynamic link library, and the target memory address of the target offset of the TLS variable relative to the TCB pointer in the dynamic link library file is determined to be 0x12078+0x fffff7f77000+0x8=0xfffff7f89080, and the address of the _dl_tlsdesc_return function is filled in at 0xfffff7f89078.

[0159] The target offset of the TLS variable relative to the TCB pointer in the executable file 0x10 is filled into the target memory address of the target offset of the TLS variable relative to the TCB pointer in the dynamic link library file 0xfffff7f89080 to complete the self-relocation.

[0160] S204: When the to-be-repaired process is loaded to the to-be-repaired function, jump to the patch function, and when the patch function is loaded, the target offset is obtained from the target memory address, and the TLS variable of the patch function is accessed according to the target offset, to complete the loading of the patch function.

[0161] This application is to be able to successfully jump to the patch function during the loading of the process to be repaired and replace the function to be repaired. The following method is used to achieve this:

[0162] If there is a target function with the same function name as the patch function in the functions of the process to be repaired, the target function is used as the function to be repaired; the assembly instruction at the function address entry of the function to be repaired is modified to an assembly instruction that jumps to the patch function.

[0163] Specifically, a patch file containing at least one patch function is dynamically loaded into the process to be repaired. The patch function's function information in the patch file is read. Based on the function name in the function information, a search is performed among all functions used in the process to be repaired for a function with the same name. If a function is found, it is the function to be repaired. The assembly instructions at the function address entry of the function to be repaired in the process to be repaired are modified to jump to the assembly instructions of the function with the same name in the dynamic link library, thereby replacing the function to be repaired and repairing the defect.

[0164] like Figure 12 As shown, it is a schematic diagram of replacing a function to be repaired provided in an embodiment of the present application. Figure 12 The process to be patched includes the function to be patched, func A, and the function func B that calls func A. The function to be patched, func A, contains the push rbp instruction; this is an assembly language instruction used on x86-64 processors. This instruction pushes the current value of the base pointer register (BP register) onto the stack. During the hot patch loading process, when the function to be patched, func A, should be executed, is replaced by the function entry instruction Jump func A, jumping to the patch function, func A, thereby replacing the function to be patched.

[0165] When loading the patch function, the sum of the TCB pointer address and the target offset is used as the TLS variable address; according to the TLS variable address, the TLS variable is accessed.

[0166] The embodiment of the present application provides a hot patch loading method and device, electronic equipment and a storage medium. The present application compiles a patch function into a dynamic link library; considering the delay binding mechanism, the patch function of the dynamic link library can be normally loaded by the statically linked executable file even if the TLS variable used by the patch function lacks relocation information in the statically linked executable file before being called, and if the patch function needs to be called, the self-relocation of the TLS variable in the dynamic link library in the statically linked executable file needs to be completed first, otherwise the function call fails. Therefore, the present application obtains the target offset of the thread local storage TLS variable in the patch function from the statically linked executable file, and obtains the relocation information of the TLS variable from the dynamic link library. After dynamically loading the patch file containing the patch function, the target memory address in the dynamic link library is determined based on the relocation information, and the target offset is stored in the target memory address, so that the self-relocation of the TLS variable in the statically linked executable file is realized. Further, when the to-be-repaired process is loaded to the to-be-repaired function, the patch function is jumped to, and when the patch function is loaded, the target offset is obtained from the target memory address, and the TLS variable of the patch function is accessed according to the target offset, so that the loading of the patch function is completed, and the replacement of the to-be-repaired function is realized, and the defect problem is repaired.

[0167] The present application realizes the relocation addressing method of the TLS variable in the dynamic link library in the aach64 type CPU in the TLS variable defined in the statically linked executable file compiled without adding the -rdynamic compilation option, thereby eliminating the relocation dependence of the TLS variable used in the patch function, realizing the successful loading of the patch function using the TLS variable, and compared with the way of realizing the switching of the access mode of the TLS variable by searching the assembly code according to the characteristics, modifying the assembly code, and then filling and covering the assembly code in the prior art, the operation steps of the present application are relatively simple, and the judgment branch is less, and the application range is wide.

[0168] Based on the same inventive concept, the embodiment of the present application also provides a hot patch loading device. As shown in the Figure 13 structure diagram of the hot patch loading device 1300, the hot patch loading device 1300 can include:

[0169] The compiling unit 1301 is configured to compile a patch function into a dynamic link library; the patch function is used for repairing a statically linked executable file of a to-be-repaired process;

[0170] The obtaining unit 1302 is configured to obtain the target offset of the thread local storage TLS variable in the patch function from the statically linked executable file, and obtain the relocation information of the TLS variable from the dynamic link library;

[0171] The determining unit 1303 is configured to, after dynamically loading the patch file containing the patch function, determine the target memory address in the dynamic link library based on the relocation information, and store the target offset into the target memory address.

[0172] The jumping unit 1304 is configured to, when the process to be repaired is loaded into the function to be repaired, jump to the patch function, and when the patch function is loaded, obtain the target offset from the target memory address, and access the TLS variable of the patch function according to the target offset, so as to complete the loading of the patch function.

[0173] Optionally, the obtaining unit 1302 is specifically configured to:

[0174] According to the variable name of the TLS variable, the symbol information in the statically linked executable file is searched to find the initial offset of the TLS variable in the thread local storage TLS space.

[0175] The sum of the initial offset and the first preset offset is taken as the target offset; the target offset is the offset of the TLS variable relative to the thread control block TCB pointer.

[0176] Optionally, the jumping unit 1304 is specifically configured to:

[0177] The sum of the TCB pointer address and the target offset is taken as the TLS variable address.

[0178] The TLS variable is accessed according to the TLS variable address.

[0179] Optionally, the obtaining unit 1302 is specifically configured to:

[0180] When it is determined that the relocation type of the TLS variable is the first type, the relocation information of the TLS variable is obtained from the dynamic link library; the first type is a type representing that relocation is needed.

[0181] Optionally, after the obtaining unit 1302 obtains the relocation information of the TLS variable from the dynamic link library, and before the determining unit 1303 dynamically loads the patch file containing the patch function, the apparatus further comprises a first modifying unit 1305, which is configured to:

[0182] The relocation type of the TLS variable is modified from the first type to a second type representing that no relocation is needed.

[0183] Optionally, the determining unit 1303 is specifically configured to:

[0184] When it is determined that the relocation type of the TLS variable is the second type, the starting virtual memory address of the dynamic link library is determined.

[0185] According to the relocation information and the starting virtual memory address, a target information address is determined, and a memory address of the preset function is filled into the target information address;

[0186] According to a sum of the target information address and a second preset offset, a target memory address is determined.

[0187] Optionally, before the jump unit 1304 jumps to the patch function when the to-be-repaired process is loaded to the to-be-repaired function, the apparatus further includes a second modification unit 1306, which is specifically configured to:

[0188] If there is a target function with the same function name as the function name of the patch function in each function of the to-be-repaired process, the target function is taken as the to-be-repaired function;

[0189] The assembly instruction at the function address entry of the to-be-repaired function is modified to the assembly instruction of jumping to the patch function.

[0190] Based on the same inventive concept, the embodiment of the present application also provides an electronic device. In this embodiment, the structure of the electronic device can be as shown in Figure 14 The electronic device includes a memory 1401, a communication module 1403, and one or more processors 1402.

[0191] The memory 1401 is used to store computer programs executed by the processor 1402. The memory 1401 can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, programs required for running instant messaging functions, and the like; and the data storage area can store various instant messaging information and operation instruction sets, and the like.

[0192] The memory 1401 can be a volatile memory, such as a random-access memory (RAM); the memory 1401 can also be a non-volatile memory, such as a read-only memory, a flash memory, a hard disk drive (HDD), or a solid-state drive (SSD); or the memory 1401 can be any other medium capable of carrying or storing desired computer programs in the form of instructions or data structures and capable of being accessed by a computer, but is not limited to this. The memory 1401 can be a combination of the above memories.

[0193] The processor 1402 can include one or more central processing units (CPUs), or digital processing units, etc. The processor 1402 is configured to implement the hot patch loading method described above when invoking the computer program stored in the memory 1401.

[0194] The communication module 1403 is configured to communicate with electronic devices and other servers.

[0195] The specific connection medium between the memory 1401, the communication module 1403 and the processor 1402 is not limited in the embodiments of the present application. In the embodiments of the present application, the memory 1401 and the processor 1402 are connected through the bus 1404, and the bus 1404 is described by a thick line in the drawings. The connection mode between other components is only schematically described, and is not limited. Figure 14 Figure 14 The bus 1404 can be divided into an address bus, a data bus, a control bus, etc. For the convenience of description, only one thick line is used to describe the bus 1404 in the drawings, but it is not described that there is only one bus or only one type of bus. Figure 14

[0196] The memory 1401 stores a computer storage medium, and the computer storage medium stores computer executable instructions. The computer executable instructions are used to implement the hot patch loading method of the embodiments of the present application. The processor 1402 is configured to execute the hot patch loading method. Based on the same inventive concept, the embodiments of the present application provide a computer readable storage medium, and a computer program product includes computer program codes. When the computer program codes run on a computer, the computer program codes make the computer execute any one of the hot patch loading methods as discussed above. Since the principle of solving problems of the above computer readable storage medium is similar to the hot patch loading method, the implementation of the above computer readable storage medium can be referred to the implementation of the method, and the repeated parts will not be described.

[0197] The computing device 1500 according to this embodiment of the present application will be described below with reference to Figure 15 Figure 15 The computing device 1500 is only an example, and should not bring any limitation to the functions and use range of the embodiments of the present application.

[0198] As shown in Figure 15 , the computing device 1500 is in the form of a general computing device. The components of the computing device 1500 can include but are not limited to the above at least one processing unit 1501, the above at least one storage unit 1502, and the bus 1503 connecting different system components including the storage unit 1502 and the processing unit 1501.

[0199] ​​​Bus 1503 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a local bus using any of a variety of bus architectures.

[0200] Storage 1502 can also include a read only memory (ROM) 1523 in the form of flash, among others.

[0201] Storage 1502 can also include a program / utility 1525 having a set of program modules 1524 including an operating system, one or more application programs, other program modules, and program data, each of which can give the computer 1500 its functionality, some or all of which can be implemented as specialized hardware logic. These software

[0202] The computing device 1500 can also communicate with one or more external devices 1504 such as a keyboard, a pointing device, a scanner, or a networking device through an I / O interface 1505. The computing device 1500 can also include one or more of a graphics processing unit, a Figure 15 The computing device 1500 can also communicate with one or more networks 1507, such as one or more external networks 1507, through a network adapter 1506. The network adapter 1506 can be any of a variety of different types of adapters, including but not limited to Ethernet, Fiber, and / or Wi-Fi adapters. The network adapter 1506 can be connected to one or more of the other components of the computing device 1500 through the bus 1503. It should be appreciated that the network adapter 1506 can be considered to be part of the bus 1503 or a separate component that is coupled with the bus 1503. It should be appreciated that the computing device 1500 can be a part of a larger system, and that there can be a variety of different types of devices in the larger system.

[0203] The embodiments of the present application further provide a computer program product. The methods in the present application can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented by software, the software can be in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When loaded and executed by a computer, the computer programs or instructions perform the processes or functions described in the present application. The computer can be a general purpose computer, a special purpose computer, a computer network, a network device, a user equipment, a core network device, an OAM, or other programmable apparatus.

[0204] The computer-readable storage medium can be implemented as a computer program product, that is, an embodiment of the present application also provides a computer-readable storage medium, which includes a computer program, and when the computer program is executed by a processor, it implements any of the above-mentioned hot patch loading methods.

[0205] The computer program or instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer program or instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via a wired or wireless method. The computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium, such as a floppy disk, a hard disk, or a magnetic tape; an optical medium, such as a digital video disk; or a semiconductor medium, such as a solid-state drive. The computer-readable storage medium may be a volatile or non-volatile storage medium, or may include both volatile and non-volatile types of storage media.

[0206] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

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

[0208] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the processFigure 1 one or more processes and / or functions described in one or more blocks. Figure 1 one or more blocks.

[0209] These computer program instructions can also be loaded into computer or other programmable data processing devices, so that a series of operation steps are performed on the computer or other programmable data processing devices to generate computer-implemented processes, thus the instructions executed on the computer or other programmable data processing devices provide processes for implementing the functions described in the flow Figure 1 one or more processes and / or functions described in one or more blocks. Figure 1 one or more blocks.

[0210] Obviously, those skilled in the art can make various modifications and variations to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application belong to the scope of the claims of the present application and their equivalent technologies, the present application also intends to include these modifications and variations.

Claims

1. A hot patch loading method, characterized in that: The method comprises: Compiling a patch function into a dynamic link library; the patch function is used to repair the static link executable file of the process to be repaired; Obtaining a target offset of a thread-local storage TLS variable in the patch function from the statically linked executable file, and obtaining relocation information of the TLS variable from the dynamic link library; After dynamically loading the patch file containing the patch function, determining a target memory address in the dynamic link library based on the relocation information, and storing the target offset in the target memory address; When the process to be repaired is loaded into the function to be repaired, it jumps to the patch function, and when loading the patch function, after obtaining the target offset from the target memory address, the TLS variable of the patch function is accessed according to the target offset to complete the loading of the patch function.

2. The method according to claim 1, wherein The step of obtaining a target offset of a thread local storage TLS variable in the patch function from the statically linked executable file includes: According to the variable name of the TLS variable and the symbol information in the statically linked executable file, finding the initial offset of the TLS variable in the thread local storage TLS space; The sum of the initial offset and the first preset offset is used as the target offset; the target offset is the offset of the TLS variable relative to the thread control block TCB pointer.

3. The method according to claim 2, wherein The accessing the TLS variable of the patch function according to the target offset includes: The sum of the TCB pointer address and the target offset is used as the TLS variable address; The TLS variable is accessed according to the TLS variable address.

4. The method according to claim 1, wherein The step of obtaining the relocation information of the TLS variable from the dynamic link library includes: When it is determined that the relocation type of the TLS variable is a first type, relocation information of the TLS variable is obtained from the dynamic link library; the first type is a type indicating that relocation is required.

5. The method according to claim 4, wherein After acquiring the relocation information of the TLS variable from the dynamic link library and before dynamically loading the patch file containing the patch function, the method further includes: The relocation type of the TLS variable is changed from the first type to a second type indicating that no relocation is required.

6. The method according to claim 5, wherein Determining the target memory address in the dynamic link library based on the relocation information includes: When it is determined that the relocation type of the TLS variable is the second type, determining a starting virtual memory address of the dynamic link library; Determine a target information address according to the relocation information and the starting virtual memory address, and fill the memory address of the preset function into the target information address; The target memory address is determined according to the sum of the target information address and a second preset offset.

7. The method according to claim 1, wherein When the process to be repaired is loaded into the function to be repaired, before jumping to the patch function, the method further includes: If there is a target function with the same function name as the patch function among the functions of the process to be repaired, the target function is used as the function to be repaired; The assembly instruction at the function address entry of the function to be repaired is modified to an assembly instruction that jumps to the patch function.

8. A thermal patch loading device, characterized in that: The device comprises: A compilation unit, configured to compile a patch function into a dynamic link library; the patch function is used to repair a statically linked executable file of a process to be repaired; an acquiring unit, configured to acquire a target offset of a thread-local storage TLS variable in the patch function from the statically linked executable file, and to acquire relocation information of the TLS variable from the dynamic link library; a determining unit, configured to determine a target memory address in the dynamic link library based on the relocation information after dynamically loading the patch file containing the patch function, and store the target offset in the target memory address; A jump unit is used to jump to the patch function when the process to be repaired is loaded into the function to be repaired, and when loading the patch function, after obtaining the target offset from the target memory address, access the TLS variable of the patch function according to the target offset to complete the loading of the patch function.

9. An electronic device, characterized in that: The method comprises a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor is enabled to perform the steps of any one of the methods of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The method comprises a computer program. When the computer program is run on an electronic device, the computer program is used to enable the electronic device to execute the steps of any one of the methods of claims 1 to 7.

11. A computer program product, characterized in that The method comprises a computer program stored in a computer-readable storage medium; when a processor of an electronic device reads the computer program from the computer-readable storage medium, the processor executes the computer program, so that the electronic device performs the steps of any one of the methods described in claims 1 to 7.

Images