Function name resolution in library transformations on same architecture

Abstract

A computer-implemented method for transforming a library from a source operating system to a target operating system is disclosed. Thereby, the source operating system comprises an ABI, the target operating system comprises a target ABI, the target ABI is different from the source ABI, the library is implemented by a source object file, the source object file conforms to the source application binary interface and comprises a source memory image, a source symbol and source relocation information. The method further includes creating a target memory image conforming to the target application binary interface, where the target memory is derived from the source memory image; enriching the target memory image with address information directed to the variable length information; and writing the target memory image to the target object file to implement the transformed library from the target object file.

Description

TECHNICAL FIELD

[0001] The present invention relates generally to library transformation from a source to a target operating system, and in particular to a computer-implemented method for transforming a library from a source operating system to a target operating system. The invention further relates to a related transformation system and to a related computer program product. BACKGROUND

[0002] Today’s IT (information technology) infrastructures, especially in large enterprises and government organizations, have many legacy systems and deploy many legacy applications. A significant portion of the available IT budget must be spent on these systems and applications, making investment in new, future-oriented systems potentially difficult. As an example, the IBM operating system z / VM has a 50-year history that is mostly written in HLASM, PLX, and C. Many programmer resources can no longer be effective. In addition, z / VM can currently only be compiled, assembled, and linked on another z / VM system. Unfortunately, there is also no available contemporary C compiler support due to the availability of z / OS 1.13.

[0003] However, software development does not always occur on the system on which the software will later be executed. For example, software that is to be applied under a legacy operating system can be developed using a Linux-type development environment. Typically, the operating system (OS) under which the new software is developed has an application binary interface (ABI) that does not match the ABI of the legacy OS on which the new software is to be deployed. To this end, object files that conform to the development ABI can not conform to the deployment ABI. In addition, the deployment system can not support the current compiler, source code manager, and / or object file format of the development system, so that object files that conform to the target ABI can not be created by compiling the source code on the deployment system without modifying the source code and / or the deployment system. This can equally apply to debugging tools for executable code in the target operating system environment. Therefore, at least a method for transforming object files from a development operating system to a deployment operating system and also making legacy debugging options available in the target or deployment operating system environment is desirable.

[0004] Some publications relate to a computer-implemented method for transforming a library from a source operating system to a target operating system. For example, document US 2020 / 0226009 A1 discloses requesting workloads to be performed by a next function, wherein a data transfer overhead is customized based on a memory sharing capability of the next function. Thereby, the data transfer overhead comprises one or more of: sending a memory address pointer, a virtual memory address pointer; or sending data to the next function.

[0005] Additionally, document US 2017 / 0039050 Al discloses techniques for binary translation. Thereby, a host platform receives a program for a guest platform different from the host. The program uses a set of shared objects or dynamic load libraries and is incompatible with the host platform. Thereby, the host platform determines whether the host platform has a corresponding shared object or dynamic load library that implements a common external interface with a particular shared object or dynamic load library from within the set.

[0006] However, none of the available techniques has a solution for cross-system development that considers, for example, z / VM as a target system, and in particular, none of the solutions supports variable function name length on legacy operating systems for tracing and debugging purposes. SUMMARY

[0007] According to an aspect of the present invention, a computer-implemented method for transforming a library from a source operating system to a target operating system can be provided. Thereby, the source operating system can comprise a source application binary interface, the target operating system can comprise a target application binary interface, the target application binary interface being different from the source application binary interface, the library being implemented by a source object file, and the source object file can conform to the source application binary interface and comprise at least a source memory map, source symbol information, and source relocation information.

[0008] The method can comprise creating a target memory map, wherein the target memory map conforms to the target application binary interface, and wherein the target memory is derived from the source memory map; enriching the target memory map with address information pointing to variable length information derived from a source symbol name for each external source symbol; and writing the target memory map to the target object file to implement a transformed library by the target object file.

[0009] According to another aspect of the present invention, a transformation system for transforming a library from a source operating system to a target operating system can be provided. Thereby, the source operating system can comprise a source application binary interface, the target operating system can comprise a target application binary interface, the target application binary interface being different from the source application binary interface, the library being implemented by a source object file, and the source object file can conform to the source application binary interface and comprise at least a source memory map, source symbol information, and source relocation information.

[0010] The system can include one or more processors and a memory operatively coupled to the one or more processors, wherein the memory stores program code portions that, when executed by the one or more processors, enable the one or more processors to: create a target memory map, wherein the target memory map conforms to the target application binary interface, and wherein the target memory is derived from the source memory map; enrich the target memory map with address information that points to variable length information derived from a source symbol name for each external source symbol; and write the target memory map to the target object file to enable transformed libraries by the target object file.

[0011] The proposed computer-implemented method for transforming libraries from a source operating system to a target operating system can provide a number of advantages, technical effects, contributions and / or improvements:

[0012] In particular, this can be particularly notable for the ability to support tracing and easier use of dump reading tools in the target operating system environment, as function names can now be tracked and clearly identified in the trace report. In short, the solution can be based on including a strtab ELF section (i.e., string table) in the transformed target memory map and adding pointers in a hot patch area in front of the name of the function or other object. Additionally, relocations can be added (if needed) to resolve absolute pointers at final linking.

[0013] As such, developers can trace and trace software code now written under an operating system environment (e.g., a modern development operating system) that is not the deployment operating system environment (e.g., a legacy deployment operating system).

[0014] Thus, software developers who are accustomed to traditional software development approaches on legacy operating systems can use traditional debugging tools, despite the fact that the information needed to do so is typically not available in the target memory map and is also not available in the target object file. The solution proposed herein advantageously remedies this deficiency.

[0015] In this way, modern software development environments can be used to develop software for more traditional software deployment environments and continue to make available the traditional tools for debugging in the deployment operating system environment. Thus, the established software infrastructure provided by the target operating system for which the software is being developed can be preserved. This can reduce the need for a large investment in updating and improving the target deployment system in order to support modern software development environments. This can be particularly beneficial for newly hired developers for which it is not necessary to fully understand the details of the target system model in order to develop software libraries using familiar and up-to-date development environments on modern computing systems. In particular, modern software development environments can leverage well-known open source solutions that can not have been available at the time the target operating system was released, but are familiar to a large number of developers today. Thus, it is possible to use available resources, in particular more traditional, well-proven computing environments and architectures, without the need to re-invent all the tools available in modern software development environments that are also used for traditional systems. This can help to save time, money and electricity and thus help to protect the environment.

[0016] As a further advantageous aspect, additional proposals regarding the (self-) discovery of runtime function names via the already mentioned pointers can also be considered to become cleverly feasible.

[0017] In the following, additional embodiments of the inventive concept applicable to the method as well as to the system will be described.

[0018] According to an embodiment of interest of the method, the source relocation information can be free of relative relocation information. Having relative relocation information is typical for modern shared library technology. The executable code of a shared library can be moved around in main memory without any impact on its executability. However, if the target / deployment environment does not allow for relative location information in its executable, it can be beneficial if the source objects being transformed can be free of any relative relocation information.

[0019] According to an advantageous embodiment of the method, enriching the target memory image can be performed by placing address information at target memory image locations at a fixed offset from the target symbol addresses. This can be achieved by a support linker or by the transformation process. In particular, the support linker can be a source system linker. The source system linker can belong to the "conversion chain" used from source code to executable code, i.e. a source compiler, a source linker, a transformation system or transformer performing the method presented herein, a target linker for generating a target executable. It can be noted that the compiler should start with corresponding options or flags.

[0020] According to a further advantageous embodiment of the method, the address information can comprise a relative offset, which represents a distance between the address information within the target memory image and an address of the corresponding variable length information within the target memory image.

[0021] According to a further interesting embodiment of the method, the address information can comprise an absolute address. This approach can be chosen because it can require the least amount of runtime computation and because it is most easily used by dump analysis tools.

[0022] According to an advantageous embodiment, the method can comprise adding reserved memory for a subsequent enrichment 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 can have been added by a support compiler, for which the relevant option has been set at compile time. Because the target symbol can be a scrambled or hashed function name, i.e. a transformed version due to the limited size of the target symbol size (e.g. 8 bytes), the additionally placed address information can be used for a pointer at which additional information about the target symbol can be stored, e.g. the full original function name as known from the source code.

[0023] According to a useful embodiment of the method, enriching the target memory image can be performed by instructing a linker system to place an absolute address of the variable length information at the target memory image location at a fixed offset from the target symbol address. Thus, if a software application crashes when running on the target operating system, all information needed for a successful trace analysis should be directly available in the target memory image. As mentioned above, the required free space before the corresponding information and / or target symbol address can have been created and placed into the target memory image by a support compiler.

[0024] According to a further useful embodiment of the method, enriching the target memory image can be achieved by instructing a linker system (or simply "linker") with instructions stored as relocation information in the target object file, which can have been created by a support compiler invoked with specific options by adding absolute or absolute relocations to the source object file by a transformation process or by adding absolute relocations to the target object file.

[0025] According to an enhanced embodiment of the method, enriching the target memory image can further comprise determining (in particular before the enriching) that the target memory image location can have been created by a support compiler. Thus, even if a standard C compiler can be used, the proposed solution can be an additional tool for the compiler in order to perform the required changes to the corresponding object file or to ensure that later enriching will not create a broken target memory image.

[0026] According to a preferred embodiment of the method, the determining can be performed by verifying that the target memory image location comprises only a specific sequence of assembly instructions. This can be a NOP operation ("no operation"), all zeros, all ones or similar operations.

[0027] Thus, for each function entry, the available bytes in front of each function call can be determined or counted from the function entry backwards. Furthermore, it can be verified that the available space (i.e. the number of available bytes) is greater or equal to the size of, for example, eight bytes for an absolute relocation address. As an advantageous form, the absolute relocation points to the complete function name in a string table (i.e. in the form of the strtab section in ELF (Executable and Linkable Format)). This way, it can be guaranteed that the original function's complete name of the source code on the source system can be available to any trace tools used in the target operating system environment of the transformed object code. This solves the problem of scrambled or hashed function names in the transformed object code.

[0028] Furthermore, embodiments can take the form of an associated computer program product accessible from a computer-usable or computer-readable medium providing program code for use 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 apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. BRIEF DESCRIPTION OF DRAWINGS

[0029] It should be noted that embodiments of the present application are described with reference to different subject matters. In particular, some embodiments are described with reference to a method claim whereas other embodiments are described with reference to an apparatus claim. However, a person skilled in the art will gather from the above and the following description that, unless otherwise indicated, in addition to any combination of features belonging to one type of subject matter, also any combination between features of different subject matters, in particular between features of the method claims and features of the apparatus claims, is considered to be disclosed within this file.

[0030] The above aspects of the present application and other aspects thereof will become apparent from the examples of embodiments described below and explained with reference to examples of embodiments of the present application, which are not limited thereto.

[0031] The preferred embodiments of the present application will be described by way of example only with reference to the following drawings in which:

[0032] Figure 1 A block diagram illustrating an embodiment of the computer-implemented method of the present application for transforming a library from a source operating system to a target operating system is shown.

[0033] Figure 2 A block diagram illustrating an embodiment comprising instrumental components for the proposed solution is shown.

[0034] Figure 3 A diagram visualizing a workflow for transforming, e.g., a library between two given exemplary platforms is shown.

[0035] Figure 4 A diagram with a binary stream is shown, which further comprises a called function.

[0036] Figure 5 A compiler linker pipeline used by the method presented herein is shown.

[0037] Figure 6 A block diagram illustrating an embodiment of the transformation system of the present application for transforming a library from a source operating system to a target operating system is shown.

[0038] Figure 7 A computing system comprising a system according to Figure 6 is shown. DETAILED DESCRIPTION

[0039] In the context of the present specification, the following technical conventions, terms and / or expressions can be used:

[0040] The term "source operating system" can denote an operating system having a first application binary interface (ABI) operating on a predefined hardware architecture. The source operating system can typically be used as a program development environment. Exemplarily, it can be a Linux-type system operating on a z-architecture hardware platform.

[0041] The term "target operating system" can denote a second operating system having a second ABI incompatible with the first ABI. Thus, the feature sets of these ABIs can significantly differ such that even a translation is not possible because the same relocation types can not exist on both operating systems.

[0042] It can also be considered that the source and target operating systems can be two different virtual machines running on the same hardware, e.g. sharing the same process on the same memory of a computer system. Naturally, the computer system can be a hybrid implementation of the two described scenarios, e.g. the source and target operating systems are two virtual machines running as two different processes or loads on one processor, but sharing one instance of memory on a given computer system.

[0043] The term "application binary interface" (ABI) can denote a set of operating system functions that can be used and called by an application. A platform ABI can define the layout and metadata of a binary object format that can be used by additional applications or operating system services. These binary objects can include, among other data, sections and segments that further include executable machine code, binary data and constants, symbol information, relocation information, etc. Thus, the machine code as well as the binary data and constants can be considered as the payload of the objects. The relocation information, symbols, segments and segment definitions can be part of the metadata required to load the payload into memory for execution or further transformations and uses of these objects. The machine code, binary data and constants can directly depend on the processor architecture of the computer system and can be only loosely coupled to the used operating system through the calling conventions defined in the ABI.

[0044] The term "source object file" can denote a compiled source code that has not been linked to executable code using operating system libraries.

[0045] The term "target memory image" can also be denoted as transformed binary image, which can be executable code compatible with the target operating system. In contrast, a "source memory image" can denote a memory image that is available and executable in the deployment environment, i.e. a memory image that can be used by the source operating system.

[0046] The term "enriching the target memory image" can denote here the addition of information to object files that are not part of the source memory image. The supporting compiler can add some space that can be denoted as "hot patch area", which can then be overwritten during the transformation process by the transformer or the source linker. The enrichment can then be a pointer in front of the function binary code. The pointer can point to a string table entry that includes the full name of the (original) function that the code has been included in a shared object (compare Figure 5 ).

[0047] The term "source symbol" can denote a location within a source memory image, typically at the beginning of the binary code of a function, a shared data area or some other location defined by the linker. The term "source symbol name" can here denote the name of the source symbol, typically the name of a function, a data area or some other location.

[0048] The term "relocation" can be a feature of object files that enables the assignment of a load address to a specific part of the object code. As used herein, an absolute relocation can define a load address within a specific virtual address space defined for the object. On the other hand, a relative relocation can here be understood as a load address definition relative to a given reference address within the virtual address space. As there can be (target) operating systems whose ABI does not support relative relocations, it can be a prerequisite for successful execution of the transformation to provide source object files without relative relocation information. Thereby, a relocation record can be used to denote an instruction to the linker to replace a placeholder within the machine code of the binary data with a relocation value that becomes known only at link time. The relocation value can be related to the address of a symbol, whereby relocations can be divided into two main groups: absolute relocations that can involve the address of the symbol, and relative relocations that can involve the distance between the address of the symbol and the placeholder address.

[0049] The term "library" can here be used to denote any object file or binary object that has been compiled so that a GOT (Global Offset Table) and a PLT (Procedure Linkage Table) are created. This can be done when compiling a shared library in the narrow sense, e.g. at load time or run time creating an object that is intended to provide additional functionality to an executable or other shared object file. The present definition of a shared library can thus include both strictly shared library objects and other objects that have been compiled from source code that originally can have been intended to generate a different type of object (e.g. an executable object), however, the object has been compiled in a similar way as would normally be the case when compiling a strict shared library. A library created in this way can be without relative relocations. A shared library (or generally a library or any other binary object) can be the target of a transformation that the concepts presented herein can be beneficial for, i.e. also preserving and making available the original function names of the source shared library in the target memory image (or target executable code).

[0050] The term "executable object" can mean an object intended to be executed by a processor using an operating system. They can be built from one or more relocatable objects with the help of a linker. Depending on the linker, they can include all symbols or only the undefined symbols necessary to find functions in shared libraries. Since executable objects can have a fixed location in memory, they can include both relative and absolute relocations (if the target operating system supports it). Furthermore, typical binary objects can exist in three main groups: relocatable objects, executable objects, and shared libraries.

[0051] Before proceeding with the detailed description of the drawings, some related system environment characteristics will be described. As already mentioned, software development can be performed on a modern computing environment that allows shared libraries; however, the final deployment can be done on another computing environment that is not compatible with the software development environment. Thus, the source operating system is incompatible with the target operating system and the source ABI (application binary interface) is incompatible with the target ABI. While there already exist general solutions for such a situation, traditional software development practices also require the ability of traditional, e.g., dump debugging and automatic name discovery during tracing at the time of debugging.

[0052] Now, tracing and using memory dump reading tools can require access to the full function name in order to be useful. If the function name has been scrambled or hashed during the transformation, the trace cannot be used effectively, i.e., the transformed function name is not meaningful to the developer. This can have been done during the transformation because the number of bits / bytes available for the function name in the source operating system environment is limited. Thus, for example, _func_ and other solutions are not accessible outside the source code (e.g., C source code) itself. Thus, they cannot be used for dump or trace analysis in the target memory image.

[0053] The detailed description of the drawings will be given below. All instructions in the figures are schematic. First, a block diagram of an embodiment of the computer-implemented method of the present invention for transforming a library from a source operating system to a target operating system is given. Then, other embodiments as well as embodiments of a transformation system for transforming a library from a source operating system to a target operating system will be described.

[0054] Figure 1 A block diagram of a preferred embodiment of a computer-implemented method 100 for transforming a library from a source operating system to a target operating system is shown. The typical case can be transforming a shared library in a Linux-type operating system to a static library in a z / VM operating system.

[0055] The following preconditions can be assumed, the source operating system (e.g. Linux) includes a source application binary interface that will be executable on a predetermined instruction set architecture (e.g. z Architecture). The target operating system (e.g. z / OS or z / VM) includes a target application binary interface and can also be executable on the same predetermined instruction set architecture. The target application binary interface shall be different from the source application binary interface; the library is implemented by source object files; the source object files conform to the source application binary interface and it includes at least the source memory image, the source symbol information and the source relocation information.

[0056] Under these assumptions, the method 100 includes creating 102 a target memory image. Thereby, the target memory image conforms to the target application binary interface and the target memory is derived from the source memory image, i.e. the target memory includes memory image data originating from the source memory image.

[0057] The method 100 further includes enriching 104 the target memory image with address information pointing to the variable length information derived from the source symbol names for each external source symbol that is part of the target memory image. Last but not least, the method 100 includes writing 106 the target memory image into a target object file to implement the transformed shared library by the target object file.

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

[0059] Relocation can be a feature of object files that enables the assignment of a load address to a particular portion of object code. As used herein, an absolute relocation can define a load address within a particular virtual address space defined for an object. On the other hand, a relative relocation can be understood here as a definition of a load address relative to a given reference address within the virtual address space. Because there can be a (target) operating system whose ABI does not support relative relocations, providing a source object file without relative relocation information can be a prerequisite for a successful execution of the transformation.

[0060] At the bottom of the diagram, a target operating system 214 with its target application binary interface 216 is shown. Transformation 220 facilitates the creation of a target memory image that includes pointers to variable-length information 224 pointing to each external (source) symbol used by the target memory image 222. Thus, the transformation creates, enriches, and writes the target memory image to the target object file. The pointers help overcome the limitation of a target operating system that can only handle fixed-length function names (i.e., external symbols).

[0061] Figure 3 A diagram visualizing workflow 300 for transforming a shared library between two given exemplary platforms (i.e., from a development environment to a deployment environment) is provided. During compilation step 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, such as library code. Regardless of whether the software is intended to be deployed as an executable object, a library, or any other target format usable on the target system, the compiler is configured to treat the source code as a shared library, thereby generating one or more binary objects as well as a GOT (Global Offset Table) and a PLT (Procedure Linking Table). The overall source code remains unchanged, and other compiler options are set as usual to reflect the details of the architecture, linking steps, and / or other desired characteristics of the resulting object file. To prepare and / or configure the merge step, additional compiler options and / or linking step characteristics required to create the shared library can be set, if necessary.

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

[0063] During the merging step 306, segments of the memory image of the absolute master object file are merged into a contiguous memory image. This can be done by the linker by passing a linker script to the linker, or alternatively, the merging function of the transformation utility can be used to convert the segmented memory image into a contiguous memory image. The merging step can be performed during linking or after the absolute master object file has been generated.

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

[0065] During the transform step 308, the relocations and symbols included in the absolute host object file are transformed to meet the specifications of the target ABI. This can include mapping the types, names, symbols, and / or address spaces of the source information to the required relocation types, naming conventions, and / or address spaces of the target ABI (application binary interface). In some cases, appropriate features of the target ABI can be selected to avoid or minimize the conversion effort.

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

[0067] Figure 4 A diagram 400 is shown with a binary code stream 402 that also includes an example function binary call 406 (e.g., a subroutine). Since there is a limited number of bytes for function call identifiers or names in the target operating system, the identifiers can have been obfuscated or hashed so that they are no longer human-understandable in an easy fashion. However, prior to each symbol or integrated function binary 406, a number of additional available bytes are reserved for an absolute relocation pointer 404, e.g., eight bytes (or any other sufficient number of bytes). The pointer at 404 (just prior to the target symbol address) points to an absolute address in the target memory image (outside of the core executable code), e.g., to the start address of a string table that stores the full original function name 410 of the source code. In this way, the tracing and debugging tools of the deployment environment can access the plaintext or full function name 410.

[0068] Figure 5 A compiler / linker pipeline that can be used by the methods presented herein is shown. It starts with source code 502 that is input to a source compiler 504 in the source / development environment. The source compiler 504 outputs object code 506. One or more object code elements 506 are linked by a source linker 508 to produce a shared object 510. Optionally, as presented herein, this undergoes transformation by a transformer 512. Alternatively, the transformation can also be performed by an extended source linker 508. The output of the transformer 512 (or extended source linker) is then directed to a target linker 516 that uses the transformed objects 514 as input to produce a target executable. This target executable can then be loaded into a target system under a target operating system.

[0069] Figure 6A block diagram of an embodiment of a transformation system 600 for transforming a library from a source operating system to a target operating system is shown. Here, the already mentioned assumptions can be repeated: the source operating system (e.g. Linux) comprises a source application binary interface, which is executable on a predetermined instruction set architecture (e.g. z Architecture). The target operating system (e.g. z / OS or z / VM) comprises a target application binary interface and can also be executable on the same predetermined instruction set architecture. The target application binary interface shall be 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 it comprises at least a source memory image, a source symbol information and a source relocation information.

[0070] The system 600 comprises at least one or more processors 602 and a memory 604 operatively coupled to the one or more processors 602, wherein the memory 604 stores program code portions which, when executed by the one or more processors 602, enable the one or more processors 602 to create (in particular by a creation module 606) a target memory image, wherein the target memory image conforms to a target application binary interface and wherein the target memory is derived from a source memory image.

[0071] In addition, the one or more processors 602 are further enabled (in particular by a enrichment unit 608) to enrich the target memory image with address information pointing to variable length information derived from the source symbol name for each external source symbol and (in particular using a writer module 610) to write the target memory image into a target object file to implement the transformed shared library by the target object file.

[0072] It should also be mentioned that all functional units, modules and functional blocks (one or more processors 602, memory 604, creation module 606, enrichment unit 608 and writer module 610) can be communicatively coupled to each other in a selected 1 : 1 manner for signal or message exchange. Alternatively, the functional units, modules and functional blocks can be linked to a system internal bus system 618 for selective signal or message exchange.

[0073] Various aspects of the application are described by way of illustration in the specification, figures of flows, block diagrams of computer systems and / or block diagrams of machine logic included in computer program product (CPP) embodiments. For any flow diagram, the order of the operations can be different than that which is depicted; based on the involved technology. For example, two operations shown as consecutive in a continuous flow diagram block can also be executed in reverse order, as a single integrated step, at the same time, or in at least partially overlapping manner, again based on the involved technology.

[0074] A computer program product embodiment (CPP embodiment or CPP) is a term of art used in this disclosure to describe any collection of one or more storage media (also referred to as media) that collectively include machine-readable code corresponding to instructions and / or data used to perform the computer operations specified in a given CPP claim. A storage device is any tangible device that can retain and store instructions for use by a computer processor. A computer-readable storage medium can be an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these media are: a floppy disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a compact disk read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device such as punch cards or pits / islands formed in the main surface of a disk, or any suitable combination of the foregoing. As a term of art used in this disclosure, a computer-readable storage medium is not to be interpreted as storage of the signals per se in transition forms such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagated through waveguides, light pulses through optical cables, electric signals through wires, and / or other transmission media. As understood by those skilled in the art, data is typically moved at certain occasional points in time during normal operation of a storage device, such as during access, defragmentation, or garbage collection, but this does not make the storage device transitory, as the data is not transitory while stored.

[0075] Figure 7 A computing environment 700 is shown, including an example of an environment for executing at least some of the computer code 750 involved in performing a method of the present invention, such as a computer-implemented method for transforming a library from a source operating system to a target operating system.

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

[0077] Computer 701 can take the form of a desktop computer, a laptop computer, a tablet computer, a smart phone, a smart watch or other wearable computer, a mainframe computer, a quantum computer, or any other form of computer or mobile device now known or developed in the future that is capable of running a program, accessing a network, or querying a database, such as remote database 730. As is understood in the computer arts, execution of a computer-implemented method can be distributed among multiple computers and / or among multiple locations in accordance with the technology. On the other hand, in this presentation of computing environment 700, the discussion is focused on a single computer, specifically computer 701, in order to keep the presentation as simple as possible. Computer 701 can be located in the cloud, although Figure 7 it is not shown in the cloud in this embodiment. On the other hand, computer 701 need not be in the cloud, unless it can be affirmatively stated at any level.

[0078] Processor complex 710 includes one or more computer processors of any type now known or developed in the future. Processing circuitry 720 can be distributed across multiple packages, such as multiple coordinated integrated circuit chips. Processing circuitry 720 can implement multiple processor threads and / or multiple processor cores. Cache 721 is memory located in the processor chip package that is typically used for data or code that threads or cores running on processor complex 710 should have fast access to. Cache memory is typically organized into multiple levels according to relative proximity to the processing circuitry. Alternatively, some or all of the cache of processor complex can be located "off-chip." In some computing environments, processor complex 710 can be designed to use qubits and perform quantum computing.

[0079] Computer readable program instructions generally be loaded onto the computer 701 to cause the processor group 710 of the computer 701 to execute a series of operational steps to implement a computer implemented method, such that the instructions so executed will instantiate the method specified in the flowchart and / or the description of the computer implemented method contained in this document (collectively referred to as "the method 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 elements discussed below. The program instructions and related data are accessed by the processor group 710 to control and direct the method of the invention. In the computing environment 700, at least some of the instructions for performing the method of the invention can be stored in the block 750 in the persistent storage 713.

[0080] The communication fabric 711 is a signal carrying path that allows the various components of the computer 701 to communicate with one another. Generally, this fabric is comprised of switches and conductive paths, such as those that make up a bus, bridges, physical input / output ports, and the like. Other types of signal communication paths can be used, such as fiber optic communication paths and / or wireless communication paths.

[0081] The volatile memory 712 is any type of volatile memory presently known or developed hereafter. Examples include dynamic types of random access memory (RAM) or static types of RAM. Generally, volatile memory is characterized by random access, but this is not required unless explicitly indicated. In the computer 701, the volatile memory 712 is located in a single package and is internal to the computer 701, however, alternatively or additionally, the volatile memory can be distributed over multiple packages and / or located external to the computer 701.

[0082] The persistent storage 713 is any form of non-volatile storage of a computer presently known or hereafter developed. The non-volatile nature of this storage means that the stored data will be retained regardless of whether power is supplied to the computer 701 and / or directly to the persistent storage 713. The persistent storage 713 can be read only memory (ROM), but generally at least a portion of the persistent storage allows for writing of data, deletion of data, and re-writing of data. Some common forms of persistent storage include magnetic disks and solid state storage devices. The operating system 722 can take a variety of forms, such as various known proprietary operating systems or open source portable operating system interface type operating systems employing a kernel. The code included in the block 750 generally includes at least some computer code involved in performing the method of the invention.

[0083] The peripheral device group 714 includes peripheral devices of the computer 701. Data communication connections between the peripheral devices and other components of the computer 701 can be achieved using various means, such as Bluetooth connections, Near Field Communication (NFC) connections, cable connections (e.g., Universal Serial Bus (USB) type cables), plug-in connections (e.g., Secure Digital (SD) cards), connections through local area communication networks, or even connections through wide area networks such as the Internet. In various embodiments, the UI device group 723 can include components such as display screens, speakers, microphones, wearable devices (e.g., eyewear and smartwatches), keyboards, mice, printers, touchpads, game controllers, and haptic devices. The storage device 724 is an external storage device (e.g., an external hard drive) or a pluggable memory (e.g., an SD card). The storage device 724 can be persistent and / or volatile. In some embodiments, the storage device 724 can take the form of a quantum computing storage device for storing data in the form of qubits. In embodiments where the computer 701 needs to have a large amount of storage (e.g., where the computer 701 locally stores and manages a large database), the storage device can be provided by a peripheral storage device designed for storing very large amounts of data, such as a Storage Area Network (SAN) shared by multiple geographically dispersed computers. The IoT sensor group 725 includes sensors that can be used in Internet of Things applications. For example, one sensor can be a thermometer, and another sensor can be a motion detector.

[0084] The network module 715 is a collection of computer software, hardware, and firmware that allows the computer 701 to communicate with other computers through the WAN 702. The network module 715 can include hardware such as a modem or Wi-Fi signal transceiver, software for packetizing and / or depacketizing data for transmission over a communication network, and / or web browser software for transmitting data over the Internet. In some embodiments, the network control functions and network forwarding functions of the network module 715 are performed on the same physical hardware device. In other embodiments (e.g., embodiments that utilize Software Defined Networking (SDN)), the control functions and forwarding functions of the network module 715 are performed on physically separate devices, such that the control functions manage multiple different network hardware devices. Computer readable program instructions for implementing the methods of the present application can generally be downloaded to the computer 701 from an external computer or external storage device through the network module 715, which can include a network adapter card or a network interface in the network module 715.

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

[0086] End user device (EUD) 703 is any computer system used and controlled by an end user (e.g., a customer of the business operating computer 701) and can take any form discussed above in connection with computer 701. EUD 703 typically receives helpful and useful data from the operation of computer 701. For example, in the hypothetical case where computer 701 is designed to provide recommendations to an end user, that recommendation would typically be transmitted from network module 715 of computer 701 to EUD 703 through WAN 702. In this way, EUD 703 can display or otherwise present the recommendation to the end user. In some embodiments, EUD 703 can be a client device such as a thin client, a thick client, a mainframe, a desktop, etc.

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

[0088] The public cloud 705 is any computer system that is available for use by multiple entities, providing on-demand availability of computer system resources and / or other computer capabilities, especially data storage (cloud storage) and computing power, without direct active management by the user. Cloud computing often utilizes resource sharing to achieve consistency and economies of scale. Direct active management of the public cloud 705 computing resources is performed by computer hardware and / or software of the cloud orchestration module 741. The computing resources provided by the public cloud 705 are typically implemented by virtual computing environments running on various computers that make up the host physical machine group 742, which are various physical computers in and / or available to the public cloud 705. The virtual computing environments (VCEs) typically take the form of virtual machines from the virtual machine group 743 and / or containers from the container group 744. It will be appreciated that these VCEs can be stored as images and can be transferred as images or after VCE instantiation between various physical machine hosts. The cloud orchestration module 741 manages the transfer and storage of images, deploys new instances of VCEs, and manages the active instances of VCE deployments. The gateway 740 is a collection of computer software, hardware, and firmware that allows the public cloud 705 to communicate over the WAN 702.

[0089] Some further explanation of virtualized computing environments (VCEs) will now be provided. VCEs can be stored as “images.” New active instances of VCEs can be instantiated from images. Two familiar types of VCEs are virtual machines and containers. Containers are VCEs that use operating system-level virtualization. This refers to an operating system feature in which the kernel allows multiple isolated user space instances (called containers) to exist. From the perspective of a program running in one, these isolated user space instances often appear as a real computer. Computer programs running on an ordinary operating system can utilize all of the resources of that computer, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, programs running within a container can only use the contents of that container and the devices allocated to that container, a feature known as containerization.

[0090] The private cloud 706 is similar to the public cloud 705 except that the computing resources are for the use of only a single enterprise. While the private cloud 706 is depicted as being in communication with the WAN 702, in other embodiments, the private cloud can be completely disconnected from the Internet and only accessible through 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 separately by different vendors. Each of the multiple clouds remains an independent discrete entity, but the larger hybrid cloud architecture is bound together through standardization or proprietary technology, supporting orchestration, management, and / or data / application portability between the multiple constituent clouds. In this embodiment, both the public cloud 705 and the private cloud 706 are part of a larger hybrid cloud.

[0091] It should also be mentioned that the transformation system 600 (compare Figure 6 ) for transforming a library from a source operating system to a target operating system can be an operating subsystem of the computer 701 and can be attached to the computer internal bus system.

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

[0093] All means or steps plus function elements in the following claims are meant to cover the corresponding structural, material, acts and equivalents thereof covered by the embodiments described hereinafter. The description of the application has been presented for purposes of illustration and description, but is not intended to be exhaustive or to limit the application to the precise form disclosed. Many modifications and variations will be apparent to those skilled in the art. Embodiments were chosen and described in order to best explain the principles of the application and its practical application, and to thereby enable others skilled in the art to best utilize the application in various embodiments with various modifications as are suited to the particular use contemplated.

[0094] In short, the inventive concept can be summarized by the following clauses:

[0095] 1. A computer-implemented method for transforming a library from a source operating system to a target operating system,

[0096] - the source operating system comprising a source application binary interface,

[0097] - the target operating system comprising a target application binary interface,

[0098] - the target application binary interface being different from the source application binary interface,

[0099] - the library being implemented by a source object file,

[0100] - the source object file conforming to the source application binary interface and comprising at least a source memory image, source symbol information and source relocation information,

[0101] the method comprising:

[0102] - creating a target memory image, wherein the target memory image conforms to the target application binary interface, and wherein the target memory is derived from the source memory image,

[0103] - enriching the target memory image with address information pointing to variable length information derived from a source symbol name for each external source symbol, and

[0104] - writing the target memory image into the target object file to enable a transformed shared library by the target object file.

[0105] 2. The method according to clause 1, wherein the source relocation information is without relative relocation information.

[0106] 3. The method according to clause 1 or 2, wherein enriching the target memory image is performed by placing address information at a target memory image location at a fixed offset from a target symbol address.

[0107] 4. The method according to clause 3, wherein the address information comprises a relative offset representing a distance between the address information within the target memory image and an address of a corresponding variable length information within the target memory image.

[0108] 5. The method according to clause 3 or 4, wherein the address information comprises an absolute address.

[0109] 6. The method according to any one of clauses 3 to 5, further comprising:

[0110] - adding reserved memory for a subsequent enrichment of the target memory image by reserving space in the source memory image at a fixed offset from a source symbol address.

[0111] 7. The method according to clause 5, wherein enriching the target memory image is performed by instructing a linker system to place an absolute address of the variable length information at the target memory image location at a fixed offset from the target symbol address.

[0112] 8. The method according to clause 7, wherein instructing the linker is based on an instruction stored as relocation information in the target object file.

[0113] 9. The method according to any one of clauses 1 to 8, wherein enriching the target memory image further comprises:

[0114] - determining that the target memory image location has been created by a supporting compiler.

[0115] 10. The method of clause 9, wherein the determining is performed by verifying that the target memory image location comprises only a particular sequence of assembly instructions.

[0116] 11. A transformation system for transforming a library from a source operating system to a target operating system,

[0117] - the source operating system comprising a source application binary interface,

[0118] - the target operating system comprising a target application binary interface,

[0119] - the target application binary interface being different from the source application binary interface,

[0120] - the library being implemented by a source object file,

[0121] - the source object file conforming to the source application binary interface and comprising at least a source memory image, source symbol information, and source relocation information,

[0122] the system comprising:

[0123] - one or more processors and a memory operatively coupled to the one or more processors, wherein the memory stores program code portions which, when executed by the one or more processors, enable the one or more processors to:

[0124] - create a target memory image, wherein the target memory image conforms to the target application binary interface, and wherein the target memory is derived from the source memory image,

[0125] - enrich the target memory image with address information pointing to variable length information derived from a source symbol name for each external source symbol, and

[0126] - write the target memory image into the target object file to implement a transformed shared library by the target object file.

[0127] 12. The system of clause 11, wherein the source relocation information is devoid of relative relocation information.

[0128] 13. The system of clause 11 or 12, wherein the one or more processors are further enabled to:

[0129] - perform the enrichment of the target memory image by placing the address information at a target memory image location at a fixed offset from a target symbol address.

[0130] 14. The system of clause 13, wherein the address information comprises a relative offset representing a distance between the address information within the target memory image and an address of corresponding variable length information within the target memory image.

[0131] 15. The system of clause 13 or 14, wherein the address information comprises an absolute address.

[0132] 16. The system of any of clauses 13 to 15, wherein the one or more processors are further caused to:

[0133] - add reserved memory for a subsequent enrichment of the target memory image by reserving space in the source memory image at a fixed offset from a source symbol address.

[0134] 17. The system of clause 16, wherein the one or more processors are further caused to:

[0135] - perform enrichment of the target memory image by instructing a linker system to place an absolute address of the variable length information at the target memory image location at a fixed offset from the target symbol address.

[0136] 18. The system of clause 17, wherein instructing the linker is based on an instruction stored as relocation information in the target object file.

[0137] 19. The system of any of clauses 11 to 18, wherein the one or more processors are further caused to, during enrichment of the target memory image:

[0138] - determine that the target memory image location has been created by a supporting compiler.

[0139] 20. A computer program product for transforming a library from a source operating system to a target operating system,

[0140] - the source operating system comprising a source application binary interface,

[0141] - the target operating system comprising a target application binary interface,

[0142] - the target application binary interface being different from the source application binary interface,

[0143] - the library being implemented by a source object file,

[0144] - the source object file conforming to the source application binary interface and comprising at least a source memory image, source symbol information, and source relocation information,

[0145] The computer program product comprises a computer readable storage medium having program instructions executable by one or more computing systems or controllers to cause the one or more computing systems to:

[0146] - create a target memory image, wherein the target memory image conforms to the target application binary interface, and wherein the target memory is derived from the source memory image,

[0147] - enrich the target memory image with address information pointing to variable length information derived from a source symbol name for each external source symbol, and

[0148] - write the target memory image into the target object file to implement the transformed library by the target object file.

Claims

1. A computer-implemented method for transforming a library from a source operating system to a target operating system. - The source operating system includes the source application binary interface. - The target operating system includes the target application binary interface. - The target application binary interface is different from the source application binary interface. - The library is implemented using source object files. - The source object file conforms to the source application binary interface and includes at least the source memory image, source symbol information, and source relocation information. The method includes: - Create a target memory image, wherein the target memory image conforms to the target application binary interface, and wherein the target memory is derived from the source memory image. - Enrich the target memory image with address information pointing to variable-length information derived from the source symbol name for each external source symbol, and - Write the target memory image to the target object file to implement the transformed shared library by the target object file.

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

3. The method according to claim 1 or 2, wherein, Enriching the target memory image is performed by placing address information at a target memory image location that is at a fixed offset from the target symbol address.

4. The method according to claim 3, wherein, The address information includes a relative offset, which represents 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 absolute addresses.

6. The method according to any one of claims 3 to 5, further comprising: - By reserving space in the source memory image at a fixed offset from the source symbol address, additional rich reserved memory is added for the subsequent target memory image.

7. The method according to claim 5, wherein, Enriching the target memory image is performed by instructing the linker system to place the absolute address of the variable-length information at a location in the target memory image that is at a fixed offset from the target symbol address.

8. The method according to claim 7, wherein, The linker is instructed based on relocation information stored in the target object file.

9. The method according to any one of claims 1 to 8, wherein, Enriching the target memory image further includes: - It is determined that the target memory image location has been created by the supporting compiler.

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

11. A transformation system for transforming a library from a source operating system to a target operating system. - The source operating system includes the source application binary interface. - The target operating system includes the target application binary interface. - The target application binary interface is different from the source application binary interface. - The library is implemented using source object files. - The source object file conforms to the source application binary interface and includes at least the source memory image, source symbol information, and source relocation information. The system includes: - One or more processors and a memory operatively coupled to the one or more processors, wherein the memory stores a portion of program code that, when executed by the one or more processors, enables the one or more processors to: - Create a target memory image, wherein the target memory image conforms to the target application binary interface, and wherein the target memory is derived from the source memory image. - Enrich the target memory image with address information pointing to variable-length information derived from the source symbol name for each external source symbol, and - Write the target memory image to the target object file to implement the transformed shared library by the target object file.

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

13. The system according to claim 11 or 12, wherein, The one or more processors are also enabled to: - Enrichment of the target memory image is performed by placing the address information at a target memory image location that is at a fixed offset from the target symbol address.

14. The system according to claim 13, wherein, The address information includes a relative offset, which represents 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 absolute addresses.

16. The system according to any one of claims 13 to 15, wherein, The one or more processors are also enabled to: - By reserving space in the source memory image at a fixed offset from the source symbol address, additional rich reserved memory is added for the subsequent target memory image.

17. The system according to claim 16, wherein, The one or more processors are also enabled to: - Enrichment of the target memory image is performed by instructing the linker system to place the absolute address of the variable-length information at a target memory image location that is at a fixed offset from the target symbol address.

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

19. The system according to any one of claims 11 to 18, wherein, The one or more processors are also enabled during the enrichment of the target memory image: - It is determined that the target memory image location has been created by the supporting compiler.

20. A computer program product for transforming a library from a source operating system to a target operating system. - The source operating system includes the source application binary interface. - The target operating system includes the target application binary interface. - The target application binary interface is different from the source application binary interface. - The library is implemented using source object files. - The source object file conforms to the source application binary interface and includes at least the source memory image, source symbol information, and source relocation information. The computer program product includes a computer-readable storage medium having program instructions that can be executed by one or more computing systems or controllers to cause the one or more computing systems to: - Create the target memory image, where, The target memory image conforms to the target application binary interface, and the target memory is derived from the source memory image. - Enrich the target memory image with address information pointing to variable-length information derived from the source symbol name for each external source symbol, and - Write the target memory image to the target object file to implement the transformed library by the target object file.

Images