Function name resolution in library conversion on the same architecture

Abstract

A computer implementation method for converting a library from a source operating system to a target operating system is disclosed. The source operating system has an ABI, the target operating system has a target ABI, the target ABI is different from the source ABI, and the library is implemented by a source object file conforming to the source application binary interface, comprising a source memory image, source symbols, and source relocation information. The method comprises the steps of creating a target memory image conforming to the target application binary interface, where the target memory is enhanced with address information pointing to variable-length information derived from the source memory image, and writing the target memory image to a target object file so that the converted library is implemented by the target object file.

Description

Technical Field

[0001] The present invention generally relates to the conversion of libraries from a source to a target operating system, and more particularly to a computer-implemented method for converting libraries from a source operating system to a target operating system. The present invention further relates to related conversion systems and related computer program products.

Background Art

[0002] Today's IT (information technology) infrastructure, particularly within large enterprises and government organizations, has many legacy systems and deploys many legacy applications. A large amount of the available IT budget must be spent on these systems and applications, and thus investment in new future-oriented systems can be difficult. As an example, IBM's operating system z / VM has a history of over 50 years and is mainly written in HLASM, PLX, and C. Many programmer resources may have become inactive. Additionally, z / VM can currently only be compiled, assembled, and linked on another z / VM system. Unfortunately, since z / OS 1.13 became available, support for modern C compilers has not been available.

[0003] However, software development is not always performed on the system in which the software will later run. For example, software intended for use under a legacy operating system may be developed using a Linux-type development environment. Often, the operating system (OS) on which the new software is developed has an application binary interface (ABI) that does not match the ABI of the legacy OS into which it will be deployed. For this reason, object files that conform to the development ABI may not conform to the deployment ABI. Additionally, the deployment system may not support the current compiler, source code manager, and / or object file format of the development system, and therefore it may not be possible to create target ABI-compliant object files by compiling the source code on the deployment system without modifying the source code and / or the deployment system. The same can be said for debugging tools for executable code in the target OS environment. Therefore, it should at least be desirable to have a method for converting object files from the development operating system to the deployment operating system, and to also make conventional debugging options available within the target or deployment operating system environment.

[0004] Several disclosures are available relating to computer implementations for translating libraries from a source operating system to a target operating system. For example, U.S. Patent 2020 / 0 226 009 A1 discloses requesting the execution of a workload by a next function having data transport overhead adjusted based on memory sharing capabilities with the next function. In this case, the data transport overhead consists of one or more of the following: sending memory address pointers, sending virtual memory address pointers, or sending data to the next function.

[0005] Additionally, U.S. Patent 2017 / 0 039 050 A1 discloses a technique for binary translation, which allows a host platform to receive a program relating to a guest platform different from the host. The program uses a set of shared objects or dynamically loaded libraries and is incompatible with the host platform. This allows the host platform to determine whether it has a corresponding shared object or dynamically loaded library that implements a common external interface with a particular shared object or dynamically loaded library from the set.

[0006] However, none of the available technologies offer solutions for cross-system development, such as those targeting z / VM, and none, in particular, support variable function name lengths on legacy operating systems for tracking and debugging purposes. [Overview of the project]

[0007] According to one aspect of the present invention, a computer implementation method for converting a library from a source operating system to a target operating system may be provided. Thereafter, the source operating system may include a source application binary interface, the target operating system may include a target application binary interface, the target application binary interface is different from the source application binary interface, the library is implemented by a source object file, the source object file may conform to the source application binary interface and includes at least a source memory image, source symbol information, and source relocation information.

[0008] The method may include the steps of creating a target memory image, wherein the target memory image conforms to the target application binary interface, and the target memory is enhanced using address information that points to variable-length information derived from the source symbol name for each external source symbol, which is derived from the source memory image; and writing the target memory image to the target object file so that the converted library is implemented by the target object file.

[0009] According to a further aspect of the present invention, a conversion system for converting a library from a source operating system to a target operating system may be provided. The source operating system may include a source application binary interface, the target operating system may include a target application binary interface, the target application binary interface is different from the source application binary interface, the library is implemented by a source object file, the source object file may conform to the source application binary interface and includes at least a source memory image, source symbol information, and source relocation information.

[0010] The system may comprise one or more processors and memory operablely coupled to the one or more processors, wherein the memory, when executed by the one or more processors, creates a target memory image, wherein the target memory image conforms to the target application binary interface, the target memory enhances the target memory image using address information pointing to variable-length information derived from source symbol names for each external source symbol, derived from the source memory image, and stores a portion of program code that enables writing the target memory image to the target object file so that the converted library is implemented by the target object file.

[0011] The proposed computer implementation method for converting libraries from a source operating system to a target operating system may offer several advantages, technical benefits, contributions, and / or improvements.

[0012] Specifically, since function names can now be tracked and clearly identified within trace reports, this may be relevant in terms of the ability to support easier use of trace and dump reading tools within the target OS environment. In short, the solution may be based on including a strtab ELF section, i.e., a string table, within the converted target memory image, and adding pointers in the hotpatch area before the names of functions or other objects. Additionally, relocation may be added if necessary to resolve absolute pointers at final link time.

[0013] In this way, developers can track and trace software code currently written under an operating system environment other than a deployment operating system environment (e.g., a legacy deployment OS) (e.g., a modern development OS).

[0014] Therefore, software developers familiar with traditional methods of software development on legacy operating systems can use conventional debugging tools, even though the information needed to do so is usually not available in the target memory image or the target object file. The solution proposed here is advantageous because it bridges this gap.

[0015] Thus, it is possible to develop software for more traditional software deployment environments using a modern software development environment, while still making traditional tools for debugging within the deployment OS environment available. Therefore, it may be possible to maintain the functionality of the established software infrastructure provided by the target operating system for which the software is developed. This can reduce the need for significant investment in updating and improving the target deployment system to support the modern software development environment. This can be particularly beneficial for newly hired development staff, as they do not need a complete understanding of the target system model details to develop software libraries using a familiar, up-to-date development environment on a modern computing system. Specifically, a modern software development environment can leverage well-known open-source solutions that may not have been available when the target operating system was released but are now familiar to many developers. Therefore, it is possible to use available resources, specifically more traditional, highly reliable computing environments and architectures, without having to reinvent all the tools available within the modern software development environment for traditional systems. This can help save time, money, and power, and therefore help protect the environment.

[0016] In a further advantageous aspect, one could consider that an additional proposal for (self)discovery of runtime function names via pointers, as already mentioned, would be elegantly possible.

[0017] The following describes additional embodiments of the present invention that are applicable to methods and systems.

[0018] According to an interesting embodiment of the method, the source relocation information does not need to include relative relocation information. Having relative relocation information is common in modern shared library technology. Executable code in a shared library can be moved around in main memory without any impact on its executableness. However, if the target / deployment environment does not allow relative location information within its executable, it can be beneficial if the source object being converted does not have any relative relocation information.

[0019] According to an advantageous embodiment of the method, the step of enhancing the target memory image may be carried out by placing address information within a target memory image location at a fixed offset from the target symbol address. This may be implemented by a supporting linker or translation process. Specifically, the supporting linker may be a source system linker. The source system linker may belong to a "translation unit" used from source code to executable code, i.e., a source compiler, a source linker, a translation system or converter that performs the method proposed herein, and a target linker for generating the target executable file. It should be noted that the compiler should be started with the respective options or flags.

[0020] According to another advantageous embodiment of the method, the address information may include a relative offset representing the distance between the address information in the target memory image and the address in the corresponding variable-length information in the target memory image.

[0021] According to another interesting embodiment of the method, the address information may include absolute addresses. This approach may be chosen because it requires the least amount of runtime computation and is most easily used by dump analysis tools.

[0022] In a favorable embodiment, the method may include a step of adding reserved memory for subsequent enhancement of the target memory image by reserving space in the source memory image at a fixed offset from the source symbol address. This additional reserved memory may be added by a supporting compiler with the relevant options set at compile time. Since the target symbol is a mangled or hashed function name—that is, there is a conversion effect due to the limited size of the target symbol size (e.g., 8 bytes)—the additionally placed address information may be used for a pointer where additional information about the final address of the target symbol can be stored, for example, the full original function name (known from the source code).

[0023] According to a useful embodiment of the method, the step of enhancing the target memory image may be carried out by instructing the linker system to place the absolute addresses of the variable-length information within the target memory image location at a fixed offset from the target symbol address. Thus, if the software application crashes while running on the target OS, all the information required for a successful trace analysis should be directly available within the target memory image. As mentioned above, each piece of information preceding the target symbol address and / or any required free space may be created by the supporting compiler and placed within the target memory image.

[0024] According to another useful embodiment of the method, the step of enhancing the target memory image may be implemented by instructing the linker system (or simply the "linker") using instructions stored as relocation information in the target object file, which may have been created using a supporting compiler called with certain options, by adding absolute or absolute relocations in the source object file, or by adding absolute relocations in the target object file by a translation process.

[0025] According to an improved embodiment of the method, the step of enhancing the target memory image may also include, specifically prior to the enhancement step, a step of determining whether the target memory image location may have been created by a supporting compiler. Thus, even when a standard C compiler may be used, the proposed solution may be an add-on tool for the compiler to make the necessary changes to each object file or to ensure that subsequent enhancements do not create a corrupted target memory image.

[0026] According to a preferred embodiment of the method, the determination step may be performed by confirming that the target memory image location contains only a specific assembly instruction sequence. This may be a NOP operation ("no operation"), all-zero, all-one, or similar.

[0027] Thus, for each function entry, the available bytes before each function call can be determined or counted backwards from the function entry. Further, it can be confirmed that the available space (i.e., the number of available bytes) is greater than or equal to a size, for example 8 bytes, for absolute relocation addresses. And in an advantageous form, the absolute relocation points to the complete function name within the string table, which is in the form of the strtab section within the ELF (Executable and Linkable Format). Thus, it can be guaranteed that the complete name of the original function in the source code on the source system can be made available to any trace tool used within the target operating system environment of the converted object code. This solves the problem of mangled or hashed function names within the converted object code.

[0028] Furthermore, embodiments may take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code used by or in connection with a computer or any instruction execution system by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer-readable medium can be any device that can contain, store, communicate, propagate, or transport the program for use by or in connection with an instruction execution system, apparatus, or device.

Brief Description of the Drawings

[0029] Note that embodiments of the present invention are described with reference to different subject matters. In particular, some embodiments are described with reference to method-type claims, while other embodiments are described with reference to apparatus-type claims. However, those skilled in the art will assume, from the above and the following descriptions, that any combination of features belonging to one type of subject matter, in addition to any combination between features related to different subject matters, particularly between the features of method-type claims and the features of apparatus-type claims, are disclosed in this document, unless otherwise stated.

[0030] The aspects defined above and further aspects of the present invention will become apparent from the examples of embodiments to be described hereinafter, and are described with reference to examples of embodiments which are not intended to limit the present invention.

[0031] Preferred embodiments of the present invention will be described, by way of example only, and with reference to the following drawings:

[0032] [Figure 1] FIG. is a block diagram of an embodiment of a computer-implemented method of the present invention for converting a library from a source operating system to a target operating system.

[0033] [Figure 2] FIG. is a block diagram of an embodiment comprising means components for a proposed solution.

[0034] [Figure 3] FIG. visualizes a workflow diagram for converting a library between two given exemplary platforms.

[0035] [Figure 4] FIG. shows a diagram including a stream of binary code including functions to be called.

[0036] [Figure 5]This diagram shows the compiler linker pipeline used by the method proposed here.

[0037] [Figure 6] This is a block diagram of one embodiment of the present invention's conversion system for converting libraries from a source operating system to a target operating system.

[0038] [Figure 7] This figure shows one embodiment of a computing system comprising the system shown in Figure 6. [Modes for carrying out the invention]

[0039] In the context of this explanation, the following technical idioms, terms, and / or expressions may be used:

[0040] The term "source operating system" can refer to an operating system with a first application binary interface (ABI) that runs on a predetermined hardware architecture. A source operating system is typically used as a program development environment. Exemplary, it could be a Linux-type system running on a z architecture hardware platform.

[0041] The term "target operating system" may refer to a second operating system having a second ABI that is incompatible with the first ABI. Therefore, the feature sets of these ABIs may differ significantly, and thus the same relocation type may not exist on both OSs, making conversion impossible.

[0042] The source and target operating systems can be thought of as two different virtual machines running on the same hardware, and may, for example, share the same process in the same memory of a single computer system. Of course, the computer system may be a hybrid implementation of the two described scenarios, for example, the source and target operating systems are two virtual machines running as two different processes or loads on a single processor, but sharing one instance of memory on a given computer system.

[0043] The term "Application Binary Interface" (ABI) can refer to a set of operating system functions that can be used and called by an application program. A platform ABI can define the layout and metadata of binary object formats that can be used by further applications or OS services. These binary objects may comprise sections and segments containing, among other data, executable machine code, binary data and constants, symbol information, relocation information, and so on. Therefore, machine code, binary data, and constants can be considered the payload of an object. Relocation information, symbols, segments, and segment definitions may be part of the metadata required to load the payload into memory for execution or to enable further transformation and use of these objects. Machine code, binary data, and constants may depend directly on the processor architecture of the computer system and may simply be loosely coupled to the operating system being used by the calling conventions defined within the ABI.

[0044] The term "source object file" can refer to compiled source code that may not yet be linked into executable code using operating system libraries.

[0045] The term "target memory image" can also refer to a converted binary image that may be executable code compatible with the target operating system. In contrast, "source memory image" can refer to a memory image that is available and executable within the deployment environment, i.e., usable by the source OS.

[0046] The term "enhancing the target memory image" here may refer to adding information to object files that were not part of the source memory image. A supportive compiler may then add some space, which may be referred to as a "hot patch area," that can be overwritten by either the converter or the source linker during the translation process. The enhancement, in this case, may be a pointer to the function binary code. This pointer may point to a string table entry containing the full name of the (original) function whose code is contained within the shared object (compare Figure 5).

[0047] The term "source symbol" can refer to a location in the source memory image, often located at the beginning of a function's binary code, in a shared data area, or somewhere else defined by the linker. The term "source symbol name" can refer here to the name of the source symbol, often the name of a function, a data area, or some other location.

[0048] The term "relocation" can be a feature of an object file that allows for the assignment of load addresses to specific parts of object code. In its usage here, absolute relocation can define a load address within a specific virtual address space defined for the object. Relative relocation, on the other hand, can be understood here as a load address definition for a given reference address within the virtual address space. Since there may be (target) operating systems whose ABIs do not support relative relocation, providing a source object file without relative relocation information may be a prerequisite for successful translation. Thus, relocation records can be used to represent instructions to the linker to replace placeholders in the machine code of the binary data with relocation values ​​that become known only at link time. Relocation values ​​may be related to the address of a symbol, and therefore relocations can be divided into two main groups: absolute relocations that can refer to the address of the symbol, and relative relocations that can refer to the distance between the address of the symbol and the address of the placeholder.

[0049] The term "library" here may be used to refer to any object file or binary object that has been compiled in such a way that a GOT (global offset table) and a PLT (procedure linkage table) are created. This may be done when compiling a shared library in a narrower sense, for example, when creating an object intended to provide additional functionality at load time or runtime to an executable file or further shared object file. Thus, this definition of a shared library may include both strict shared library objects and other objects compiled from source code that may have originally been intended to produce a different type of object (e.g., an executable object), but were compiled in a manner similar to that of compiling a strict shared library as usual. Libraries created in this way may not have relative relocation. A shared library, or a library in general, or any other binary object, may be a target for conversion, where the concept proposed here may be useful, namely, preserving and making available the original function names of the source shared library within the target memory image (or target executable code).

[0050] The term "executable object" can refer to an object intended to be executed by a processor using an operating system. They can be constructed from one or more relocatable objects with the help of a linker. Depending on the linker, they may have all symbols, or only the undefined symbols necessary to discover functions in shared libraries. Since executable objects can have fixed locations in memory, they may have relative and absolute relocation (if supported by the target OS). Furthermore, ordinary binary objects can exist within three main groups: relocatable objects, executable objects, and shared libraries.

[0051] Before continuing with a detailed explanation of the diagram, let's describe some relevant system environment characteristics. As already mentioned, software development can be carried out on a modern computing environment that enables shared libraries; however, the final deployment may take place on a different computing environment that is incompatible with the software development environment. Thus, the source OS may not be compatible with the target OS, and the source ABI (Application Binary Interface) may not be compatible with the target ABI. While common solutions for such scenarios are already available, traditional software development practices also require the ability to perform traditional methods such as dump debugging and automatic name discovery during tracing in debugging.

[0052] Currently, tracing and using memory dump reading tools sometimes requires access to the full function name for it to be useful. If the function name has been mangled or hashed during the conversion, tracing cannot be used effectively; that is, the converted function name is meaningless to the developer. This can happen during conversion because the amount of bits / bytes available for the function name in the source OS environment is limited. Therefore, for example, _func_ and other solutions are not accessible outside of the source code (e.g., C source code) itself. Consequently, they cannot be used for dump or trace analysis within the target memory image.

[0053] A detailed explanation of the figures is given below. All instructions in the figures are schematic. First, a block diagram of one embodiment of the computer implementation method of the present invention for converting libraries from a source operating system to a target operating system is given. Then, further embodiments and embodiments of a conversion system for converting libraries from a source operating system to a target operating system are described.

[0054] Figure 1 shows a block diagram of a preferred embodiment of a computer implementation method 100 for converting libraries from a source operating system to a target operating system. Typically, this might involve converting shared libraries, such as those in a Linux-type operating system, to static libraries, such as those in a z / VM operating system.

[0055] The following preconditions may be assumed: The source operating system, e.g., Linux, has a source application binary interface that should be executable on a given instruction set architecture (e.g., z architecture). The target operating system, e.g., z / OS or z / VM, has a target application binary interface and may also be executable on the same given instruction set architecture. The target application binary interface shall be different from the source application binary interface; libraries are implemented by source object files; the source object files conform to the source application binary interface and include at least a source memory image, source symbol information, and source relocation information.

[0056] Under these assumptions, method 100 comprises a step 102 of creating a target memory image. The target memory image conforms to the target application binary interface, and the target memory is derived from the source memory image, i.e., it comprises memory image data sourced from the source memory image.

[0057] Method 100 also includes a step 104 in which the target memory image is enhanced using address information that points to variable-length information derived from the source symbol name of each external source symbol, which is part of the target memory image. Finally, and not to be forgotten, Method 100 includes a step 106 in which the target memory image is written to the target object file in order to implement the converted shared library by the target object file.

[0058] Figure 2 shows a block diagram 200 of one embodiment comprising means components for the proposed solution. At the top of the figure is a source operating system 202 comprising a source application binary interface 204. Also shown is a source object file 206 comprising a source memory image 208, source symbol information 210, and source relocation information 212.

[0059] Relocation can be a feature of an object file that allows for the assignment of load addresses to specific parts of object code. In its usage here, absolute relocation can define load addresses within a specific virtual address space defined for the object. Relative relocation, on the other hand, can be understood here as a load address definition for a given reference address within the virtual address space. Since there may be (target) operating systems whose ABIs do not support relative relocation, providing a source object file without relative relocation information may be a prerequisite for successful translation.

[0060] At the bottom of the figure is the target operating system 214 with its target application binary interface 216. The conversion 220 is a means for creating a target memory image that has pointers to variable-length information 224 for each external (source) symbol used by the target memory image 222. Thus, the conversion creates the target memory image, enhances it, and writes the target memory image to the target object file. The pointers are useful in overcoming the limitations of the target operating system, which may only be able to handle fixed-length function names, i.e., external symbols.

[0061] Figure 3 visualizes a diagram of workflow 300 for converting a shared library between two given exemplary platforms, i.e., from a development environment to a deployment environment. During the compilation phase 302, a C compiler (e.g., a standard C11 compiler) is used to compile the source code of the software to be deployed on the target system, e.g., library code. Regardless of whether the software is intended to be deployed as an executable object, a library, or any other target format that may be used on the target system, the compiler is configured to treat the source code as a shared library and generate one or more binary objects along with a GOT (Global Offset Table) and a PLT (Procedure Linkage Table). The entire source code remains unchanged, and further compiler options are set as usual to reflect architectural details, linking phases, and / or further desired characteristics of the resulting object files. To prepare and / or configure the merging phase, additional compiler options and / or linking phase characteristics required to create the shared library may be set, if necessary.

[0062] During linking stage 304, a (standard) linker is used to link different binary objects within a single (shared) library. During this stage, the linker combines the binary object files into a single main object file, and then converts the main object file into an absolute main object file without relative relocation.

[0063] During the merging phase 306, the segments of the memory image of the absolute main object file are merged into a contiguous memory image. This may be done by the linker by passing a linker script to the linker, or alternatively, the segmented memory image may be converted into a contiguous memory image using the merging function of a conversion utility. The merging phase may be performed at link time or following the generation of the absolute main object file.

[0064] During the example shown in Figure 3, the merging stage (i.e., stage 306) may also include a stage for discarding unnecessary binary segments. This capability can be used to reduce the size of the memory image by, for example, excluding all segments that do not contain memory image data or any symbols or relocation information.

[0065] During conversion phase 308, the relocations and symbols present in the absolute main object file are converted to meet the specifications of the target ABI. This may involve mapping the source information's type, name, symbol, and / or address space to the relocation types, naming conventions, and / or address space required by the target ABI (Application Binary Interface). In some cases, suitable features of the target ABI may be selected to avoid or minimize conversion effort.

[0066] During the write phase 310, the converted memory image data, symbol information, and relocation information are written to the target object file according to the format and / or layout specifications of the target ABI. A target object header for the target object file is generated and included in the target object file. Additionally, a symbol translation dictionary may be created.

[0067] Figure 4 shows diagram 400 with a stream of binary code 402, which also includes an exemplary function binary call 406 (e.g., a subroutine). Because the number of bytes for function call identifiers or names is limited within the target operating system, identifiers may be mangled or hashed, and therefore not readily human-readable. However, several additional available bytes, e.g., 8 bytes (or any other sufficient number of bytes), are reserved before each symbol or integrated function binary code 406 for an absolute relocation pointer 404. The pointer 404 lies immediately before the target symbol address and points to an absolute address in the target memory image (outside the core executable code), e.g., the starting address of a string table that stores the complete original function name 410 in the source code. Thus, tracing and debugging tools in the deployment environment may have access to the clear text or the complete function name 410.

[0068] Figure 5 shows the compiler / linker pipeline available by the method proposed herein. It begins with source code 502, which is used as input to source compiler 504 in the source / development environment. Source compiler 504 outputs object code 506. One or more object code elements 506 are linked by source linker 508 to produce shared object 510. Optionally, this goes through conversion by converter 512 as proposed herein. Alternatively, conversion may also be performed by extended source linker 508. Next, the output of converter 512 (or extended source linker) is directed to target linker 516, which uses the converted object 514 as input to produce target executable file, which can then be loaded into the target system under the target OS.

[0069] Figure 6 shows a block diagram of one embodiment of a conversion system 600 for converting a library from a source operating system to a target operating system. The assumptions already mentioned can be repeated here: the source operating system, e.g., Linux, has a source application binary interface that should be executable on a given instruction set architecture (e.g., z architecture). The target operating system, e.g., z / OS or z / VM, has a target application binary interface and may also be executable on the same given instruction set architecture. The target application binary interface is different from the source application binary interface; the library is implemented by a source object file; the source object file conforms to the source application binary interface and comprises at least a source memory image, source symbol information, and source relocation information.

[0070] The system 600 comprises at least one or more processors 602, and memory 604 operably coupled to one or more processors 602, wherein memory 604 stores a portion of program code that, when executed by one or more processors 602, enables one or more processors 602 to create a target memory image, specifically by a creation module 606, wherein the target memory image conforms to a target application binary interface, and the target memory is derived from a source memory image.

[0071] Additionally, one or more processors 602 are also capable of enhancing the target memory image using address information that points to variable-length information derived from the source symbol name of each external source symbol, specifically by an enhancement unit 608, and of writing the target memory image to a target object file using a writer module 610 so that the converted shared library is implemented by the target object file.

[0072] It should also be noted that all functional units, modules, and functional blocks—one or more processors 602, memory 604, creation module 606, enhancement unit 608, and writer module 610—may be coupled together to communicate with one another for signaling or message exchange in a selected one-to-one manner. Alternatively, the functional units, modules, and functional blocks may be linked to the system internal bus system 618 for selective signaling or message exchange.

[0073] Various aspects of this disclosure are described by explanatory text, flowcharts, block diagrams of computer systems, and / or block diagrams of machine logic included in embodiments of computer program products (CPPs). With respect to any flowchart, operations may be performed in a different order than those shown in a given flowchart, depending on the technology involved. For example, also depending on the technology involved, two operations shown in consecutive blocks of a flowchart may be performed in reverse order, as a single integrated stage, simultaneously, or with at least partial temporal overlap.

[0074] Embodiments of a computer program product (CPP embodiment or CPP) are terms used in this disclosure to describe any set of one or more storage media (also called mediums) that collectively comprise a set of one or more storage devices that collectively comprise machine-readable code corresponding to instructions and / or data for performing computer operations defined in a given CPP claim. A storage device is any tangible device capable of holding and storing instructions for use by a computer processor. Computer-readable storage media may be, but are not limited to, electronic storage media, magnetic storage media, optical storage media, electromagnetic storage media, semiconductor storage media, mechanical storage media, or any suitable combination thereof. Some known types of storage devices, including these media, include diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital purpose discs (DVDs), memory sticks, floppy disks, mechanically encoded devices (such as pits / lands formed on the main surface of a punch card or disk), or any suitable combination of the foregoing. When the term "computer-readable storage medium" is used in this disclosure, it shall not be construed as storage in the form of a transient signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides, light pulses passing through optical fiber cables, electrical signals transmitted through wires, and / or other transmission media.As those skilled in the art will understand, data is typically moved at several intermittent points during the normal operation of a storage device, such as during access, defragmentation, or garbage collection; however, data is not transient while it is stored, and therefore the above does not mean that the storage device is transient.

[0075] Figure 7 shows a computing environment 700 that includes an example of an environment for executing at least some of the computer code involved in carrying out the methods of the present invention, such as a computer implementation method 750 for converting libraries from a source operating system to a target operating system.

[0076] In addition to block 750, the computing environment 700 includes, for example, a computer 701, a wide area network (WAN) 702, an end user device (EUD) 703, a remote server 704, a public cloud 705, and a private cloud 706. In this embodiment, the computer 701 includes a processor set 710 (including processing circuits 720 and a cache 721), a communication fabric 711, volatile memory 712, persistent storage 713 (including an operating system 722 and the block 750 identified above), a peripheral device set 714 (including a user interface (UI) device set 723, storage 724, and an Internet of Things (IoT) sensor set 725), and a network module 715. The remote server 704 includes a remote database 730. The public cloud 705 includes a gateway 740, a cloud orchestration module 741, a host physical machine set 742, a virtual machine set 743, and a container set 744.

[0077] Computer 701 may take the form of a desktop computer, laptop computer, tablet computer, smartphone, smartwatch or other wearable computer, mainframe computer, quantum computer, or any other form of computer or mobile device currently known or to be developed in the future that is capable of running programs, accessing networks, or querying databases such as the remote database 730. As is well understood in the field of computer technology, and depending on the technology, the execution of a computer implementation method may be distributed among multiple computers and / or multiple locations. On the other hand, in this description of the computing environment 700, in order to keep the description as simple as possible, the detailed discussion will focus on a single computer, specifically computer 701. Although computer 701 is not shown in the cloud in Figure 7, it may be located in the cloud. On the other hand, computer 701 is not required to be located in the cloud, except to any extent that may be shown positively.

[0078] The processor set 710 includes one or more computer processors of any type currently known or to be developed in the future. The processing circuitry 720 may be distributed across multiple packages, for example, multiple interconnected integrated circuit chips. The processing circuitry 720 may implement multiple processor threads and / or multiple processor cores. The cache 721 is memory located within the processor chip package and is typically used for data or code that should be available for high-speed access by threads or cores running on the processor set 710. The cache memory is typically organized into multiple levels depending on its relative proximity to the processing circuitry. Alternatively, some or all of the cache for the processor set may be located "off-chip". In some computing environments, the processor set 710 may operate using qubits and be designed to perform quantum computing.

[0079] Computer-readable program instructions are typically loaded onto computer 701, causing the processor set 710 of computer 701 to perform a series of operational steps, thereby executing the computer implementation method. Instructions thus executed will instantiate the methods specified in the flowcharts and / or descriptions of the computer implementation methods contained in this document (collectively referred to as the "Methods of the Invention"). These computer-readable program instructions are stored in various types of computer-readable storage media, such as the cache 721 and other storage media discussed below. The program instructions and associated data are accessed by the processor set 710 to control and direct the implementation of the Methods of the Invention. In the computing environment 700, at least some of the instructions for implementing the Methods of the Invention may be stored in block 750 within persistent storage 713.

[0080] The communication fabric 711 is a signal conduction path that enables various components of the computer 701 to communicate with one another. Typically, this fabric is made up of switches and conductive paths, such as buses, bridges, physical input / output ports, and similar switches and conductive paths. Other types of signal communication paths, such as fiber optic communication paths and / or wireless communication paths, may be used.

[0081] Volatile memory 712 is any type of volatile memory currently known or to be developed in the future. Examples include dynamic random-access memory (RAM) or static RAM. Volatile memory typically features random access, although this is not required unless explicitly stated. In computer 701, volatile memory 712 is located in a single package and resides inside computer 701, but alternatively or additionally, volatile memory may be distributed across multiple packages and / or located externally to computer 701.

[0082] Persistent storage 713 is any form of non-volatile storage for a computer that is currently known or may be developed in the future. The non-volatility of this storage means that the stored data is maintained regardless of whether power is supplied to the computer 701 and / or directly to the persistent storage 713. Persistent storage 713 may be read-only memory (ROM), but typically at least a portion of the persistent storage allows for writing, deleting, and rewriting of data. Some well-known forms of persistent storage include magnetic disks and solid-state storage devices. The operating system 722 may take several forms, such as various known proprietary operating systems employing a kernel or open-source portable operating system interface type operating systems. The code contained in block 750 typically includes at least some of the computer code involved in carrying out the methods of the present invention.

[0083] The peripheral device set 714 includes a set of peripheral devices for the computer 701. Data communication connections between the computer 701's peripheral devices and other components may be implemented in various ways, such as Bluetooth connections, near-field communication (NFC) connections, connections made by cables (such as Universal Serial Bus (USB) type cables), insert-type connections (e.g., Secure Digital (SD) cards), connections made through local area communication networks, and even connections made through wide area networks such as the Internet. In various embodiments, the UI device set 723 may include components such as a display screen, speakers, microphones, wearable devices (such as goggles and smartwatches), keyboards, mice, printers, touchpads, game controllers, and haptic devices. Storage 724 is external storage such as an external hard drive, or insertable storage such as an SD card. Storage 724 may be persistent and / or volatile. In some embodiments, storage 724 may take the form of a quantum computing storage device for storing data in the form of qubits. In embodiments where computer 701 is required to have a large amount of storage (for example, computer 701 locally stores and manages a large database), this storage may be provided by peripheral storage devices designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. The IoT sensor set 725 consists of sensors that may be used in an Internet of Things application. For example, one sensor may be a thermometer and another may be a motion detector.

[0084] The network module 715 is a collection of computer software, hardware, and firmware that enables computer 701 to communicate with other computers via the WAN 702. The network module 715 may include hardware such as a modem or Wi-Fi signal transceiver, software for packetizing and / or depacketizing data for communication network transmission, and / or web browser software for transmitting data over the internet. In some embodiments, the network control and network forwarding functions of the network module 715 are performed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing software-defined networking (SDN)), the control and forwarding functions of the network module 715 are performed on physically separate devices so that the control function manages several different network hardware devices. Computer-readable program instructions for carrying out the method of the present invention can typically be downloaded from an external computer or external storage device to computer 701 via a network adapter card or network interface included in the network module 715.

[0085] WAN702 is any wide area network (e.g., the Internet) capable of transmitting computer data over non-local distances by any technology currently known or to be developed for transmitting computer data. In some embodiments, the WAN may be replaced and / or complemented by a local area network (LAN), such as a Wi-Fi network, designed to transmit data between devices located in a local area. The WAN and / or LAN typically include computer hardware such as copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and edge servers.

[0086] The end-user device (EUD) 703 is any computer system used and controlled by an end-user (e.g., a customer of the company operating computer 701), and may take any of the forms discussed above in relation to computer 701. EUD 703 typically receives useful and valuable data from the operation of computer 701. For example, in a hypothetical case where computer 701 is designed to provide recommendations to an end-user, these recommendations would typically be transmitted from computer 701's network module 715 to EUD 703 via WAN 702. Thus, EUD 703 can display or otherwise present the recommendations to the end-user. In some embodiments, EUD 703 may be a client device such as a thin client, heavy client, mainframe computer, or desktop computer.

[0087] The remote server 704 is any computer system that provides at least some data and / or functionality to computer 701. The remote server 704 may be controlled and used by the same entity that operates computer 701. The remote server 704 represents a machine that collects and stores useful and valuable data for use by other computers, such as computer 701. For example, in a hypothetical case where computer 701 is designed and programmed to provide recommendations based on historical data, this historical data may be provided to computer 701 from the remote database 730 of the remote server 704.

[0088] Public Cloud 705 is any computer system available for use by multiple entities, providing on-demand availability of computer system resources and / or other computing capabilities, particularly data storage (cloud storage) and computing power, without direct active management by the user. Cloud computing typically leverages resource sharing to achieve consistency and economies of scale. Direct active management of Public Cloud 705's computing resources is performed by the computer hardware and / or software of the Cloud Orchestration Module 741. The computing resources provided by Public Cloud 705 are typically implemented by virtual computing environments running on various computers that make up the computers of the host physical machine set 742, which is a universe of physical computers located within and / or available to Public Cloud 705. Virtual computing environments (VCEs) typically take the form of virtual machines from the virtual machine set 743 and / or containers from the container set 744. These VCEs may be stored as images and are understood to be transferable either as images or after instantiation of VCEs, within and between various physical machine hosts. The cloud orchestration module 741 manages image transfer and storage, deploys new VCE instances, and manages active instances of VCE deployments. The gateway 740 is a collection of computer software, hardware, and firmware that enables the public cloud 705 to communicate over the WAN 702.

[0089] Here, we will provide some further explanation about virtualized computing environments (VCEs). A VCE can be stored as an "image." A new active instance of a VCE can be instantiated from an image. Two well-known types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to an operating system feature where the kernel allows for the existence of multiple isolated user-space instances called containers. These isolated user-space instances typically behave like actual computers from the perspective of the programs running within them. Computer programs running on a typical operating system can utilize all the resources of that computer, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, programs running inside a container can only use the contents of the container and the devices allocated to that container; this feature is known as containerization.

[0090] Private Cloud 706 is similar to Public Cloud 705, except that its computing resources are available for use by a single enterprise only. While Private Cloud 706 is shown as being in communication with WAN 702, in other embodiments, a private cloud may be completely isolated from the internet and accessible only via a local / private network. A hybrid cloud is a combination of multiple clouds of different types (e.g., private, community, or public cloud types), often implemented by different vendors. Each of the multiple clouds remains a distinct, discrete entity, but the larger hybrid cloud architecture is bound together by standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the multiple configured clouds. In this embodiment, both Public Cloud 705 and Private Cloud 706 are part of a larger hybrid cloud.

[0091] It should also be noted that the conversion system 600 (compare Figure 6) for converting libraries from the source operating system to the target operating system may be an operational subsystem of computer 701 and may be attached to the computer's internal bus system.

[0092] The terminology used herein is intended solely to describe specific embodiments and is not intended to limit the invention. Where used herein, the singular forms a, an, and the are intended to include the plural forms unless the context explicitly indicates otherwise. It will be further understood that the terms comprises and / or comprising, where used herein, specify the presence of the described features, integers, stages, actions, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, stages, actions, elements, components, and / or groups thereof.

[0093] All corresponding structures, materials, actions, and equivalents of all means or steps plus function elements in the following claims are intended to include any structures, materials, or actions for carrying out their function in combination with other claimed elements specifically claimed. While the description of the invention has been presented for illustrative and explanatory purposes, it is not intended to be exhaustive or to limit the invention to the disclosed forms. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the invention. The embodiments have been selected and described to best illustrate the principles and practical applications of the invention and to enable those other skilled in the art to understand the invention in relation to various embodiments with various modifications suitable for specific uses intended.

[0094] In short, the concept of this invention can be summarized by the following points: [Item 1] A computer implementation method for converting libraries from a source operating system to a target operating system, The aforementioned source operating system includes a source application binary interface, The aforementioned target operating system includes a target application binary interface, The target application binary interface is different from the source application binary interface. The aforementioned library is implemented by source object files, The source object file conforms to the source application binary interface and includes at least a source memory image, source symbol information, and source relocation information. The aforementioned method, In the step of creating a target memory image, the target memory image conforms to the target application binary interface, and the target memory is derived from the source memory image. The steps include enhancing the target memory image using address information that points to variable-length information derived from the source symbol name of each external source symbol, and The step of writing the target memory image to the target object file so that the converted shared library is implemented by the target object file. A computer implementation method comprising the following features. [Item 2] The method described in item 1, wherein the source relocation information does not include relative relocation information. [Item 3] The method according to item 1 or 2, wherein the step of enhancing the target memory image is performed by placing address information within a target memory image location at a fixed offset from the target symbol address. [Item 4] The method according to item 3, wherein the address information includes a relative offset representing the distance between the address information in the target memory image and the address of the corresponding variable-length information in the target memory image. [Item 5] The address information, including an absolute address, is as described in item 3 or 4. [Item 6] The step of adding reserved memory for subsequent enhancement of the target memory image by reserving space in the source memory image at a fixed offset from the source symbol address. The method described in any of items 3 to 5, also comprising: [Item 7] The method of item 5, wherein the step of enhancing the target memory image is performed by instructing the linker system to place the absolute address of the variable-length information within the target memory image location at a fixed offset from the target symbol address. [Item 8] The method of item 7, wherein the instruction given to the linker system is based on the instruction stored as relocation information in the target object file. [Item 9] The step of enhancing the target memory image is as follows: The method according to any one of items 1 to 8, further comprising the step of determining that the target memory image location was created by a supporting compiler. [Item 10] The method according to item 9, wherein the determination step is performed by confirming that the target memory image location contains only a specific assembly instruction sequence. [Item 11] A conversion system for converting libraries from a source operating system to a target operating system, The aforementioned source operating system includes a source application binary, The aforementioned target operating system includes a target application binary interface, The target application binary interface is different from the source application binary interface. The aforementioned library is implemented by source object files, The source object file conforms to the source application binary interface and includes at least a source memory image, source symbol information, and source relocation information. The aforementioned system, The system comprises one or more processors and memory operably coupled to the one or more processors, wherein the memory is executed by the one or more processors and the one or more processors To create a target memory image, wherein the target memory image conforms to the target application binary interface, and the target memory is derived from the source memory image. The target memory image is enhanced using address information that points to variable-length information derived from the source symbol name of each external source symbol, and Writing the target memory image to the target object file so that the converted shared library is implemented by the target object file. A conversion system that stores the program code portion that enables this functionality. [Item 12] The system described in item 11, in which the aforementioned source relocation information does not include relative relocation information. [Item 13] The aforementioned one or more processors The system according to item 11 or 12, which also enables the enhancement of the target memory image by placing address information within a target memory image location at a fixed offset from the target symbol. [Item 14] The system according to item 13, wherein the address information includes a relative offset representing the distance between the address information in the target memory image and the address of the corresponding variable-length information in the target memory image. [Item 15] The address information includes absolute addresses, as described in item 13 or 14. [Item 16] The aforementioned one or more processors The system according to any one of items 13 to 15, which also makes it possible to add reserved memory for subsequent enhancement of the target memory image by reserving space in the source memory image at a fixed offset from the source symbol address. [Item 17] The aforementioned one or more processors The system according to item 16, which also enables the enhancement of the target memory image by instructing the linker system to place the absolute address of the variable-length information within the target memory image location at a fixed offset from the target symbol address. [Item 18] The system described in item 17, wherein issuing the aforementioned instructions to the linker system is based on instructions stored as relocation information in the target object file. [Item 19] The one or more processors, during the enhancement of the target memory image, The system described in any of items 11 to 18, which also enables the determination that the target memory image location was created by a supporting compiler. [Item 20] A computer program product for converting libraries from a source operating system to a target operating system, The aforementioned source operating system includes a source application binary, The aforementioned target operating system includes a target application binary interface, The target application binary interface is different from the source application binary interface. The aforementioned library is implemented by source object files, The source object file conforms to the source application binary interface and includes at least a source memory image, source symbol information, and source relocation information. The computer program product comprises a computer-readable storage medium having program instructions that are implemented therein, and the program instructions are executable by one or more computing systems or controllers, and the one or more computing systems To create a target memory image, wherein the target memory image conforms to the target application binary interface, and the target memory is derived from the source memory image. The target memory image is enhanced using address information that points to variable-length information derived from the source symbol name of each external source symbol, and Writing the target memory image to the target object file so that the converted shared library is implemented by the target object file. A computer program product that performs a certain action.

Claims

1. A computer implementation method for converting libraries from a source operating system to a target operating system, The aforementioned source operating system includes a source application binary interface, The aforementioned target operating system includes a target application binary interface, The target application binary interface is different from the source application binary interface. The aforementioned library is implemented by source object files, The source object file conforms to the source application binary interface and includes at least a source memory image, source symbol information, and source relocation information. The aforementioned method, In the step of creating a target memory image, the target memory image conforms to the target application binary interface, and the target memory is derived from the source memory image. The steps include enhancing the target memory image using address information that points to variable-length information derived from the source symbol name of each external source symbol, and The step of writing the target memory image to the target object file so that the converted shared library is implemented by the target object file. A computer implementation method comprising the following features.

2. The method according to claim 1, wherein the source relocation information does not include relative relocation information.

3. The method according to claim 1 or 2, wherein the step of enhancing the target memory image is carried out by placing address information within a target memory image location at a fixed offset from the target symbol address.

4. The method according to claim 3, wherein the address information includes a relative offset representing the distance between the address information in the target memory image and the address of the corresponding variable-length information in the target memory image.

5. The method according to claim 3 or 4, wherein the address information includes an absolute address.

6. The step of adding reserved memory for subsequent enhancement of the target memory image by reserving space in the source memory image at a fixed offset from the source symbol address. The method according to any one of claims 3 to 5, also comprising:

7. The method according to claim 5, wherein the step of enhancing the target memory image is carried out by instructing the linker system to place the absolute address of the variable-length information within a target memory image location at a fixed offset from the target symbol address.

8. The method of claim 7, wherein issuing the command to the linker is based on a command stored as relocation information in the target object file.

9. The step of enhancing the target memory image is as follows: The method according to any one of claims 1 to 8, further comprising the step of determining that the target memory image location was created by a supporting compiler.

10. The method according to claim 9, wherein the determination step is performed by confirming that the target memory image location contains only a specific assembly instruction sequence.

11. A conversion system for converting libraries from a source operating system to a target operating system, The aforementioned source operating system includes a source application binary, The aforementioned target operating system includes a target application binary interface, The target application binary interface is different from the source application binary interface. The aforementioned library is implemented by source object files, The source object file conforms to the source application binary interface and includes at least a source memory image, source symbol information, and source relocation information. The aforementioned system, The system comprises one or more processors and memory operably coupled to the one or more processors, wherein the memory, when executed by the one or more processors, To create a target memory image, wherein the target memory image conforms to the target application binary interface, and the target memory is derived from the source memory image. The target memory image is enhanced using address information that points to variable-length information derived from the source symbol name of each external source symbol, and Writing the target memory image to the target object file so that the converted shared library is implemented by the target object file. A conversion system that stores the program code portion that enables this functionality.

12. The system according to claim 11, wherein the source relocation information does not include relative relocation information.

13. The aforementioned one or more processors are The system according to claim 11 or 12, wherein the enhancement of the target memory image can also be performed by placing address information within a target memory image position at a fixed offset from the target symbol.

14. The system according to claim 13, wherein the address information includes a relative offset representing the distance between the address information in the target memory image and the address of the corresponding variable-length information in the target memory image.

15. The system according to claim 13 or 14, wherein the address information includes an absolute address.

16. The aforementioned one or more processors are The system according to any one of claims 13 to 15, wherein it is also possible to add reserved memory for subsequent enhancement of the target memory image by reserving space in the source memory image at a fixed offset from the source symbol address.

17. The aforementioned one or more processors are The system according to claim 16, wherein the enhancement of the target memory image can also be performed by instructing the linker system to place the absolute address of the variable-length information within the target memory image position at a fixed offset from the target symbol address.

18. The system according to claim 17, wherein issuing the command to the linker is based on a command stored as relocation information in the target object file.

19. The one or more processors, during the enhancement of the target memory image, The system according to any one of claims 11 to 18, which also enables determination that the target memory image location was created by a supporting compiler.

20. A computer program product for converting libraries from a source operating system to a target operating system, The aforementioned source operating system includes a source application binary, The aforementioned target operating system includes a target application binary interface, The target application binary interface is different from the source application binary interface. The aforementioned library is implemented by source object files, The source object file conforms to the source application binary interface and includes at least a source memory image, source symbol information, and source relocation information. The computer program product comprises a computer-readable storage medium having program instructions that are implemented therein, and the program instructions are executable by one or more computing systems or controllers, and the one or more computing systems To create a target memory image, wherein the target memory image conforms to the target application binary interface, and the target memory is derived from the source memory image. The target memory image is enhanced using address information that points to variable-length information derived from the source symbol name of each external source symbol, and The target object file is written to the target memory image so that the converted library is implemented by the target object file. A computer program product that performs a certain action.

Images