Reloading of an Updated Shared Library Without Stopping Application Execution

Abstract

The technique includes executing a software program that includes a function call to a shared library and reloading the shared library without stopping execution of the software program. In response 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 resolved field, and updating includes updating the index field with a positive value and marking the resolved field with a positive flag for the entry in the GOT. In response to reloading the shared library, an entry in the GOT that includes a positive value in the index field and a positive flag in the resolved field is found. In response to a subsequent execution of the function call to the shared library, the address value in the link address field of the entry that includes a positive value in the index field is returned.

Description

Technical Field

[0001] The present invention generally relates to computer systems, and more particularly to computer systems, computer-implemented methods, and computer program products for performing a reload of an updated shared library without stopping the execution of an application.

Background Art

[0002] In computing, position-independent code or position-independent executable files are the machine language body and are placed somewhere within the primary memory and are properly executed regardless of their absolute address. The term absolute address refers to a numerical value that identifies a physically fixed position within the actual storage in terms of the number of bytes from the beginning, or a physically fixed position within a peripheral device in terms of a disk, sector, and byte. Position-independent code is generally used for shared libraries so that the same library code can be loaded at a certain position within the address space of each program where it does not overlap with any other use of memory (e.g., other shared libraries). A shared library or shared object is a file intended to be shared by executable files and further shared object files. The modules used by a program are not copied by a linker when creating a single monolithic executable file for the program, but are read into memory from individual shared objects at load time or execution time. In particular, a shared library is a library that is read by a program at the start of the program. When a shared library is properly installed, all programs that start thereafter automatically use the new shared library. A shared library can be statically linked at compile time (i.e., when the executable file is created, references to library modules are resolved and memory is allocated to the modules) or can be dynamically linked later.

[0003] When using a shared library, problems or issues may occur when the shared library is updated. For example, while the program is running, if the source code in the shared library is updated, the compilation options used are changed, the search path is changed, or a combination of these occurs, there may be problems even if explicit independent code is being used. In such cases, the user has to stop the execution or debugging of the program and reload the software program in order to enable the updated shared library.

Summary of the Invention

[0004] Embodiments of the present invention are directed to performing a reload of an updated shared library without stopping the execution of an application. A non-limiting, exemplary computer-implemented method includes executing, by a processor, a software program that requires function calls to a shared library and reloading the shared library without stopping the execution of the software program, where the shared library has 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 a function call,

[0005] Entries in the GOT include a link address field, an index field, and a resolved field, and updating involves updating the index field with a positive value and marking the resolved field with a positive flag for an entry in the GOT. The computer-implemented method includes finding an entry in the GOT that includes a positive value in the index field and a positive flag in the resolved field in response to reloading a shared library without stopping the execution of the software program. The computer-implemented method also includes returning the address value in the link address field of an entry that includes a positive value in the index field in response to a subsequent execution of a function call to the shared library.

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

[0007] In addition to, or as an alternative to, one or more of the features described above or below, further embodiments can include marking the resolved field with a non-positive value if the resolved field already includes a positive value before updating the GOT.

[0008] In addition to, or as an alternative to, one or more of the features described above or below, further embodiments can include cases where reloading a shared library without stopping the execution of the software program includes resolving the new address of the updated shared library.

[0009] In addition to, or as an alternative to, one or more of the features described above or below, further embodiments can include cases where updating the GOT includes replacing the default value in the link address field with the new address.

[0010] In addition to, or as an alternative to, one or more of the features described above or below, further embodiments can include cases where the address value in the link address field is the new resolved address of the shared library.

[0011] In addition to, or as an alternative to, one or more of the features described above or below, further embodiments can include cases where the shared library is first loaded for a function call to the shared library during the execution of a software program, before the shared library is reloaded.

[0012] In addition to, or as an alternative to, one or more of the features described above or below, further embodiments can include performing a reload of the updated shared library without stopping the execution of the software program / application.

[0013] In addition to, or as an alternative to, one or more of the features described above or below, further embodiments can include expanding the size of the global offset table using a new library index field and a new address-resolved flag field to account for reloading the updated shared library.

[0014] A non-limiting, exemplary system includes a memory containing computer-readable instructions and one or more processors for executing the computer-readable instructions. The computer-readable instructions execute a software program that requires a function call to a shared library and perform operations including reloading the shared library without stopping the execution of the software program, where the shared library has 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, where entries in the GOT include a link address field, an index field, and a resolved field, and updating includes updating the index field with a positive value and marking the resolved field with a positive flag for entries in the GOT. The operations include finding an entry in the GOT that includes a positive value in the index field and a positive flag in the resolved field in response to reloading the shared library without stopping the execution of the software program. Also, the operations include returning an address value in the link address field of an entry that includes a positive value in the index field in response to a subsequent execution of a function call to the shared library.

[0015] Non-limiting examples include a computer program product comprising a computer-readable storage medium in which program instructions are embodied, 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 stopping execution of the software program, where the shared library has been updated after execution of the software program. The operations include updating a Global Offset Table (GOT) in response to resolving a link address associated with a function call, where entries in the GOT include a link address field, an index field, and a resolved field, and updating includes updating the index field with a positive value and marking the resolved field with a positive flag for an entry in the GOT. The operations include finding an entry in the GOT that includes a positive value in the index field and a positive flag in the resolved field in response to reloading the shared library without stopping execution of the software program. The operations also include returning an address value in a link address field of an entry that includes a positive value in the index field in response to subsequent execution of a function call to the shared library.

[0016] Non-limiting examples include a computer-implemented method including reloading a shared library without stopping execution of a software program that calls the shared library. The computer-implemented method includes 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) in response to resolving a link address to the shared library. The computer-implemented method includes finding an entry in the GOT that includes the resolved link address of the shared library in response to reloading the shared library without stopping execution of the software program.

[0017] Non-limiting examples include a system comprising a memory containing 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 a shared library without stopping the execution of a software program that calls the shared library. The operations include, 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 operations include finding an entry in the GOT that contains the resolved link address of the shared library in response to reloading the shared library without stopping the execution of the software program.

[0018] Other embodiments of the invention implement the features of the foregoing method in a computer system and a computer program product.

[0019] Other technical features and advantages are realized by the technology of the present invention. Embodiments and aspects of the present invention are described in detail herein and are considered part of the claimed subject matter. Refer to the detailed description and the drawings for a better understanding.

[0020] The details of the rights described herein are specifically pointed out and clearly claimed in the claims at the end of this specification. The foregoing and other features and advantages of embodiments of the present invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings.

Brief Description of the Drawings

[0021]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 14

Figure 15

DETAILED DESCRIPTION OF THE INVENTION

[0022] One or more embodiments of the present invention perform a reloading of an updated shared library without stopping the execution of the target program / application. One or more embodiments of the present invention provide a technique for seamlessly reloading an updated dynamic library called by a software program / application when a debugger or other tool triggers a library reloading operation. According to one or more embodiments, a static linker is configured to extend the size of global offset table (GOT) entries using a new library index field and a new resolved flag field. A debugger or other tool reloads the updated dynamic library, examines the library index field of the GOT, and then resets the link address (using the default value) and the resolved flag (using the default value) stored in the matching GOT entry where the previous resolved flag is TRUE. Therefore, when an 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 effectively reload an updated dynamic shared library without stopping the execution or debugging of a software program / application that calls the API of the updated dynamic library. Thus, this beneficial technique not only helps users solve questions / requests / inputs more quickly and efficiently, but also provides users with a way to perform more flexible testing or debugging or both.

[0023] One or more embodiments address the problem that occurs in the current art where, even if distinct and independent code is being used, after an application has been run, if the source code within a shared library has been updated, the compilation options being used have been changed, or the search path has been changed, or a combination thereof has occurred, the user has to stop the execution or debugging of the software program / application and reload the software program / application in order to enable the updated shared library. The reason for stopping the software program / application is that, during the execution of the software program / application, if a dynamically shared library that has been updated with a different address is loaded, the current loader cannot effectively resolve the link address. Such frequent restart operations during program / application development and bug hunting are cumbersome for developers and, especially in the case of programs / applications that contain very complex (long) source code, waste time. However, one or more embodiments of the present invention provide a new and innovative method to address this situation, thereby introducing an effective method for seamlessly reloading an updated dynamic library without pausing or stopping the execution or debugging of the running program / application.

[0024] Referring now to FIG. 1, in accordance with one or more embodiments of the present invention, a computer system 100 is generally shown. The computer system 100 can be an electronic computer framework that includes, or employs, or both, any number and combination of computing devices and networks that utilize various communication technologies, as described herein. The computer system 100 can be made easily scalable, extensible, modular, and capable of reconfiguring some functions independently of the ability to vary for different services or other functions. The computer system 100 can be, for example, a server, a desktop computer, a laptop computer, a tablet computer, or a smartphone. In some examples, the computer system 100 can be a cloud computing node. The computer system 100 can be described in the general context of executable instructions by a computer system, such as program modules executed by the computer system. Generally, program modules can include routines, programs, objects, components, logic, data structures, etc., that perform particular tasks or implement particular abstract data types. The computer system 100 can be practiced in a distributed cloud computing environment where tasks are executed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules can be located in both local and remote computer system storage media, including a memory storage device.

[0025] As shown in FIG. 1, computer system 100 includes one or more central processing units (CPUs) 101a, 101b, 101c, etc. (collectively or generally referred to as processor 101). Processor 101 can be a single-core processor, a multi-core processor, a computing cluster, or any number of other configurations. Processor 101, also called a processing circuit, is coupled to system memory 103 and various other components via system bus 102. System memory 103 can 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) that controls certain basic functions of computer system 100 or its successor such as a Unified Extensible Firmware Interface (UEFI). RAM is a read-write memory coupled to system bus 102 for use by processor 101. System memory 103 provides a temporary memory space for the operation of the aforementioned instructions during operation. System memory 103 can include random access memory (RAM), read only memory, flash memory, or any other suitable memory system.

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

[0027] Software 111 for execution on computer system 100 may be stored in mass storage 110. Mass storage 110 is an example of a tangible storage medium readable by processor 101, and software 111 is stored as instructions for execution by processor 101 to cause computer system 100 to operate as described hereinafter herein with respect to various figures. Examples of computer program products and execution of such instructions are described in more detail herein. Communication adapter 107 interconnects system bus 102 with a 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 110 collectively stores an operating system, which may be any suitable operating system, for coordinating the functions of the various components shown in FIG. 1.

[0028] Other input / output devices are shown as being connected to 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, which are connected to system bus 102 via an intermediate bus bridge (not shown). A display 119 (e.g., a screen or display monitor) is connected to system bus 102 by display adapter 115, and display adapter 115 may include a graphics controller to improve the performance of graphics-intensive applications and video controllers. A keyboard 121, mouse 122, speaker 123, etc. can be interconnected to system bus 102 via interface adapter 116. For example, interface adapter 116 may include a Super I / O chip that integrates multiple device adapters into a single integrated circuit. I / O buses suitable for connecting peripheral devices such as hard disk controllers, network adapters, and graphics adapters typically include common protocols such as PCI (Peripheral Component Interconnect) and PCIe (Peripheral Component Interconnect Express). Thus, as configured in FIG. 1, computer system 100 includes processing capabilities in the form of processor 101, storage capabilities including system memory 103 and mass storage 110, input means such as keyboard 121 and mouse 122, and output capabilities including speaker 123 and display 119.

[0029] In some embodiments, communication adapter 107 can transmit data using any suitable interface or protocol, such as the Internet, Small Computer System Interface, etc. Network 112 can be, in particular, a cellular network, a wireless network, a wide area network (WAN), a local area network (LAN), or the Internet. An external computing device can be connected to computer system 100 via network 112. In some examples, the external computing device can be an external web server or a cloud computing node.

[0030] It should be understood that the block diagram of FIG. 1 is not intended to show that computer system 100 will include all of the components shown in FIG. 1. Rather, computer system 100 can include any suitable fewer or additional components not shown in FIG. 1 (e.g., additional memory components, embedded controllers, modules, additional network interfaces, etc.). Further, the embodiments described herein with respect to computer system 100 can be implemented using any suitable logic, which, when referred to herein, can include any suitable hardware (e.g., in particular, a processor, an embedded controller, or an application specific integrated circuit), software (e.g., in particular, an application), firmware, or any suitable combination of hardware, software, and firmware in various embodiments.

[0031] FIG. 2 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. FIG. 2 shows one or more computer systems 202. For example, computer system 202 can represent a number of computers within a data center that provides services to various users. The elements of computer system 100 may be used within computer system 202, integrated into computer system 202, or both. 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 utilize software 111 executed on one or more processors 101, are implemented as software 111, or both, as described with respect to FIG. 1.

[0032] Software program / application 230 is executed on computer system 202, and software program / application 230 uses shared library 214 as part of its execution, requires access to shared library 214, or both. The shared library may have a special name called "soname". Soname includes the prefix "lib", the name of the library, the phrase ".so", followed by a period and a version number that is incremented each time the interface changes. The fully qualified soname may include, as a prefix, the directory in which the soname exists. In a running system, the fully qualified soname is simply a symbolic link to the "actual name" of the shared library. The actual name is the file name that contains the actual library code.

[0033] In computing, a linker or link editor, such as static linker 210 and dynamic linker 212, is a program of a computer system that takes one or more object files (produced by a compiler or assembler) and combines them into a single executable file, library file, or another "object" file. A computer program, such as software program / application 230, is typically composed of multiple parts or modules. These parts / modules do not all have to be contained within a single object, and in such cases, when linked for execution, symbols (e.g., in symbol table 216) are used as addresses to other modules mapped to memory addresses (in memory 206) to reference each other. Typically, an object file can contain three types of symbols, which are defined "external" symbols, sometimes called "public" or "entry" symbols, that allow the symbol to be called by other modules, undefined "external" symbols that reference other modules if these symbols are defined, and local symbols used within the object file to facilitate relocation. Relocation is an entry in the binary that is left to be written later, either at link time by a static linker (binder) or at execution time by a dynamic linker (loader).

[0034] Many operating system environments enable dynamic linking (e.g., using dynamic linker 212), which defers the resolution of some undefined symbols until the program (e.g., software program / application 230) is executed. This means that the executable code of the software program / application 230 still contains undefined symbols, and in addition, it contains a list of objects or libraries (e.g., one or more shared libraries 214) that provide the definitions of these undefined symbols. The dynamically linked program (e.g., software program / application 230) includes small statically linked functions that are called when the program starts. This static function maps the link library (e.g., one or more shared libraries 214) to the memory 206 and executes the code contained in the function. The dynamic linker 212 determines all the dynamic shared libraries required by the program, along with the names of the variables and functions required from those libraries, by reading the information contained in the sections of the shared libraries. Then, the dynamic linker 212 maps the shared libraries to the center of the virtual memory and resolves the references to the symbols contained in those shared libraries. The software program does not know where these shared libraries (e.g., one or more shared libraries 214) are actually mapped within the memory 206. The shared libraries are compiled into position-independent code (PIC) that can be executed at any address within the memory.

[0035] On one hand, static linking (e.g., using static linker 210) results in the linker copying all library routines used in software program / application 230 into an executable image / file. Static linking may require more disk space and memory 206 than dynamic linking, but is more portable because the program does not require the presence of shared libraries on the system on which it is executed. For example, when the program's execution (.exe) file is clicked and the program starts execution, all the necessary contents of the binary file are loaded into the virtual address space of the process. However, most programs also need to execute functions from the system's shared libraries, and these library functions also need to be loaded. In the simplest case, the required library functions are directly embedded into the program's execution binary file. Such programs are statically linked to the library, and the statically linked execution code can start execution as soon as they are loaded.

[0036] The debugger 240 or debug tool is a computer program used to test and debug other programs such as software program / application 230. The debugger 240 is configured to execute the software program / application 230 under controlled conditions, enabling the programmer to track the operation of the ongoing software program / application 230 and monitor changes in computer resources (such as memory areas used by the program or the computer's operating system) that may indicate non-functioning code within the software program / application 230. The debugger 240 has the ability to execute or pause the program at specific locations, display the contents of memory, the CPU's registers (such as register 250), or a storage device (such as a disk drive), and modify the contents of memory or registers to input selected test data that may cause the execution of a defective program.

[0037] The computer system 202 includes a Global Offset Table (GOT) 208, which is a section of memory for computer programs (executable files and shared libraries) that is used to enable correct execution of computer program code (e.g., compiled as an ELF file) regardless of the memory address where the program's code or data is loaded at runtime. The GOT 208 maps symbols in the programming code to their corresponding absolute memory addresses to facilitate position-independent code (PIC) and position-independent executables (PIE) that are loaded at different memory addresses each time the software program is started. When PIC or PIE code is executed, the runtime memory address, also known as the absolute memory address of variables and functions, is unknown before the program starts, so it cannot be hard-coded by the compiler at compile time. The GOT can be represented as the.got and.got.plt sections within a file (e.g., an ELF file) that is loaded into the program's memory at startup. For example, the operating system's dynamic linker is used to update the relocation of the Global Offset Table (from symbol to absolute memory address) when the program starts or when a symbol is accessed. The GOT 208 is a mechanism that allows shared libraries (e.g.,.so) to be relocated to different memory addresses at startup, preventing memory address conflicts with the main program or other shared libraries. The GOT 208 is a table of addresses that exists in the data section. The GOT 208 converts position-independent address calculations to absolute positions. A Procedure Linkage Table (PLT) (not shown) is a table that redirects position-independent function calls to absolute positions.The link editor cannot resolve the transfer of execution, such as function calls, between different dynamic objects. Therefore, the link editor prepares to move the control of the program to an entry in the procedure link table. In this way, the runtime linker redirects the entry without sacrificing the position independence and shareability of the text of the program. The executable file and the shared object file can contain separate procedure link tables.

[0038] FIG. 3 is a block diagram of an exemplary architecture flow 300 according to one or more embodiments of the present invention. With reference to FIG. 2, the architecture flow 300 is described. As described above, the software program / application 230 is executed on the computer system 202, and then, without stopping or pausing the execution of the software program / application 230, the shared library 214 is updated and reloaded. At block 302, the debugger 240 is configured to start a debug session for the software program / application 230, and during the debug session, the debugger 240 is configured to issue a reload command, such as reload liba.so, thereby reloading the shared library 214 since the shared library 214 has been updated. The debugger 240 is configured to call, communicate with, or both execute the software (APIs) respectively associated with each of the static linker 210, the dynamic linker 212, the GOT 208, and the shared library 214 in order to execute as described herein when executing the software program / application 230.

[0039] Block 304 is configured to initiate / perform a field back of the GOT 208 by resetting the previously resolved address with respect to the shared library 214 (e.g., liba.so). For example, in a particular GOT entry within the GOT table 208, in the link address field of the GOT 208 of the shared library 214 (e.g., the link address field 504 shown in FIG. 5), the old address 320 has already been resolved. The old address 320 has already been resolved by the dynamic linker 212. Since the shared library 214 has been reloaded / updated, the GOT 208 is configured to reset the old address 320 in the link address field 504 shown in FIG. 5 to the initial value 322. The initial value is predefined as a default value. Further, as can be seen herein, performing a field back of the GOT includes not only resetting the link address from the old address (to which it was originally linked) to the initial value (i.e., the default value), but also resetting the GOT resolved flag (e.g., within the resolved flag field 508 shown in FIG. 5) from TRUE to FALSE.

[0040] At block 306, since the shared library 214 has been updated, the dynamic linker 212 is called again (i.e., later) to resolve the new address of the shared library 214 (e.g., liba.so). At block 308, the dynamic linker 212 is configured to perform dynamic loading. When a symbol (e.g., function foo) defined in the dynamic library (e.g., liba.so) is called for the first time after the updated liba.so is loaded again, the dynamic linker 212 resolves the unresolved (relocated) entries by searching the unresolved entry table 215 and the symbol table 216 for a match with the new address 324. For the unresolved entries detected in the unresolved entry table 215, the dynamic linker 212 searches for and retrieves the symbols in the symbol table 216 that are used to resolve the new address of the shared library 214 (liba.so). The dynamic linker 212 functions to resolve the symbols of the shared library 214 (liba.so) using the symbol table 216. After the symbols are resolved, the dynamic linker 212 updates the entries (of the resolved symbols) in the index table 218 associated with the shared library 214. At block 310, the dynamic linker 212 is configured to update the GOT 208 using the new resolved address 324 (i.e., the new value of the link address field 504 shown in FIG. 5). Also, the dynamic linker 212 sets the GOT resolved flag (e.g., in the resolved flag field 508 shown in FIG. 5) from FALSE to TRUE.

[0041] In block 312, the dynamic linker 212 (or loader) is configured to read the newly resolved address of the shared library 214 in the memory space for use by the software program / application 230. The memory space can be one or more locations within the memory 206 used by the software program / application 230, one or more registers 250 of a processor (such as processor 101), etc. Exemplary results of the debugger 240 or the dynamic linker 212 or both can be the input 330. The input 330 can include a library file name (e.g., liba.so) in the shared library 214 or another output file (e.g., a.out) or both. FIG. 4 is a block diagram of an exemplary flowchart 400 of a debug session for the software program / application 230 according to one or more embodiments of the present invention. As described above, the software program / application 230 is executed on the computer system 202, and then the shared library 214 is updated and reloaded. In block 402, the debugger 240 is configured to start a debug session for the software program / application 230. In block 404, the debugger 240 is configured to receive user input. The user input can be permission such as to continue debugging, to specify to examine a particular section of code within the software program / application 230, etc. For example, the command "reload liba.so" can be input by the user. In block 406, the debugger 240 is configured to check whether a reload of the shared library 214 is required. If a reload is not required, the flow moves to block 410. If the shared library 214 is updated, such as when one or more memory addresses have changed (e.g., a new address replaces the previous address within the shared library 214), the debugger 240 determines that a reload of the shared library 214 is required to enable the change / update.In one example, the debugger 240 may receive a trigger or instruction that the shared library 214 should be reloaded into the memory 206.

[0042] At block 408, the debugger 240 is configured to execute the GOT fill-back, or cause the GOT fill-back to be executed, or both. In particular, during the GOT fill-back, the debugger 240 or another software tool or both are configured to fill-back the GOT entry in the GOT 208 corresponding to the updated address (or symbol), and in response, the GOT 208 is reset using the initial value 322 (e.g., an initial value of 0x80000000 as a default value). In one or more embodiments, the debugger 240 may include the GOT fill-back module 242, or another tool may include the GOT fill-back module 242, or both. The GOT fill-back module 242 includes computer-executable instructions configured to perform the GOT fill-back described herein. In one or more embodiments, the GOT fill-back module 242 may be integrated with the dynamic linker 212, the GOT 208, or other software tools, or a combination thereof. At block 410, the debugger 240 is configured to resolve a new address, or cause the dynamic linker 212 to resolve a new address, or both. To resolve the unresolved address (which is the new address) of the reloaded shared library 214, the loading process is triggered. Resolving a new address is described at blocks 306 and 308 of FIG. 3. At block 412, the debugger 240 is configured to provide debugger output. The debugger 240 outputs results according to a user request (e.g., which source line is stopped after execution of debug commands such as "continue", "next", etc.). For example, the debugger session ends each time the user terminates the debugger program according to the user input at block 404.

[0043] To execute the GOT's field back, one or more embodiments present a new GOT 208 (i.e., a new global offset table), as illustrated in FIG. 5. As shown in FIG. 5, an exemplary GOT 208 includes three columns. Offset 502 indicates which GOT entry is used to store the link address of a symbol defined within a dynamic library. For example, the offset can start from 0x00, and each GOT entry or row (e.g., in this example) contains 8 bytes. The first row indicates a link address field 504, and the link address field 504 is an entry value that contains the resolved link address of the GOT entry / row within the GOT 208. The GOT 208 is extended to include two new columns, which are the second and third columns, according to one or more embodiments of the present invention. For the extended fields of the GOT, the static linker 210 extends the size of the GOT entry or row, for example, from 4 bytes to 8 bytes, and introduces two new fields, namely a dynamic library (DLL) index field and a resolved flag field, into the extended 4 bytes. The second column indicates the DLL index field 506 of the linked module (i.e., the shared library 214) after being resolved. The third column indicates a resolved flag field 508 that shows whether the address of the module (i.e., the link address) has been resolved. By default, the resolved flag is set to "FALSE" and is set to "TRUE" when the address of a symbol (e.g., of the software program / application 230) is resolved by a loader (e.g., the dynamic linker 212).

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

[0045] As described in this specification, after the software program / application 230 has already started execution, the memory addresses within the shared library 214 are updated, changed, or both. The debugger 240 has started a debug session and is notified / aware of the updates / changes to the shared library 214, for example, when the shared library 214 is called. For example, a debugger command (e.g., "reload liba.so") informs the debugger 240 that the liba.so needs to be reloaded. Thus, at block 606, the debugger 240 is configured to reload the updated shared library 214 (e.g., liba.so) and the GOT 208 without pausing, restarting, or doing both to the software program / application 230. At block 608, the debugger 240 is configured to check whether the GOT resolved flag within the resolved flag field 508 of the GOT entry or item is TRUE. For example, the debugger 240 can use the GOT 208 to check the resolved flag field 508 of the GOT entry / item (i.e., row). If the GOT resolved flag of the GOT entry / item is FALSE, the flow proceeds to block 602. If the GOT resolved flag of the GOT entry / item is TRUE, at block 610, the debugger 240 is configured to check whether the value of the DLL index within the DLL index field 506 of the GOT entry / item in the GOT 208 is equal to the value of the DLL index of the corresponding entry / item within the DLL index table 218 in the shared library 214 (e.g., liba.so). If the value of the DLL index field 506 of the GOT entry / item in the GOT 208 is not equal to the value of the corresponding entry / item of the DLL index in the DLL index table 218 of the shared library 214 (e.g., liba.so), the flow returns to block 602.If the value of the DLL index field 506 of the GOT entry / item within GOT208 is equal to the value of the corresponding entry / item within the DLL index table 218 of the DLL index within the shared library 214 (e.g., liba.so), at block 612, the debugger 240 is configured to execute the field back of the GOT. As described herein, prior to updating the corresponding memory address within the shared library 214, the dynamic linker 212 is used to resolve the old link address (e.g., old address 320) within the link address field 504. Since the shared library 214 is reloaded / updated, the debugger 240 resets the link address within the link address field of the GOT entry / item of GOT208 (e.g., resets the old address 320 to an initial value 322 such as 0x8000000) and is configured to reset the GOT resolved flag within the resolved flag field to FALSE, as previously described with respect to block 304.

[0046] The flow returns to block 602, where debugger 240 is configured to re-execute the call to bar() on liba.so (the currently updated shared library 214). Returning to block 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 the initial value of the memory address (i.e., the link address within GOT 208). If the memory address of the called GOT entry or item within GOT 208 (e.g., the link address within the link address field 504 of FIG. 5) is the initial value (e.g., the initial value 322), at block 614, debugger 240 instructs or causes the dynamic linker 212 to resolve a new link address. At block 616, the dynamic linker 212 is configured to perform dynamic loading (as previously described, for example, at block 308). The dynamic linker 212 searches for a match with the new address 324 in the unresolved (relocated) entry table 215 to find the unresolved entry. For the unresolved entry detected within the unresolved entry table 215, the dynamic linker 212 searches for and retrieves the symbol within the symbol table 216 that is used to resolve the new address of the shared library 214 (liba.so). The dynamic linker 212 functions to resolve the symbols of the shared library 214 (liba.so) using the symbol table 216. After the symbol is resolved, the dynamic linker 212 updates the entry (of the resolved symbol) within the index table 218 associated with the shared library 214. At block 310, debugger 240 is configured to update GOT 208 using the newly resolved address 324 (i.e., the new value of the link address field 504 shown in FIG. 5). Also, debugger 240 can set the GOT resolved flag from FALSE to TRUE.In block 618, the debugger 240 is configured to update the GOT 208, or cause the dynamic linker 212 to update the GOT 208, or both. During an update to a GOT entry or item in the GOT 208, the debugger 240, the dynamic linker 212, or both, are configured to write the newly resolved address as the link address in the link address field 504, update the DLL index in the DLL index field 506, and mark the resolved flag for the link address in the resolved flag field 508 as TRUE.

[0047] For purposes of illustration and not limitation, exemplary situations are described in FIGS. 7-11. FIG. 7 is a block diagram showing detailed operations performed by a dynamic linker and a debugger in accordance with one or more embodiments of the present invention. Typically, reloading a shared library requires stopping the execution of the program / application. However, when a standard system attempts to continue without stopping the execution of the program / application, the standard system reloads the recompiled shared library (e.g., liba.so), but the address of the called function (e.g., bar()) within the reloaded liba.so has changed from 0x7ff8100 (old shared library) to 0x7ff9100 (updated shared library). Since the address stored in the GOT entry is not the default value in the standard system (i.e., not 0x80000000), the program / application branches to the original (old) load address of bar(), which is 0x7ff8100, thereby causing the reloading of the shared library (e.g., liba.so) to malfunction in the standard system. In FIG. 7, one or more embodiments are configured to reload the shared library 214 without stopping the execution of the software program / application 230 while using the extended GOT 208 (shown in FIG. 5). Since the shared library 214 has been updated, the dynamic linker 212 is configured to assign "1" to the DLL index in the DLL index field 506 and mark the resolved flag of the address in the resolved flag field 508 of the GOT entry or item as TRUE, as shown in operation 702. Also, the dynamic linker 212 assigns the resolved address of bar() to 0x7ff8100 as shown in the old version of the shared library 214 (e.g., old libra.so). Note at this time that operation 705 points to the old address of the shared library 214 (e.g., 0x7ff8100). While the software program / application 230 is being executed, the shared library 214 is reloaded or recompiled.For example, after the shared library 214 is recompiled, the debugger 240 calls the dynamic linker 212 (e.g., the loader) by issuing a command (e.g., "reload liba.so") to reload the updated shared library 214 (e.g., the new liba.so). In operation 704, the debugger 240 retrieves all mapped GOT entries or items (i.e., GOT + 0x28) by fetching the GOT entry or item that contains the DLL index "1" in the DLL index field 506. If the resolved flag in the resolved flag field 508 is TRUE, the debugger 240 resets the link address (in the link address field 504) stored in the target GOT entry / item (e.g., GOT + 0x28) using the default value (i.e., 0x80000000) and resets the address resolved flag to FALSE using FALSE. In operation 706, the dynamic linker 212 assigns "1" to the DLL index field 506, marks the address resolved flag in the resolved flag field 508 of the GOT entry / item as TRUE, and then, when the symbol bar is called again, is configured to assign 0x7ff9100 in the link address field 504 to the resolved address of bar. The resolved address of bar (i.e., 0x7ff9100) is the link address to the updated shared library 214 (i.e., the new liba.so) instead of the old shared library (e.g., the old liba.so), and operation 708 points to / links to the updated shared library 214. In FIG. 7, an exemplary portion of the software program / application 230 is shown, and note that an exemplary function (e.g., bar()) is a call to the address of bar. Note that in FIGS. 7 and 8, the operations (such as operations A - K) showing the standard operations / transitions for shared and dynamic libraries using the PLT and GOT are not described as these operations / transitions are understood by those skilled in the art.

[0048] To provide further details regarding operation 702 of FIG. 7, FIG. 8 is a block diagram showing the operation of a linker executed by a dynamic linker in accordance with one or more embodiments of the present invention. In FIG. 8, in operation 802, after the dynamic linker 212 loads the shared library 214 (e.g., liba.so), it is configured to obtain the resolved address and resolve the address of the function bar to be called. In operation 804, the dynamic linker 212 is configured to update the content of bar's GOT+0x28 (i.e., the GOT entry / item) using 0x7ff8100 within the link address field 504. In operation 806, with respect to the GOT entry / item, the dynamic linker 212 is configured to assign "1" to the DLL index within the DLL index field 506 and mark the resolved flag of the address within the resolved flag field 508 as TRUE.

[0049] Referring to FIGS. 7 and 8 in more detail, FIG. 9 is a block diagram showing the file back of the GOT according to one or more embodiments of the present invention. As described herein, after the shared library 214 is recompiled, the debugger 240 issues a command (i.e., "reload liba.so") to call the dynamic linker 212 (e.g., the loader), reload the updated shared library 214 (e.g., liba.so), and the dynamic linker 212 obtains the DLL index by searching the DLL index / table 218. In operation 902, the dynamic linker 212 retrieves all mapped GOT entries / items (i.e., GOT+0x28) by retrieving the GOT entry / item containing the DLL index "1" in each DLL index field 506. If the resolved flag of the GOT entry / item in the GOT 208 is TRUE, in operation 904 of FIG. 9, the file back module 242 (e.g., block 304 of FIG. 3) uses the default value (i.e., 0x80000000) to reset the address in the link address field 506 of the target GOT entry / item (e.g., GOT+0x28) and reset the resolved flag of the address in the resolved flag field 508 to FALSE.

[0050] To illustrate further use of GOT208, FIG. 10 is a block diagram showing the operation of a further loader in accordance with one or more embodiments of the present invention. The dynamic linker 212 performs an address resolution process and updates the new address from the recompiled shared library 214 as described herein. For example, in operation 1002, when the software program / application 230 calls bar() again, since the address stored in GOT+0X28 is the default value 0x8000000, the dynamic linker 212 resolves the address of the function bar again. In operation 1004, the dynamic linker 212 updates the link address of GOT+0x28 using the new address 0x7ff910 of bar, assigns "1" to the DLL index, and marks the resolved flag in the GOT entry / item as TRUE. In the GOT entry / item of GOT208, the old address (0x7ff8100) of the shared library 214 is updated to the new address (i.e., the new link address 0x7ff9100). The index field can be the value "-1", and "-1" is the initial value of the library index field. The index field can be the value "1" meaning the library index 218, i.e., the library index of liba.so is 1.

[0051] To illustrate the use of the updated GOT208 and PTL, FIG. 11 is a block diagram showing that when a function is called subsequently, it branches directly to the new address (e.g., the new address 324 in the link address field 504) in accordance with one or more embodiments of the present invention. In operation 1102, the software program / application 230 is compiled and the PLT is used to redirect the position-independent function call to the absolute position. In operation 1104, when bar() is called again (later), since the value stored in GOX+0X28 is the new address 0x7ff9100, the instruction "b @GOT+0X28" jumps directly to 0x7ff9100.

[0052] The technical advantages and benefits include one or more embodiments in which when a dynamic library is updated, the execution of a software program / application or a debug process or both continues, i.e., the software program / application or the debug process is not stopped. According to one or more embodiments, since neither the stop, nor the suspension, nor the interruption of the execution of the software program / application is required, no additional instructions need to be generated by a static linker and no extra operations are performed by a dynamic linker (e.g., a loader), thus having no impact on performance. Further technical advantages and benefits include, in particular, the reduction of the time and effort of software programmers during the development / testing of a software program / application and during the identification of root causes in complex situations, while always providing software programmers with a more flexible way for testing and debugging.

[0053] FIG. 12 is a flowchart of a method 1200 for performing a reload of an updated shared library without stopping the execution of a software program / application 230, in accordance with one or more embodiments of the present invention. At block 1202, the debugger 240 is configured to execute a software program / application 230 that requires a function call (e.g., bar()) to the shared library 214 via the processor 101, or to cause the software program / application 230 to be executed, or both. At block 1204, the debugger 240 is configured to reload the shared library 214, or cause the dynamic linker 212 to reload it, or both, without stopping the execution of the software program / application 230, where the shared library 214 has been updated after the execution of the software program. At block 1206, the debugger 240 is configured to update the global offset table (GOT) 208 in response to resolving the link address associated with the function call, where the entries in the GOT 208 include a link address field 504, an index field 506, and a resolved flag field 508, and updating includes updating the index field with a positive value (e.g., "1") for an entry in the GOT 208 and marking the resolved field with a positive flag (e.g., TRUE). At block 1208, the debugger 240 is configured to find an entry in the GOT 208 that includes a positive value (e.g., "1") in the index field and a positive flag (e.g., TRUE) in the resolved field, or cause the dynamic linker 212 to find it, or both, in response to reloading the shared library 214 without stopping the execution of the software program / application 230.In block 1210, debugger 240 is configured to return, or cause to be returned to dynamic linker 212, or do both, the address value within the link address field of an entry containing a positive value in the index field, in response to subsequent execution of a function call to shared library 214.

[0054] Before updating GOT 208, the link address field is set to a default value (e.g., 0x80000000). If the resolved field already contains a positive value (e.g., TRUE) before updating GOT 208, the resolved field is marked with a non-positive 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 within the link address field with the new address after resolving the new address. The address value within the link address field is the resolved new address of shared library 214. Before reloading shared library 214, during the execution of software program / application 230, shared library 214 has been initially / already loaded for a function call to the shared library.

[0055] FIG. 13 is a flowchart of a method 1300 for performing a reload of 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 1302, debugger 240 is configured to reload shared library 214, or cause dynamic linker 212 to reload it, or both, without stopping the execution of software program / application 230 that calls shared library 214. At block 1304, in response to debugger 240 resolving the link address to shared library 214 (e.g., of link address field 504), debugger 240 is configured to update an index field (e.g., DLL index field 506) for an entry in the global offset table (GOT) using a positive value (e.g., "1") and mark a resolved field (e.g., resolved flag field 508) with a positive flag (e.g., TRUE). At block 1306, in response to debugger 240 reloading the shared library without stopping the execution of the software program, debugger 240 is configured to find an entry in GOT 208 that contains the resolved link address of shared library 214.

[0056] Although this disclosure includes a detailed description of cloud computing, it should be understood that the implementations of the teachings shown herein are not limited to a cloud computing environment. Embodiments of the present invention can be implemented in conjunction with any other type of computing environment now known or later developed.

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

[0058] The characteristics are as follows. On - demand self - service: Cloud consumers can unilaterally provision computing capabilities such as server time and network storage automatically as needed, without the need for human interaction with the service provider. Broad network access: Capabilities are available over the network and can be accessed using standard mechanisms, facilitating use by heterogeneous thin or thick client platforms (such as mobile phones, laptops, and PDAs). Resource pooling: The provider's computing resources are pooled and offered to multiple consumers using a multi - tenant model, and various physical and virtual resources are dynamically assigned and reassigned according to demand. There is a sense of location - independence, and consumers typically neither manage nor know the exact location of the provided resources, although at a higher level of abstraction, it may be possible to specify a location (such as a country, state, or data center). Rapid elasticity: Capabilities can be rapidly and elastically, and in some cases automatically, provisioned, quickly scaled out, and rapidly released and scaled in. The capabilities available for provisioning often appear to the consumer to be unlimited, and any amount can be purchased at any time. Services to be measured: By leveraging measurement capabilities, a cloud system automatically controls and optimizes resource usage at an abstract level suitable for service types (e.g., storage, processing, bandwidth, and active user accounts). The resource usage situation can be monitored, controlled, and reported, providing transparency to both the provider and the user of the services utilized.

[0059] The service model is as follows. SaaS (Software as a Service): The capabilities provided to users are to utilize the provider's applications running on the cloud infrastructure. Those applications can be accessed from various client devices via a thin-client interface such as a web browser (e.g., web-based email). Users do not manage or control the underlying cloud infrastructure, which includes the network, servers, operating systems, storage, or individual application functions, except for limited user-specific application configuration settings which may be an exception. PaaS (Platform as a Service): The capabilities provided to users are to deploy the applications created or obtained by the users, which are created using the programming languages and tools supported by the provider, onto the cloud infrastructure. Users do not manage or control the underlying cloud infrastructure, which includes the network, servers, operating systems, or storage, but can control the deployed applications and, in some cases, the configuration of the application hosting environment. IaaS (Infrastructure as a Service): The capabilities provided to users are to provision processing, storage, network, and other basic computing resources, and users can deploy and run any software that can include operating systems and applications. Users do not manage or control the underlying cloud infrastructure, but can control the operating system, storage, and deployed applications, and in some cases, can limitedly control selected network components (e.g., host firewalls).

[0060] The deployment models are as follows. Private cloud: This cloud infrastructure is operated only for an organization. It can be managed by this organization or a third party and can exist on-premises or off-premises. Community cloud: This cloud infrastructure is shared by multiple organizations and supports a specific community that shares concerns (e.g., missions, security requirements, policies, and compliance considerations). It can be managed by these organizations or a third party and can exist on-premises or off-premises. Public cloud: This cloud infrastructure is available for general users or large industry groups and is owned by an organization that sells cloud services. Hybrid cloud: This cloud infrastructure is a composition of two or more clouds (private, community, or public) that are combined with each other while leaving unique entities intact by standardized technologies or proprietary technologies (e.g., cloud bursting for adjusting the load balance between clouds) that enable the migration of data and applications.

[0061] A cloud computing environment is a service-oriented environment that emphasizes statelessness, loose coupling, modularity, and semantic interoperability. At the center of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0062] Referring now to FIG. 14, an exemplary cloud computing environment 50 is shown. As illustrated, cloud computing environment 50 includes one or more cloud computing nodes 10 that can communicate with local computing devices (e.g., personal digital assistants (PDAs) or cellular phones 54A, desktop computers 54B, laptop computers 54C, or in-vehicle computer systems 54N, or combinations thereof, etc.) used by cloud consumers. Nodes 10 can communicate with each other. Nodes 10 can be physically or virtually grouped within one or more networks into the private cloud, community cloud, public cloud, or hybrid cloud, or combinations thereof, etc., described hereinabove (not shown). Thereby, cloud computing environment 50 can provide an infrastructure, platform, or SaaS, or combinations thereof, for which cloud consumers need not maintain resources on local computing devices. The types of computing devices 54A - N shown in FIG. 14 are for illustrative purposes only, and it is understood that computing nodes 10 and cloud computing environment 50 can communicate with any type of computer-controlled device via any type of network or network-addressable connection (e.g., a connection using a web browser) or both.

[0063] Referring now to FIG. 15, a set of functional abstraction layers provided by the cloud computing environment 50 (FIG. 14) is shown. It should be understood in advance that the components, layers, and functions shown in FIG. 15 are for illustrative purposes only, and embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided.

[0064] The hardware and software layer 60 includes hardware components and software components. Examples of hardware components include mainframe 61, RISC (Reduced Instruction Set Computer) architecture-based server 62, server 63, blade server 64, storage device 65, and network and network components 66. In some embodiments, the software components include network application server software 67 and database software 68.

[0065] The virtualization layer 70 includes an abstract layer that can provide virtual entities such as virtual server 71, virtual storage 72, virtual network 73 including a virtual private network, virtual applications and operating systems 74, and virtual clients 75.

[0066] For example, the management layer 80 may provide the functions described below. Resource provisioning 81 performs dynamic procurement of computing resources and other resources used to execute tasks within a cloud computing environment. Measurement and pricing 82 performs cost tracking when resources are utilized within a cloud computing environment and sends invoices or bills for the use of those resources. For example, those resources may include application software licenses. Security performs ID verification of cloud users and tasks and protects data and other resources. The user portal 83 provides access to the cloud computing environment to users and system administrators. Service level management 84 performs allocation and management of cloud computing resources to meet the required service levels. Service level agreement (SLA) planning and execution 85 performs advance preparation and procurement of cloud computing resources for which future demands are expected according to the SLA.

[0067] The workload layer 90 shows examples of functions available in a cloud computing environment. Examples of workloads and functions that may be provided from this layer include mapping and navigation 91, software development and life cycle management 92, delivery of virtual classroom education 93, data analysis processing 94, transaction processing 95, and software applications 96 (for example, software program / application 230, debugger 240, static linker 210, dynamic linker 212, and field back module 242). Also, the software application can function with resource provisioning 81, or be integrated with resource provisioning 81, or both.

[0068] In this specification, various embodiments of the present invention are described with reference to the accompanying drawings. Alternative embodiments of the present invention may be devised without departing from the scope of the present invention. In the following description and drawings, various connections and positional relationships between elements (e.g., above, below, adjacent, etc.) are shown. Those connections or positional relationships or both can be direct or indirect unless otherwise specifically defined, and the present invention is not intended to be limited in this regard. Therefore, a physical connection can refer to a direct connection or an indirect connection, and the positional relationship between entities can be a direct positional relationship or an indirect positional relationship. Further, the various operations and process steps described herein can be incorporated into a more comprehensive procedure or process that includes additional steps or functions not described in detail herein.

[0069] One or more of the methods described herein can be implemented using any one or combination of techniques well known in the prior art, such as discrete logic circuits including logic gates for implementing logical functions on data signals, application specific integrated circuits (ASICs) including appropriate combinational logic gates, programmable gate arrays (PGAs), field programmable gate arrays (FPGAs), etc.

[0070] For the sake of brevity, the prior art related to the creation and use of aspects of the present invention may or may not be described in detail herein. Specifically, the various aspects of computing systems and specific computer programs for implementing the various technical features described herein are well known. Therefore, for the sake of brevity, many details regarding conventional implementations are only briefly described herein without providing details of known systems or processes or both, or are omitted entirely.

[0071] In some embodiments, various functions or operations may be performed at a particular location, or in relation to the operation of one or more devices or systems, or both. In some embodiments, a portion of a particular function or operation may be executable at a first device or location, and the remaining portion of the function or operation may be executable at one or more additional devices or locations.

[0072] The terms used herein are for the purpose of describing particular embodiments only and are 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 dictates otherwise. The terms "comprising", "comprises", and / or "comprising", when used herein, specify the presence of the stated function, integer, step, operation, element, or component, or combinations thereof, but do not preclude the presence or addition of one or more other functions, integers, steps, operations, elements, components, or groups thereof, or combinations thereof.

[0073] All means or steps and corresponding structures, materials, acts, and equivalents of the functional elements in the claims below are intended to include any structure, material, or act for performing the functions in combination with the other claimed elements specifically recited. The present disclosure has been presented for purposes of illustration and description but is not intended to be exhaustive or limited to the disclosed forms. It will be apparent to those skilled in the art that many modifications and variations are possible without departing from the scope of the disclosure. Embodiments have been chosen and described in order to best explain the principles of the disclosure and its practical application, and to enable others skilled in the art to understand the disclosure for various embodiments with various modifications as are suited to the particular use contemplated.

[0074] The figures shown in this specification are illustrative. Without departing from the scope of the present disclosure, many variations of the figures or steps (or operations) described herein are possible. For example, the operations can be executed in a different order, or operations can be added, deleted, or changed. Also, the term "coupled" represents that there is a signal path between two elements and does not mean a direct connection between the elements without an element / connection intervening between them. All these variations are considered to be part of the present disclosure.

[0075] The following definitions and abbreviations are used in the claims and the interpretation of this specification. As used herein, the terms "comprising," "comprises," "including," "includes," "having," "has," "containing," "contains," or any other variation thereof are intended to cover non-exclusive inclusion. For example, a composition, mixture, process, method, product, or apparatus that includes a list of elements is not necessarily limited to only those elements, and can include other elements not expressly listed or inherent to such composition, mixture, process, method, product, or apparatus.

[0076] Furthermore, the term "exemplary" is used herein to mean "serving as an example, instance, or illustration." Embodiments or designs described herein as "exemplary" should not necessarily 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., 1, 2, 3, 4, etc.). The term "plurality" is understood to include any integer greater than or equal to two (i.e., 2, 3, 4, 5, etc.). The term "connected" can include both indirect "connection" and direct "connection."

[0077] The terms "about," "substantially," "approximately," and variations thereof are intended to include the degree of error associated with the measurement of a particular quantity, based on the equipment available at the time of filing of the present application. For example, "about" can include a range of ±8% or 5% or 2% of a particular value.

[0078] The present invention may be a system, method, or computer program product, or a combination thereof, at any possible technical level of integration. The computer program product may include a computer-readable storage medium including computer-readable program instructions for causing a processor to execute aspects of the present invention.

[0079] A computer-readable storage medium can be a tangible device that can hold and store instructions for use by an instruction execution device. The computer-readable storage medium can be, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof, but is not limited thereto. A non-exhaustive list of more specific examples of computer-readable storage media includes portable floppy (R) 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 compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy (R) disks, mechanically encoded devices such as punch cards or raised structures in grooves in which instructions are recorded, and any suitable combination thereof. As used herein, a computer-readable storage medium should not be construed to be a transient signal such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse passing through an optical fiber cable), or an electrical signal transmitted through a wire.

[0080] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device, or to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof). The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface within each computing / processing device receives the computer-readable program instructions from the network and transfers them for storage on a computer-readable storage medium within each computing / processing device.

[0081] Computer-readable program instructions for carrying out the operations of the present invention may be written in any combination of one or more programming languages, including assembly instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuits, or source code or object code written in any combination of one or more programming languages such as the object-oriented programming languages like Smalltalk(R), C++, and the procedural programming languages like the "C" programming language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially executed on the user's computer as a stand-alone software package, partially executed on the user's computer and a remote computer respectively, or executed entirely on a remote computer or a server. In the latter scenario, 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 the connection may be made to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, to carry out aspects of the present invention, an electronic circuit including, for example, a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer-readable program instructions for customizing the electronic circuit by utilizing the state information of the computer-readable program instructions.

[0082] Aspects of the present invention will be 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.

[0083] These computer-readable program instructions are provided to a processor of a general purpose computer, 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 / acts specified in the block or blocks of the flowchart and / or block diagram. These computer-readable program instructions may be stored in a computer-readable storage medium that includes instructions for causing a computer, programmable data processing apparatus, or other device to function in a particular manner, such that the storage medium comprises a product including instructions for implementing the aspects of the functions / acts specified in the block or blocks of the flowchart and / or block diagram.

[0084] The computer-readable program instructions may 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 such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the block or blocks of the flowchart and / or block diagram.

[0085] The flowcharts and block diagrams in the figures 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 the flowchart or block diagram may represent a module, segment, or portion of instructions comprising one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, depending on the functionality involved, or may sometimes be executed in the reverse order. It should also be noted that each block of the block diagrams or flowchart diagrams, or combinations of blocks in the block diagrams or flowchart diagrams or both, can be implemented by a dedicated hardware-based system that performs the specified functions or operations, or by a combination of dedicated hardware and computer instructions.

[0086] The description of the various embodiments of the present invention has been presented for purposes of illustration, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope of the described embodiments. The terms used herein were chosen in order to best explain the principles of the embodiments, the practical application, or a technical improvement over technologies found in the marketplace, or to enable other ordinary skill in the art to understand the embodiments described herein.

Claims

1. executing, by a processor, a software program that requires a function call to a shared library; reloading the shared library without stopping execution of the software program, wherein the shared library has been updated after the execution of the software program; updating a Global Offset Table (GOT) in response to resolving a link address associated with the function call, wherein entries in the GOT include a link address field, an index field, and a resolved field, and wherein updating includes updating the index field for the entry in the GOT with a positive value and marking the resolved field with a positive flag; finding, in the GOT, an entry that includes the positive value in the index field and the positive flag in the resolved field in response to reloading the shared library without stopping execution of the software program; returning, in response to a subsequent execution of the function call to the shared library, an address value in the link address field of the entry that includes the positive value in the index field, a computer-implemented method.

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

3. The computer-implemented method of claim 1, further comprising marking the resolved field with a non-positive value if the resolved field already includes the positive value before updating the GOT.

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

5. The computer-implemented method of 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 the new resolved address of the shared library.

7. The computer-implemented method according to claim 1, wherein the shared library is first loaded for the function call to the shared library during the execution of the software program before the reloading of the shared library.

8. A system comprising a processor for executing the computer-implemented method according to any one of claims 1 to 7.

9. A program for causing a processor to execute the computer-implemented method according to any one of claims 1 to 7.

10. A processor reloading the shared library without stopping the execution of the software program that calls the shared library; in response to resolving the 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 the global offset table (GOT); finding the entry in the GOT that contains the resolved link address of the shared library in response to reloading the shared library without stopping the execution of the software program.

11. The computer-implemented method according to claim 10, wherein the finding of the entry in the GOT that contains the resolved link address of the shared library is in response to a subsequent execution of a call to the shared library.

12. The computer-implemented method according to claim 11, further comprising setting the link address field to a default value before updating the index field with the positive value and marking the resolved field with the positive flag for the entry in the GOT.

13. The computer-implemented method of claim 10, further performing, for the entry in the GOT, updating the index field using the positive value and, before marking the resolved field using the positive flag, marking the resolved field with a negative value if the resolved field already contains the positive value.

Images