Reloading of an updated shared library without stopping execution of an application

Abstract

Techniques include executing a software program having a function call to a shared library and reloading the shared library without stopping execution of the software program. Responsive to resolving a link address associated with the function call, a global offset table (GOT) is updated. An entry in the GOT includes a link address field, an index field, and a resolve field, the updating including updating the index field with a positive value and marking the resolve field with a positive flag for the entry in the GOT. Responsive to reloading the shared library, an entry in the GOT is found having a positive value in the index field and a positive flag in the resolve field. Responsive to subsequent execution of the function call to the shared library, a value of the address in the link address field of the entry having the positive value in the index field is returned.

Description

Technical Field

[0001] This invention generally relates to computer systems, and more particularly to computer systems, computer-implemented methods, and computer program products that perform reloading of updated shared libraries without halting the execution of applications. Background Technology

[0002] In computing, position-independent code, or position-independent executable code, is the body of machine code located somewhere in main memory that executes correctly regardless of its absolute address. The term absolute address refers to a numerical value that physically identifies a fixed location in physical memory, either in bytes from the beginning or in a disk, sector, or byte manner in a peripheral device. Position-independent code is often used for shared libraries, allowing the same library code to be loaded into a location in each program's address space where it will not overlap with any other memory usage (e.g., other shared libraries). Shared libraries, or shared targets, are files intended to be shared by the executable and further shared target files. Modules used by a program are loaded into memory from the respective shared targets at load time or runtime, rather than being copied by the linker when it creates a single monolithic executable for the program. Specifically, shared libraries are libraries loaded by the program when it starts. When a shared library is correctly installed, all subsequently launched programs automatically use the new shared library. Shared libraries can be statically linked at compile time, meaning references to the library modules are resolved and allocated to memory when the executable is created, or dynamically linked later.

[0003] When using shared libraries, problems or difficulties may arise when updating them. For example, if the source code in the shared library is updated, the compilation options used are changed, and / or the search path is modified while the program is already running, problems may occur even if positive-independent code is used. In such cases, the user must stop program execution or debugging and reload the software program for the updated shared library to take effect. Summary of the Invention

[0004] Embodiments of the present invention relate to reloading an updated shared library without halting the execution of an application. A non-limiting example computer-implemented method includes: executing a software program by a processor that requires function calls to a shared library; and reloading the shared library without halting the execution of the software program, the shared library having been updated after the execution of the software program. The computer-implemented method includes updating a Global Offset Table (GOT) in response to resolving a link address associated with the function call. Entries in the GOT include a link address field, an index field, and a resolution field. The update includes updating the index field with a positive value and marking the resolution field with a positive flag for each entry in the GOT. The computer-implemented method includes finding an entry in the GOT that has a positive value in the index field and a positive flag in the resolution field in response to reloading the shared library without halting the execution of the software program. Furthermore, the computer-implemented method includes returning the address value in the link address field of the entry that has a positive value in the index field in response to subsequent execution of the function call to the shared library.

[0005] In addition to one or more of the features described above or below, or as an alternative, further embodiments may include setting the link address field to a default value before updating the GOT.

[0006] In addition to one or more of the features described above or below, or as an alternative, further embodiments may include, before updating the GOT, marking the parsed field with a non-affirmative value if the parsed field previously contained the affirmative value.

[0007] In addition to one or more of the features described above or below, or as an alternative, other embodiments may include reloading the shared library without stopping the execution of the software program, which includes resolving the new address of the updated shared library.

[0008] In addition to one or more of the features described above or below, or as an alternative, further embodiments may include updating the GOT by replacing the default value in the link address field with a new address.

[0009] In addition to one or more of the features described above or below, or as an alternative, further embodiments may include wherein the address value in the link address field is a new address that has been resolved for the shared library.

[0010] In addition to one or more of the features described above or below, or as an alternative, further embodiments may include initially loading the shared library during the execution of the software program for the purpose of calling the functions of the shared library, prior to reloading the shared library.

[0011] In addition to one or more of the features described above or below, or as an alternative, further embodiments may include reloading updated shared libraries without stopping the execution of the software program / application.

[0012] In addition to or as an alternative to one or more of the features described above or below, further embodiments may include expanding the size of the global offset table with a new library index field and a new address resolution tag field to account for reloading updated shared libraries.

[0013] A non-limiting example system includes a memory having computer-readable instructions and one or more processors for executing the computer-readable instructions. The computer-readable instructions control the one or more processors to perform operations including: executing a software program that requires function calls to a shared library, and reloading the shared library after execution of the software program without stopping the execution of the software program. The operations include updating a Global Offset Table (GOT) in response to resolving a link address associated with the function call. Entries in the GOT include a link address field, an index field, and a resolution field. The update includes updating the index field with a positive value and marking the resolution field with a positive flag for each entry in the GOT. The operations also include finding an entry in the GOT that has a positive value in the index field and a positive flag in the resolution field in response to reloading the shared library without stopping the execution of the software program. Furthermore, the operations include returning the address value in the link address field of the entry that has a positive value in the index field in response to subsequent execution of the function call to the shared library.

[0014] A non-limiting example includes a computer program product comprising a computer-readable storage medium having program instructions implemented therewith, the program instructions being executable by a processor to cause the processor to perform operations including: executing a software program that requires function calls to a shared library. The operations include reloading the shared library without halting the execution of the software program, the shared library having been updated after the execution of the software program. The operations include updating a Global Offset Table (GOT) in response to resolving a link address associated with the function call, entries in the GOT including a link address field, an index field, and a resolution field, the update including updating the index field with a positive value and marking the resolution field with a positive flag for each entry in the GOT. The operations include finding an entry in the GOT that has a positive value in the index field and a positive flag in the resolution field in response to reloading the shared library without halting the execution of the software program. Furthermore, the operations include returning the address value in the link address field of the entry that has a positive value in the index field in response to subsequent execution of the function call to the shared library.

[0015] A non-limiting example includes a computer-implemented method that reloads a shared library without halting the execution of a software program that calls the shared library. The computer-implemented method includes, in response to resolving a link address to the shared library, updating an index field with a positive value and marking a resolved field with a positive flag for an entry in a Global Offset Table (GOT). The computer-implemented method also includes, in response to reloading the shared library without halting the execution of the software program, finding an entry in the GOT that has a link address resolved for the shared library.

[0016] A non-limiting example includes a system comprising a memory having computer-readable instructions and one or more processors for executing the computer-readable instructions. The computer-readable instructions control the one or more processors to perform operations including: reloading the shared library without halting the execution of a software program that calls the shared library. The operation includes, in response to a link address resolved to the shared library, updating an index field with a positive value and marking a resolved field with a positive flag for an entry in a Global Offset Table (GOT). The operation also includes, in response to reloading the shared library without halting the execution of the software program, finding an entry in the GOT with a link address resolved for the shared library.

[0017] Other embodiments of the present invention implement the features of the above-described method in computer systems and computer program products.

[0018] Additional technical features and benefits are achieved through the technology of this invention. Embodiments and aspects of the invention are described in detail herein and are considered part of the claimed subject matter. For a better understanding, refer to the detailed description and accompanying drawings. Attached Figure Description

[0019] The details of the claims set forth herein are specifically pointed out and clearly claimed in the claims at the end of the specification. The foregoing and other features and advantages of embodiments of the invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings, wherein: Figure 1 A block diagram is depicted for use in conjunction with one or more embodiments of the present invention; Figure 2 A block diagram of a system for reloading an updated shared library without stopping the execution of a software program / application, according to one or more embodiments of the present invention, is depicted. Figure 3 A block diagram depicting an exemplary architectural flow according to one or more embodiments of the present invention; Figure 4 A block diagram depicting an example flowchart of a debugging session for a software program / application according to one or more embodiments of the present invention; Figure 5 An example global offset table with extended fields is depicted according to one or more embodiments of the present invention; Figure 6 An exemplary architectural flow according to one or more embodiments of the present invention is described; Figure 7 A block diagram illustrating detailed actions performed by a dynamic linker and a debugger is provided according to one or more embodiments of the present invention. Figure 8 A block diagram illustrating linker operation is depicted according to one or more embodiments of the present invention; Figure 9 A block diagram illustrating backfilling is depicted according to one or more embodiments of the present invention; Figure 10 A block diagram illustrating further loader actions according to one or more embodiments of the present invention is depicted; Figure 11 A block diagram illustrating, according to one or more embodiments of the present invention, directly branches to a new address of the shared library when a function call is subsequently executed; Figure 12 This is a flowchart of a method for reloading an updated shared library without stopping the execution of a software program / application, according to one or more embodiments of the present invention; Figure 13This is a flowchart of a method for reloading an updated shared library without stopping the execution of a software program / application, according to one or more embodiments of the present invention; Figure 14 A cloud computing environment according to one or more embodiments of the present invention is described; and Figure 15 An abstract model layer is described according to one or more embodiments of the present invention. Detailed Implementation

[0020] One or more embodiments of the present invention perform the reloading of updated shared libraries without halting the execution of a target program / application. One or more embodiments of the present invention provide a technique for seamlessly reloading updated dynamic libraries called by a software program / application when a debugger or other tool triggers a library reloading action. According to one or more embodiments, the static linker is configured to expand the size of the Global Offset Table (GOT) entries using a new library index field and a new address resolution flag field. The debugger or other tool is configured to reload the updated dynamic library and browse the library index field of the GOT, then reset the link address (with default values) and resolution flag (with default values) stored in the matching GOT entries, the previous address resolution flag of which was TRUE. Thus, when the application programming interface (API) from the updated shared library is later called, the reset link address in the link address field causes the loader to resolve the link address. One or more embodiments of the present invention efficiently reload updated shared dynamic libraries without halting the execution or debugging of software programs / applications that call APIs for updated dynamic libraries. Therefore, this beneficial technology not only helps users resolve their problems / requests / inputs faster and more efficiently, but also provides them with a more flexible way to perform testing and / or debugging.

[0021] One or more embodiments address a problem in the prior art where, after application execution, if the source code in a shared library is updated, the compilation options used are changed, and / or the search path is modified, even with the use of irrelevant code, the user must stop the execution or debugging of the software program / application to reload it for the updated shared libraries to take effect. The reason for stopping the software program / application is that the current loader cannot effectively resolve link addresses when an updated shared dynamic library is loaded at a different address during the execution of the software program / application. Such frequent restarts during program / application development and vulnerability localization are cumbersome and time-consuming for developers, especially for programs / applications with very complex (or long) source code. However, one or more embodiments of the present invention provide a novel and innovative method to address this situation, thereby introducing an efficient way to seamlessly reload updated dynamic libraries without terminating or stopping the execution or debugging of the program / application.

[0022] Turn now Figure 1 This document generally illustrates a computer system 100 according to one or more embodiments of the present invention. The computer system 100 may be an electronic computer architecture comprising and / or employing any number of computing devices and networks utilizing various communication technologies and combinations thereof, as described herein. The computer system 100 may be easily upgradeable, scalable, and modular, with the ability to change to different services or reconfigure some features independently of others. The computer system 100 may be, for example, a server, desktop computer, laptop computer, tablet computer, or smartphone. In some examples, the computer system 100 may be a cloud computing node. The computer system 100 may be described in the general context of computer system executable instructions, such as program modules executed by the computer system. Typically, program modules may include routines, programs, objects, components, logic, data structures, etc., that perform specific tasks or implement specific abstract data types. The computer system 100 may be practiced in a distributed cloud computing environment, where tasks are performed by remote processing devices linked via a communication network. In a distributed cloud computing environment, program modules may reside in local and remote computer system storage media, including memory storage devices.

[0023] like Figure 1As shown, computer system 100 has one or more central processing units (CPUs) 101a, 101b, 101c, etc. (collectively or generally referred to as processor 101). Processor 101 may be a single-core processor, a multi-core processor, a computing cluster, or any number of other configurations. Processor 101 (also referred to as processing circuitry) is coupled to system memory 103 and various other components via system bus 102. System memory 103 may include read-only memory (ROM) 104 and random access memory (RAM) 105. ROM 104 is coupled to system bus 102 and may include a basic input / output system (BIOS) or a successor system such as a unified extensible firmware interface (UEFI), which controls certain basic functions of computer system 100. RAM is read-write memory coupled to system bus 102 for use by processor 101. System memory 103 provides temporary memory space for the operation of the instructions during operation. System memory 103 may include random access memory (RAM), read-only memory, flash memory, or any other suitable memory system.

[0024] Computer system 100 includes an input / output (I / O) adapter 106 and a communication adapter 107 coupled to a system bus 102. I / O adapter 106 may be a Small Computer System Interface (SCSI) adapter that communicates with a hard disk 108 and / or any other similar component. I / O adapter 106 and hard disk 108 are collectively referred to herein as mass storage device 110.

[0025] Software 111 for execution on computer system 100 may be stored in mass storage device 110. Mass storage device 110 is an example of a tangible storage medium readable by processor 101, wherein software 111 is stored as instructions executed by processor 101 to operate computer system 100, such as those depicted herein with reference to the accompanying drawings. Examples of computer program products and the execution of such instructions are discussed in more detail here. Communication adapter 107 interconnects system bus 102 with network 112, which may be an external network, enabling computer system 100 to communicate with other such systems. In one embodiment, a portion of system memory 103 and mass storage device 110 jointly store an operating system, which may be a coordinating... Figure 1 The functions of the various components shown are available on any suitable operating system.

[0026] Additional input / output devices are shown connected to the system bus 102 via display adapter 115 and interface adapter 116. In one embodiment, adapters 106, 107, 115, and 116 may be connected to one or more I / O buses connected to the system bus 102 via an intermediate bus bridge (not shown). A display 119 (e.g., a screen or display monitor) is connected to the system bus 102 via display adapter 115, which may include a graphics controller to improve the performance of graphics-intensive applications and video controllers. Keyboard 121, mouse 122, speakers 123, etc., may be interconnected to the system bus 102 via interface adapter 116, which may include, for example, a super I / O chip integrating multiple device adapters into a single integrated circuit. Suitable I / O buses for connecting peripheral devices such as hard disk controllers, network adapters, and graphics adapters typically include common protocols such as Peripheral Component Interconnect (PCI) and Fast Peripheral Component Interconnect (PCIe). Therefore, as Figure 1 The computer system 100 configured therein includes processing capabilities in the form of a processor 101, storage capabilities including system memory 103 and mass storage device 110, input devices such as a keyboard 121 and a mouse 122, and output capabilities including a speaker 123 and a display 119.

[0027] In some embodiments, the communication adapter 107 may use any suitable interface or protocol to transmit data, such as an Internet Minicomputer System Interface (IMSI). The network 112 may be a cellular network, radio network, wide area network (WAN), local area network (LAN), or the Internet. External computing devices may connect to the computer system 100 via the network 112. In some examples, the external computing device may be an external network server or a cloud computing node.

[0028] It should be understood that Figure 1 The block diagram is not intended to indicate that computer system 100 will include Figure 1 All components shown. Conversely, computer system 100 may include... Figure 1 Any suitable fewer or additional components not shown herein (e.g., additional memory components, embedded controllers, modules, additional network interfaces, etc.). Furthermore, the embodiments described herein with respect to computer system 100 can be implemented with any suitable logic, wherein the logic mentioned herein may include any suitable hardware (e.g., processor, embedded controller, or application-specific integrated circuit, etc.), software (e.g., applications, etc.), firmware, or any suitable combination of hardware, software, and firmware.

[0029] Figure 2This is a block diagram of a system 200 for reloading an updated shared library 214 without stopping the execution of a software program / application, according to one or more embodiments of the present invention. Figure 2 One or more computer systems 202 are depicted. For example, computer system 202 may represent many computers in a data center serving various users. Components of computer system 100 may be used and / or integrated into computer system 202. One or more software programs / applications 230, one or more debuggers 240, one or more static linkers 210 and dynamic linkers 212, one or more GOTs 208, and one or more shared libraries 214 may be utilized and / or implemented as software 111 that executes on one or more processors 101, such as... Figure 1 As discussed in the article.

[0030] Software program / application 230 executes on computer system 202, and software program / application 230 uses and / or requests access to shared library 214 as part of its execution. Shared library may have a special name called a "soname". The soname has a prefix "lib", the library name, the phrase ".so" followed by a period, and a version number that increments whenever the interface changes. A fully qualified soname may include the directory where it resides as a prefix. On the operating system, a fully qualified soname is simply a symbolic link to the "real name" of the shared library. The real name is the filename containing the actual library code.

[0031] In computing, a linker or link editor, such as a static linker 210 and a dynamic linker 212, is a computer system program that takes one or more object files (generated by a compiler or assembler) and combines them into a single executable file, library file, or another "object" file. Computer programs, such as software programs / applications 230, typically consist of several parts or modules. These parts / modules do not need to be entirely contained within a single object file, and in such cases, they reference each other via symbols (e.g., in symbol table 216) as addresses to other modules, which are mapped to memory addresses (of memory 206) when linked for execution. Typically, an object file can contain three types of symbols: defined "external" symbols, sometimes called "public" or "entry" symbols, which allow them to be called by other modules; undefined "external" symbols that refer to other modules to which these symbols are defined; and local symbols used within the object file for relocation purposes. Relocations are entries in binary form, left to be populated later by the static linker (binder) at link time or by the dynamic linker (loader) at runtime.

[0032] Many operating system environments allow dynamic linking (e.g., using dynamic linker 212), which delays the resolution of certain undefined symbols until the program (e.g., software program / application 230) is run. This means that the executable code of software program / application 230 still contains undefined symbols, along with a list of objects or libraries (e.g., one or more shared libraries 214) that will provide definitions for these undefined symbols. The dynamically linked program (e.g., software program / application 230) contains small, statically linked functions that are called when the program starts. These static functions map the linked libraries (e.g., one or more shared libraries 214) into memory 206 and execute the code contained within the function. Dynamic linker 212 determines all the shared dynamic libraries required by the program, as well as the names of variables and functions needed from those libraries, by reading information contained in the sections of the shared libraries. Dynamic linker 212 then maps the shared libraries into middleware in virtual memory and resolves references to symbols contained in those shared libraries. The software program is unaware of where these shared libraries (e.g., one or more shared libraries 214) are actually mapped into memory 206. Shared libraries are compiled into location-independent code (PIC) that can run at any address in memory.

[0033] On the other hand, static linking (e.g., using a static linker 210) is the result of the linker copying all library routines used in the software program / application 230 into the executable image / file. This may require more disk space and memory 206 than dynamic linking, but it is more portable because the program does not need the shared libraries to exist on the system it runs on. For example, when the executable (.exe) file of a program is clicked and it begins to run, all the necessary contents of the binary file have been loaded into the process's virtual address space. However, most programs also need to run functions from shared libraries from the system, and these library functions also need to be loaded. In the simplest case, the required library functions are directly embedded in the program's executable binary. Such a program is statically linked to its libraries, and statically linked executable code can start running as soon as it is loaded.

[0034] Debugger 240, or debugging tool, is a computer program used for testing and debugging other programs such as software program / application 230. Debugger 240 is configured to run software program / application 230 under controlled conditions that allow the programmer to trace its ongoing operations and monitor changes in computer resources (such as, for example, memory areas used by the program or the computer's operating system) that may indicate fault codes in the software program / application 230. Debugger 240 has the ability to run or pause the program at specific points, display the contents of memory, CPU registers (e.g., register 250), or storage devices (such as disk drives), and modify memory or register contents to input selected test data that may be the cause of erroneous program execution.

[0035] Computer system 202 includes a Global Offset Table (GOT) 208, which is part of the memory of computer programs (executables and shared libraries) to enable computer program code (e.g., compiled into an ELF file) to run correctly, regardless of the memory addresses at which program code or data is loaded at runtime. GOT 208 maps symbols in the programming code to their corresponding absolute memory addresses so that position-independent code (PIC) and position-independent executable code (PIE) are loaded into different memory addresses whenever the software program starts. Runtime memory addresses, also known as the absolute memory addresses of variables and functions, are unknown when the PIC or PIE code runs before the program starts; therefore, runtime memory addresses cannot be hard-coded by the compiler during compilation. GOT can be represented as .got and .got.plt sections in a file (e.g., an ELF file), which are loaded into the program's memory at startup. For example, the operating system's dynamic linker is used to update the Global Offset Table for relocation (symbols to absolute memory addresses) at program startup or when a symbol is accessed. GOT 208 is a mechanism that allows shared libraries (e.g., .so files) to be relocated to different memory addresses at startup and avoids memory address conflicts with the main program or other shared libraries. GOT 208 is an address table residing in the data section. GOT 208 converts position-independent address calculations into absolute addresses. The Procedure Linking Table (PLT) (not shown) is a table that redirects position-independent function calls to absolute addresses. The linker cannot resolve execution transfers, such as function calls between different dynamic objects. Therefore, the linker is configured to have program transfer control to enter the program linking table. Thus, the runtime linker redirects entries without compromising the position independence and shareability of the program text. Executable files and shared object files can have separate procedure linking tables.

[0036] Figure 3 This is a block diagram of an exemplary architectural flow 300 according to one or more embodiments of the present invention. Reference will be made to... Figure 2 The architecture flow 300 is described. As described above, software program / application 230 executes on computer system 202, and shared library 214 is subsequently updated and reloaded without stopping or pausing the execution of software program / application 230. In block 302, debugger 240 is configured to initiate a debug session for software program / application 230, and during the debug session, debugger 240 is configured to issue reload commands, such as reloading liba.so, for example, reloading shared library 214 since it has been updated. When software program / application 230 is executed, debugger 240 is configured to invoke and / or communicate with the software (API) associated with each of static linker 210, dynamic linker 212, GOT 208, and shared library 214, respectively, to execute as discussed herein.

[0037] Box 304 is configured to initiate / perform GOT 208 fill back by resetting the address previously resolved for shared library 214 (e.g., liba.so). For example, for a given GOT entry in GOT table 208, the old address 320 was previously already in the link address field of GOT 208 used for shared library 214 (e.g., Figure 5 The link address field 504 described in the diagram is resolved. The old address 320 was previously resolved by the dynamic linker 212. Because the shared library 214 was reloaded / updated, GOT 208 was configured to... Figure 5 The link address field 504 depicted in the diagram resets the old address 320 to the initial value 322, which is predefined as a default value. Furthermore, as seen here, performing GOT backfilling includes not only resetting the link address from the old address (the one initially linked to) to the initial value (i.e., the default value), but also (e.g., in...) Figure 5 In the parsing flag field 508 described in the text, the GOT parsing flag is reset from TRUE to FALSE.

[0038] In box 306, dynamic linker 212 is invoked again (i.e., later) to resolve the new address of shared library 214 (e.g., liba.so) because shared library 214 has been updated. In box 308, dynamic linker 212 is configured to perform dynamic loading. When a symbol defined in a dynamic library (e.g., liba.so) (e.g., the function foo) is invoked for the first time after the updated liba.so is reloaded, dynamic linker 212 performs the resolution of unresolved (relocated) entries by searching unresolved entry table 215 and symbol table 216 to find a match for the new address 324. For unresolved entries found in unresolved entry table 215, dynamic linker 212 searches in symbol table 216 and retrieves symbols used to resolve the new address of shared library 214 (liba.so). Using symbol table 216, dynamic linker 212 works to resolve symbols in shared library 214 (liba.so). Once the symbol is resolved, dynamic linker 212 updates the entries in index table 218 associated with shared library 214 (for resolved symbols). In block 310, dynamic linker 212 is configured to use the newly resolved address 324 (i.e., Figure 5 The new value of the link address field 504 described in the diagram is updated in GOT 208. Furthermore, the dynamic linker 212 (e.g., in...) updates GOT 208. Figure 5 In the parsing flag field 508 described in the text, the GOT parsing flag is set from FALSE to TRUE.

[0039] In box 312, dynamic linker 212 (or loader) is configured to load the newly resolved address of shared library 214 into memory space for use by software program / application 230. Memory space may be one or more locations in memory 206 used by software program / application 230, one or more registers 250 for the processor (such as processor 101), etc. An example output of debugger 240 and / or dynamic linker 212 may be input 330. Input 330 may include the library filename (e.g., liba.so) and / or another output file (e.g., a.out) from shared library 214. Figure 4This is a block diagram of an example flowchart 400 of a debugging session for a software program / application 230 according to one or more embodiments of the present invention. As described above, the software program / application 230 executes on computer system 202, and the shared library 214 will subsequently be updated and reloaded. In block 402, debugger 240 is configured to initiate a debugging session for the software program / application 230. In block 404, debugger 240 is configured to receive user input. User input may be authorization to continue debugging, specifying a particular code segment in the software program / application 230 to be inspected, etc. For example, the command “reload liba.so” may be entered by the user. In block 406, debugger 240 is configured to check whether a reload of the shared library 214 is required. When a reload is not required, the flow moves to block 410. When the shared library 214 has been updated, such as when one or more memory addresses have been changed (e.g., a new address replaces a previous address in the shared library 214), debugger 240 determines that a reload of the shared library 214 is required for the change / update to take effect. In one example, debugger 240 can receive a trigger or instruction that shared library 214 should be reloaded into memory 206.

[0040] At block 408, debugger 240 is configured to perform GOT backfilling and / or cause GOT backfilling to be performed. Specifically, during GOT backfilling, debugger 240 and / or another software tool are configured to backfill the GOT entry in GOT 208 corresponding to the updated address (or symbol), and thus GOT 208 is reset to have an initial value of 322 (e.g., an initial value of 0x80000000 as a default value). In one or more embodiments, debugger 240 may include GOT backfilling module 242 and / or other tools may include GOT backfilling module 242. GOT backfilling module 242 includes computer-executable instructions configured to perform GOT backfilling discussed herein. In one or more embodiments, GOT backfilling module 242 may be integrated with dynamic linker 212, GOT 208, and / or other software tools. At block 410, debugger 240 is configured to resolve new addresses and / or cause dynamic linker 212 to resolve new addresses. The loading process is triggered to resolve the unresolved address (which is the new address) of the reloaded shared library 214. Figure 3 Boxes 306 and 308 discuss resolving new addresses. In box 412, debugger 240 is configured to provide debugger output. Debugger 240 will output results based on user requests, such as which source line will stop after executing debugging commands like "continue," "next," etc. The debugger session terminates whenever the user exits the debugger program, for example, based on user input at box 404.

[0041] To perform GOT backfilling, one or more embodiments provide, as follows: Figure 5The new GOT 208 (i.e., the new global offset table) discussed in the document. Figure 5 As shown, example GOT 208 includes three columns. Offset 502 depicts which GOT entry is used to store the link address of a symbol defined in a dynamic library. For example, in this example, the offset may start at 0x00, and each GOT entry or entry (e.g., row) has 8 bytes. The first column depicts the link address field 504, which is the entry value containing the resolved link address of the GOT entry / entry in GOT 208. GOT 208 is expanded to include two new columns, which are the second and third columns according to one or more embodiments of the invention. For the expanded GOT fields, static linker 210 expands the size of the GOT entry or entry from, for example, 4 bytes to 8 bytes and introduces two new fields in the expanded 4 bytes: a dynamic library (DLL) index field and a resolution flag field. The second column depicts the DLL index field 506 once the linked module (i.e., shared library 214) is resolved. The third column depicts the resolution flag field 508, which indicates whether the module address (i.e., link address) has been resolved. By default, the resolution flag is set to "FALSE" and is set to "TRUE" when the loader (e.g., dynamic linker 212) resolves symbol addresses (of software program / application 230).

[0042] Figure 6 This is an example architecture flow 600 with further details of GOT backfilling according to one or more embodiments of the present invention. As discussed herein, software program / application 230 is executed on computer system 202 (e.g., during a debug session), and shared library 214 is subsequently updated and reloaded. At block 602, debugging or testing of software program / application 230 is initiated via debugger 240. During a debug session, the code of software program / application 230 may include functions that call shared library 214, such as the function bar() defined in liba.so. At block 604, debugger 240 (e.g., using GOT backfilling module 242) is configured to check whether the GOT entry or item in GOT 208 associated with the function call is equal to an initial value of a memory address. An example initial value (e.g., initial value 322) for the memory address (i.e., the link address in GOT 208) could be 0x80000000. If the memory address of the GOT entry or item called in GOT 208 is not an initial value, the process returns to box 602. If the memory address of the GOT entry or item called in GOT 208 is an initial value, the process proceeds to box 614, which will be discussed further below.

[0043] As described herein, after software program / application 230 has previously started execution, the memory address in shared library 214 has been updated and / or changed. Debugger 240 has started a debug session and has been notified of the update / change to shared library 214, for example, when shared library 214 is invoked. For example, a debugger command, such as “reload liba.so”, notifies debugger 240 that liba.so needs to be reloaded. Therefore, at box 606, without pausing and / or restarting software program / application 230, debugger 240 is configured to reload the updated shared library 214 (e.g., liba.so) and GOT 208. At box 608, debugger 240 is configured to check whether the GOT resolution flag in the resolution flag field 508 of a GOT entry or item is TRUE. For example, using GOT 208, debugger 240 can check the resolution flag field 508 of a GOT entry / item (i.e., line). When the GOT resolution flag for a GOT entry / item is FALSE, the flow proceeds to box 602. When the GOT resolution flag for a GOT entry / item is TRUE, debugger 240 is configured at box 610 to check whether the value of the DLL index in the DLL index field 506 for the GOT entry / item in GOT 208 is equal to the value of the DLL index for the corresponding entry / item in the DLL index table 218 for the shared library 214 (e.g., liba.so). When the value of the DLL index field 506 for the GOT entry / item in GOT 208 is not equal to the value of the corresponding entry / item in the DLL index table 218 for the shared library 214 (e.g., liba.so), the flow returns to box 602. When the value of the DLL index field 506 for the GOT entry / item in GOT 208 is equal to the value of the corresponding entry / item in the DLL index of the DLL index table 218 in shared library 214 (e.g., liba.so), debugger 240 is configured to perform GOT backfilling at box 612. As described here, the old link address (e.g., old address 320) in link address field 504 is pre-resolved using dynamic linker 212 before updating the corresponding memory address in shared library 214. Because shared library 214 is reloaded / updated, debugger 240 is configured to reset the link address in the link address field of the GOT entry / item for GOT 208 (e.g., resetting old address 320 to an initial value 322, such as 0x8000000) and reset the GOT resolution flag in the resolution flag field to FALSE (as mentioned above for box 304).

[0044] The process returns to box 602, where debugger 240 is configured to re-execute the call to `bar()` on `liba.so` (now the updated shared library 214). Returning to box 604, debugger 240 is configured to check whether the GOT entry or item associated with the function call (e.g., the call to `bar()`) is set to its initial value at a memory address (i.e., the link address in GOT 208). When the memory address of the called GOT entry or item in GOT 208 (e.g., ...) is... Figure 5 When the link address in the link address field 504 is an initial value (e.g., initial value 322), debugger 240 instructs or causes dynamic linker 212 to resolve the new link address in box 614. In box 616, dynamic linker 212 (e.g., caused by debugger 240) is configured to perform dynamic loading (e.g., as discussed above in box 308). Dynamic linker 212 searches the unresolved (relocated) entries table 215 for a match for the new address 324 to find unresolved entries. For an unresolved entry found in unresolved entries table 215, dynamic linker 212 searches and retrieves symbols in symbol table 216 for resolving the new address of shared library 214 (liba.so). Using symbol table 216, dynamic linker 212 works to resolve symbols in shared library 214 (liba.so). Once the symbols are resolved, dynamic linker 212 updates the entries in index table 218 associated with shared library 214 (for resolved symbols). In box 310, debugger 240 is configured to use the newly resolved address 324 (i.e., Figure 5 The debugger 240 updates GOT 208 by adding a new value to the link address field 504 as depicted in the diagram. Furthermore, the debugger 240 can set the GOT resolution flag from FALSE to TRUE. At box 618, the debugger 240 is configured to update GOT 208 and / or cause the dynamic linker 212 to update GOT 208. During the update of GOT entries or items in GOT 208, the debugger 240 and / or the dynamic linker 212 are configured to populate the link address in the link address field 504 with the new resolved address, update the DLL index in the DLL index field 506, and mark the resolution flag of the link address in the resolution flag field 508 as TRUE.

[0045] For purposes of explanation rather than limitation, in Figures 7-11 Example scenarios are discussed in the text. Figure 7This is a block diagram depicting the detailed actions performed by a dynamic linker and debugger according to one or more embodiments of the present invention. Typically, reloading a shared library requires stopping the execution of a program / application. However, if a typical system attempts to continue the execution of a program / application without stopping, the typical system will reload the recompiled shared library (e.g., liba.so). But the address of the called function (e.g., bar()) in the reloaded liba.so has changed from 0x7ff8100 (old shared library) to 0x7ff9100 (updated shared library). Since the address stored in the GOT entry in a typical system is not the default value (i.e., not 0x80000000), the program / application branches to 0x7ff8100, which is the original (old) load address of bar(), and this will cause the reloading of the shared library (e.g., liba.so) to have no effect on the typical system. Figure 7 In the context of using extended GOT 208 ( Figure 5As depicted in [the description], one or more embodiments are configured to reload shared library 214 without halting the execution of software program / application 230. Because shared library 214 has been updated, dynamic linker 212 is configured to assign a "1" to the DLL index in DLL index field 506 and mark the address resolution flag with TRUE in the GOT entry or item resolution flag field 508, as depicted in action 702. Furthermore, dynamic linker 212 assigns the resolved address of bar() to 0x7ff8100 as shown in the older version of shared library 214 (e.g., the older liba.so), and note that action 705 now points to the old address of shared library 214 (e.g., 0x7ff8100). While software program / application 230 is running, shared library 214 is reloaded or recompiled. For example, after recompiling shared library 214, debugger 240 reloads the updated shared library 214 (e.g., new liba.so) by issuing a command such as "reload liba.so" to invoke dynamic linker 212 (e.g., loader). In operation 704, debugger 240 obtains all mapped GOT entries or entries (i.e., GOT+0x28) by retrieving the GOT entry or entry with DLL index "1" in DLL index field 506, and if the resolution flag in resolution flag field 508 is TRUE, debugger 240 resets the link address stored in the target GOT entry / entry (e.g., GOT+0x28) (in link address field 504) to the default value (i.e., 0x80000000) and resets the address resolution flag to FALSE. In action 706, dynamic linker 212 is configured to assign a "1" to DLL index field 506 and mark the address resolution flag as TRUE in resolution flag field 508 for GOT entries / items. Then, when symbol bar is invoked again, the resolved address 0x7ff9100 of bar is assigned in link address field 504. The resolved address of bar (i.e., 0x7ff9100) is the link address to the updated shared library 214 (i.e., the new liba.so) rather than the old shared library (e.g., the old liba.so), and action 708 points to / links to the updated shared library 214. Note that... Figure 7 Example sections of software program / application 230 are shown, and example functions (e.g., bar()) are calls to the address of bar. Note that in Figure 7 and Figure 8 Typical actions / transformations used for sharing and actions (e.g., actions AK) using dynamic libraries of PLT and GOT are not depicted here because these actions / transformations are understood by those skilled in the art.

[0046] In order to provide information Figure 7Further details of action 702 in the film. Figure 8 This is a block diagram depicting linker actions performed by a dynamic linker according to one or more embodiments of the present invention. Figure 8 In action 802, dynamic linker 212 is configured to obtain the resolved address after loading shared library 214 (e.g., liba.so) and resolve the address of the called function bar. In action 804, dynamic linker 212 is configured to update the contents of bar's GOT +0x28 (i.e., GOT entry / item) with 0x7ff8100 in link address field 504. In action 806, for GOT entry / item, dynamic linker 212 is configured to assign a "1" to the DLL index and mark the address of the resolution flag with TRUE in both DLL index field 506 and resolution flag field 508.

[0047] Extend Figure 7 and Figure 8 , Figure 9 This is a block diagram depicting GOT backfilling according to one or more embodiments of the present invention. As described herein, debugger 240 invokes dynamic linker 212 (e.g., loader) to reload the updated shared library 214 (e.g., liba.so) by issuing a command (i.e., reload liba.so) after recompiling shared library 214, and dynamic linker 212 obtains the DLL index by searching DLL index / table 218. In action 902, dynamic linker 212 obtains all mapped GOT entries / items (i.e., GOT +0x28) by retrieving GOT entries / items with DLL index "1" in their respective DLL index fields 506. Figure 9 Action 904, for GOT entries / items in GOT 208, if the resolution flag is TRUE, then backfill module 242 (e.g., Figure 3 In box 304, the address stored in the target GOT entry / item (e.g., GOT +0x28) is reset with a default value (i.e., 0x80000000) in the link address field 506, and the address resolution flag is reset to FALSE in the resolution flag field 508.

[0048] To illustrate further use of GOT 208, Figure 10This is a block diagram depicting further loader actions according to one or more embodiments of the present invention. Dynamic linker 212 performs an address resolution process to update the new address from the recompiled shared library 214, as discussed herein. For example, in action 1002, if software program / application 230 calls bar() again, dynamic linker 212 resolves the function bar address again because the address stored in GOT+0x28 is the default value 0x8000000. In action 1004, dynamic linker 212 updates the link address in GOT+0x28 with the new bar address 0x7ff910, assigns a "1" to the DLL index, and marks the resolution flag as TRUE in the GOT entry / entry. The old address (0x7ff8100) of shared library 214 has been updated to the new address in the GOT entry / entry of GOT 208 (i.e., the new link address 0x7ff9100). The index field can be the value "-1", where "-1" is the initial value of the library index field. The index field can have the value "1", which means library index 218, that is, the library index of liba.so is 1.

[0049] To illustrate the use of the updated GOT 208 and PTL, Figure 11 This is a block diagram depicting, according to one or more embodiments of the invention, a direct branch to a new address (e.g., new address 324 in link address field 504) when the function is subsequently called. In operation 1102, software program / application 230 is compiled, and a PLT is used to redirect position-independent function calls to absolute locations. In operation 1104, when bar() is called again (later), the instruction “b @ GOT +0X28” will jump directly to 0X7ff9100 because the value stored in GOT +0X28 is the new address 0X7ff9100.

[0050] Technical advantages and benefits include one or more embodiments that allow the software program / application and / or debugging process to continue execution without interrupting the software program / application or debugging process when updating dynamic libraries. According to one or more embodiments, performance is unaffected by the fact that the execution of the software program / application does not need to be stopped, paused, or halted, because the static linker does not require additional instruction generation, and the dynamic linker (e.g., the loader) does not take any extra action. Further technical advantages and benefits include reduced time and effort for software programmers during software program / application development / testing and during root cause localization, especially in complex scenarios, while providing software programmers with more flexible testing and debugging methods.

[0051] Figure 12This is a flowchart of a method 1200 for reloading an updated shared library without stopping the execution of a software program / application 230, according to one or more embodiments of the present invention. At block 1202, debugger 240 is configured via processor 101 to execute the software program / application 230 that requires function calls to the shared library 214 (e.g., bar()) and / or to cause the software program / application 230 to be executed. At block 1204, debugger 240 is configured and / or to cause dynamic linker 212 to reload the shared library 214 without stopping the execution of the software program / application 230, wherein the shared library 214 has been updated after the execution of the software program. At box 1206, debugger 240 is configured to update the Global Offset Table (GOT) 208 in response to resolving the link address associated with a function call. Entries in GOT 208 include a link address field 504, an index field 506, and a resolution flag field 508. For each entry in GOT 208, the update includes updating the index field with a positive value (e.g., "1") and marking the resolution field with a positive flag (e.g., "TRUE"). At box 1208, debugger 240 is configured to, and / or cause dynamic linker 212 to, find entries in GOT 208 that have a positive value (e.g., "1") in the index field and a positive flag (e.g., "TRUE") in the resolution field in response to reloading shared library 214 without stopping the execution of software program / application 230. In box 1210, debugger 240 is configured and / or causes dynamic linker 212 to return the address value in the link address field of the entry that has a positive value in the index field in response to subsequent execution of a function call to shared library 214.

[0052] Before updating GOT 208, the link address field is set to a default value (e.g., 0x80000000). Before updating GOT 208, if the resolution field previously contained a positive value (e.g., TRUE), the resolution field is marked as a negative value (e.g., FALSE). Reloading shared library 214 without stopping the execution of software program / application 230 includes resolving the new address of the updated shared library 214 (e.g., 0x7FF9100). Updating GOT 208 includes replacing the default value in the link address field with the new address after resolving the new address. The address value in the link address field is the new address that has been resolved for shared library 214. Before reloading shared library 214, during the execution of software program / application 230, shared library 214 is initially / preloaded for use in function calls to the shared library.

[0053] Figure 13This is a flowchart of a method 1300 for performing a shared library reload for updating without stopping the execution of software program / application 230, according to one or more embodiments of the present invention. At block 1302, debugger 240 is configured to and / or cause dynamic linker 212 to reload shared library 214 without stopping the execution of software program / application 230 that calls shared library 214. At block 1304, debugger 240 is configured to, in response to a resolved link address to shared library 214 (e.g., link address field 504), update index fields (e.g., DLL index field 506) with a positive value (e.g., "1") for entries in the Global Offset Table (GOT) and mark resolution fields (e.g., resolution flag field 508) with a positive flag (e.g., TRUE). At block 1306, debugger 240 is configured to, in response to reloading the shared library without stopping the execution of the software program, find an entry in GOT 208 with a resolved link address for shared library 214.

[0054] It should be understood that although this disclosure includes a detailed description of cloud computing, the implementation of the teachings set forth herein is not limited to a cloud computing environment. Rather, embodiments of the invention can be implemented in conjunction with any other type of computing environment now known or developed hereafter.

[0055] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with service providers. This cloud model may include at least five features, at least three service models, and at least four deployment models.

[0056] The features are as follows: On-demand self-service: Cloud consumers can unilaterally and automatically provide computing power, such as server time and network storage, as needed, without requiring human interaction with the service provider.

[0057] Extensive network access: the capabilities available on the network and accessed through standard mechanisms that facilitate the use of heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0058] Resource pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically allocated and reallocated based on demand. In a sense, it is location-independent because consumers typically do not control or know the exact location of the resources offered, but can specify the location at a higher level of abstraction (e.g., country, state, or data center).

[0059] Rapid and flexible: In some cases, the ability to scale outwards and inwards can be provided automatically, quickly, and flexibly. For consumers, the available capacity often appears unlimited and can be purchased in any quantity at any time.

[0060] Measurement services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a level of abstraction appropriate to the service type (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the service providers and consumers.

[0061] The service model is as follows: Software as a Service (SaaS): This provides consumers with the ability to use a provider's applications running on cloud infrastructure. Applications can be accessed from various client devices through thin client interfaces such as web browsers (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including the network, servers, operating system, storage, or even individual application capabilities, with possible exceptions such as limited user-specific application configuration settings.

[0062] Platform as a Service (PaaS): This provides consumers with the ability to deploy consumer-created or acquired applications onto cloud infrastructure using programming languages ​​and tools supported by the vendor. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but they have control over the deployed applications and the configuration of any application hosting environments.

[0063] Infrastructure as a Service (IaaS): This provides consumers with the capability to deliver processing, storage, networking, and other basic computing resources that enable them to deploy and run arbitrary software, which may include operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but they do have control over the operating system, storage, deployed applications, and possibly limited control over selected networking components (e.g., host firewalls).

[0064] The deployment model is as follows: Private cloud: Cloud infrastructure operated solely by an organization. It can be managed by the organization or a third party and can exist inside or outside a building.

[0065] Community cloud: A cloud infrastructure shared by several organizations and supporting a specific community with shared concerns (e.g., tasks, security requirements, policies, and compliance considerations). It can be managed by an organization or a third party and can reside inside or outside a building.

[0066] Public cloud: Cloud infrastructure available to the general public or large industrial groups and owned by organizations that sell cloud services.

[0067] Hybrid cloud: A cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain a single entity but are bound together by standardized or proprietary technologies that enable data and applications to be ported together (e.g., cloud bursting for load balancing between clouds).

[0068] Cloud computing environments are service-oriented, focusing on statelessness, loose coupling, modularity, and semantic interoperability. At the heart of cloud computing is the infrastructure of a network of interconnected nodes.

[0069] Now for reference Figure 14 The diagram illustrates an illustrative cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 to which local computing devices used by cloud consumers can communicate, such as, for example, personal digital assistants (PDAs) or cellular phones 54A, desktop computers 54B, laptop computers 54C, and / or automotive computer systems 54N. The nodes 10 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks, such as private clouds, community clouds, public clouds, or hybrid clouds, or combinations thereof, as described above. This allows the cloud computing environment 50 to provide infrastructure, platforms, and / or software as services that cloud consumers do not need to maintain on their local computing devices. It should be understood that... Figure 14 The types of computing devices 54A-54N shown are intended to be illustrative only, and computing node 10 and cloud computing environment 50 can communicate with any type of computerized device via any type of network and / or network-addressable connection (e.g., using a web browser).

[0070] Now for reference Figure 15 This demonstrates a cloud computing environment of 50 ( Figure 14 This provides a set of functional abstraction layers. It should be understood beforehand that... Figure 15 The components, layers, and functions shown are intended to be illustrative only, and embodiments of the invention are not limited thereto. As depicted, the following layers and corresponding functions are provided: The hardware and software layer 60 includes hardware and software components. Examples of hardware components include: a host 61; a server 62 based on a RISC (Reduced Instruction Set Computer) architecture; a server 63; a blade server 64; a storage device 65; and a network and network components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0071] The virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual server 71; virtual storage 72; virtual network 73, including virtual private network; virtual application and operating system 74; and virtual client 75.

[0072] In one example, management layer 80 may provide the following functionalities: Resource Provisioning 81 provides dynamic procurement of computing resources and other resources used to perform tasks within the cloud computing environment. Metering and Pricing 82 provides cost tracking as resources are utilized in the cloud computing environment and bills or invoices for the consumption of these resources. In one example, these resources may include application software licenses. Security provides authentication for cloud consumers and tasks, as well as protection for data and other resources. User Portal 83 provides access to the cloud computing environment for consumers and system administrators. Service Level Management 84 provides cloud resource allocation and management to meet required service levels. Service Level Agreement (SLA) Planning and Fulfillment 85 provides pre-scheduling and procurement of cloud resources based on anticipated future needs according to the SLA.

[0073] Workload layer 90 provides examples of functionalities that can leverage a cloud computing environment. Examples of workloads and functionalities that can be provided from this layer include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analytics and processing 94; transaction processing 95; and software applications 96 (e.g., software programs / applications 230, debuggers 240, static linkers 210, dynamic linkers 212, and backfill modules 242). Furthermore, software applications can work and / or integrate with resource provision 81.

[0074] Various embodiments of the invention are described herein with reference to the accompanying drawings. Alternative embodiments of the invention may be designed without departing from the scope of the invention. In the following description and drawings, various connections and positional relationships (e.g., above, below, adjacent, etc.) are illustrated between elements. Unless otherwise stated, these connections and / or positional relationships may be direct or indirect, and the invention is not intended to be limiting in this respect. Thus, coupling of entities may refer to direct or indirect coupling, and positional relationships between entities may be direct or indirect positional relationships. Furthermore, the various tasks and process steps described herein may be incorporated into a more comprehensive program or process with additional steps or functionality not described in detail herein. One or more methods described herein can be implemented using any of the following techniques known in the art, or combinations thereof: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) with appropriately combined logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0075] For the sake of brevity, conventional techniques associated with the manufacture and use of various aspects of the present invention may or may not be described in detail herein. In particular, various aspects of the computing systems and specific computer programs used to implement the various technical features described herein are well known. Therefore, for the sake of brevity, many conventional implementation details are only briefly mentioned or omitted entirely herein, without providing well-known system and / or process details.

[0076] In some embodiments, various functions or actions may occur at a given location and / or in combination with the operation of one or more devices or systems. In some embodiments, a portion of a given function or action may be performed at a first device or location, and the remainder of the function or action may be performed at one or more additional devices or locations.

[0077] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the terms “comprising” and / or “including” as used in this specification designate the presence of the stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0078] All means or steps plus functional elements in the following claims are intended to include corresponding structures, materials, actions, and equivalents for performing functions in combination with other claimed elements as specifically claimed. This disclosure is presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the forms disclosed. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of this disclosure. The embodiments were chosen and described in order to best explain the principles and practical application of this disclosure and to enable others skilled in the art to understand this disclosure with various embodiments having various modifications suitable for the particular purpose contemplated.

[0079] The diagrams described herein are illustrative. Numerous variations of the diagrams or steps (or operations) described herein may exist without departing from the scope of this disclosure. For example, actions may be performed in a different order, or actions may be added, deleted, or modified. Furthermore, the term "coupled" describes a signal path between two elements and does not imply a direct connection between elements where there are no intermediate elements / connections between them. All such variations are considered part of this disclosure.

[0080] The following definitions and abbreviations are used to interpret the claims and specification. As used herein, the terms “comprising,” “including,” “having,” “containing,” or any other variations thereof are intended to cover a non-exclusive inclusion. For example, a composition, mixture, process, method, article, or apparatus that comprises a list of elements is not necessarily limited to those elements, but may include other elements not expressly listed or inherent to such compositions, mixtures, processes, methods, articles, or apparatus.

[0081] Additionally, the term "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs. The terms "at least one" and "one or more" are understood to include any integer greater than or equal to one, i.e., one, two, three, four, etc. The term "multiple" should be understood to include any integer greater than or equal to two, i.e., two, three, four, five, etc. The term "connection" can include both indirect "connection" and direct "connection."

[0082] The terms “about,” “substantially,” “approximately,” and variations thereof are intended to include a degree of error associated with a measurement of a specific quantity based on the equipment available at the time of filing this application. For example, “about” may include a range of ±8%, 5%, or 2% of a given value.

[0083] This invention can be a system, method, and / or computer program product at any possible level of technical detail integration. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to perform aspects of the invention.

[0084] Computer-readable storage media can be tangible devices capable of retaining and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable optical disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices such as punch cards or recessed structures with instructions recorded thereon, and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0085] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a suitable computing / processing device, or via a network, such as the Internet, a local area network (LAN), a wide area network (WAN), and / or a wireless network, to an external computer or external storage device. The network may include copper cables, optical fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to a computer-readable storage medium within the respective computing / processing device.

[0086] Computer-readable program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages ​​(including object-oriented programming languages ​​such as Smalltalk, C++, etc.) and procedural programming languages ​​(such as the "C" programming language or similar programming languages). The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, to perform aspects of this invention, electronic circuits, including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute computer-readable program instructions to personalize the electronic circuits by utilizing the status information of the computer-readable program instructions.

[0087] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0088] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / actions specified in one or more blocks of a flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other devices to operate in a particular manner, such that the computer-readable storage medium in which the instructions are stored includes an article of writing comprising instructions for implementing aspects of the functions / actions specified in one or more blocks of a flowchart and / or block diagram.

[0089] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer-implemented process, such that the instructions, which execute on the computer, other programmable apparatus or other device, perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0090] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions comprising one or more executable instructions for implementing a specified logical function. In some alternative embodiments, the functions indicated in the blocks may occur in a non-consecutive order as shown in the figures. For example, two blocks shown consecutively may actually be executed substantially simultaneously, or these blocks may sometimes be executed in reverse order, depending on the functions involved. It will also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs the specified function or action or executes a combination of dedicated hardware and computer instructions.

[0091] Various embodiments of the invention have been described for illustrative purposes, but are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the described embodiments. The terminology used herein has been chosen to best explain the principles of the embodiments, their practical application, or improvements to existing technologies on the market, or to enable others skilled in the art to understand the embodiments described herein.

Claims

1. A computer-implemented method, comprising: The processor executes software programs that require function calls from shared libraries; The shared library, which has been updated after the execution of the software program, is reloaded without stopping the execution of the software program. In response to resolving the link address associated with the function call, the Global Offset Table (GOT) is updated. Entries in the GOT include a link address field, an index field, and a resolution field. The update includes, for each entry in the GOT, updating the index field with a positive value and marking the resolution field with a positive flag. In response to reloading the shared library without halting the execution of the software program, the entry in the GOT that has a positive value in the index field and a positive flag in the parsing field is found; and In response to subsequent execution of the function call to the shared library, the address value in the link address field of the entry that has a positive value in the index field is returned.

2. The computer-implemented method according to claim 1 further includes setting the link address field to a default value before updating the GOT.

3. The computer-implemented method of claim 1 further includes, before updating the GOT, marking the parsed field with a non-affirmative value if the parsed field previously contained the affirmative value.

4. The computer-implemented method according to claim 1, wherein, Reloading the shared library without stopping the execution of the software program includes resolving the new address of the updated shared library.

5. The computer-implemented method according to claim 4, wherein, Updating the GOT includes replacing the default value in the link address field with the new address.

6. The computer-implemented method according to claim 4, wherein, The address value in the link address field is a new address that has been resolved for the shared library.

7. The computer-implemented method according to claim 1, wherein, Before reloading the shared library, the shared library is initially loaded during the execution of the software program for use in calling the functions of the shared library.

8. A computer system, comprising: A memory containing computer-readable instructions; as well as One or more processors are used to execute the computer-readable instructions, which control the one or more processors to perform operations including: Execute software programs that require function calls from shared libraries; The shared library, which has been updated after the execution of the software program, is reloaded without stopping the execution of the software program. In response to resolving the link address associated with the function call, the Global Offset Table (GOT) is updated. Entries in the GOT include a link address field, an index field, and a resolution field. The update includes, for each entry in the GOT, updating the index field with a positive value and marking the resolution field with a positive flag. In response to reloading the shared library without halting the execution of the software program, the entry in the GOT that has a positive value in the index field and a positive flag in the parsing field is found; and In response to subsequent execution of the function call to the shared library, the address value in the link address field of the entry that has a positive value in the index field is returned.

9. The computer system of claim 8 further includes setting the link address field to a default value before updating the GOT.

10. The computer system of claim 8, further comprising, before updating the GOT, marking the parsed field with a non-affirmative value if the parsed field previously contained the affirmative value.

11. The computer system according to claim 8, wherein, Reloading the shared library without stopping the execution of the software program includes resolving the new address of the updated shared library.

12. The computer system according to claim 11, wherein, Updating the GOT includes replacing the default value in the link address field with the new address.

13. The computer system according to claim 11, wherein, The address value in the link address field is a new address that has been resolved for the shared library.

14. The computer system according to claim 8, wherein, Before reloading the shared library, the shared library is initially loaded during the execution of the software program for use in calling the functions of the shared library.

15. A computer program product comprising program instructions executable by a processor to cause the processor to perform operations including: Execute software programs that require function calls from shared libraries; The shared library, which has been updated after the execution of the software program, is reloaded without stopping the execution of the software program. In response to resolving the link address associated with the function call, the Global Offset Table (GOT) is updated. Entries in the GOT include a link address field, an index field, and a resolution field. The update includes, for each entry in the GOT, updating the index field with a positive value and marking the resolution field with a positive flag. In response to reloading the shared library without halting the execution of the software program, the entry in the GOT that has a positive value in the index field and a positive flag in the parsing field is found; and In response to subsequent execution of the function call to the shared library, the address value in the link address field of the entry that has a positive value in the index field is returned.

16. The computer program product of claim 15, further comprising setting the link address field to a default value before updating the GOT.

17. The computer program product of claim 15, further comprising, before updating the GOT, marking the parsed field with a non-affirmative value if the parsed field previously contained the affirmative value.

18. The computer program product according to claim 15, wherein, Reloading the shared library without stopping the execution of the software program includes resolving the new address of the updated shared library.

19. The computer program product according to claim 18, wherein, Updating the GOT includes replacing the default value in the link address field with the new address.

20. The computer program product according to claim 18, wherein, The address value in the link address field is a new address that has been resolved for the shared library.

21. A computer-implemented method, comprising: Reload the shared library without stopping the execution of the software program that calls the shared library; In response to the link address resolved to the shared library, for entries in the Global Offset Table (GOT), the index field is updated with a positive value and the resolved field is marked with a positive flag; as well as In response to reloading the shared library without halting the execution of the software program, an entry with a link address resolved for the shared library is found in the GOT.

22. The computer-implemented method according to claim 21, wherein, An entry with a resolved link address for the shared library is found in the GOT in response to subsequent execution of a call to the shared library.

23. The computer-implemented method of claim 21, further comprising setting the link address to a default value before updating the index field with an affirmative value for an entry in the GOT and marking the parsing field with an affirmative flag.

24. The computer-implemented method of claim 21, further comprising, before updating the index field with an affirmative value for an entry in the GOT and marking the parsing field with an affirmative flag, marking the parsing field with a non-affirmative value if the parsing field previously contained the affirmative value.

25. A computer system, comprising: A memory containing computer-readable instructions; as well as One or more processors are used to execute the computer-readable instructions, which control the one or more processors to perform operations including: Reload the shared library without stopping the execution of the software program that calls the shared library; In response to the link address resolved to the shared library, for entries in the Global Offset Table (GOT), the index field is updated with a positive value and the resolved field is marked with a positive flag; as well as In response to reloading the shared library without halting the execution of the software program, an entry with a link address resolved for the shared library is found in the GOT.

26. The computer system according to claim 25, wherein, An entry with a resolved link address for the shared library is found in the GOT in response to subsequent execution of a call to the shared library.

Images