Injecting eye-catching elements into library conversion
The method enhances target memory images with eye catcher information to facilitate cross-platform development from modern to legacy systems, enabling effective analysis and debugging on legacy systems without extensive updates, thus reducing costs and resource requirements.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- INTERNATIONAL BUSINESS MACHINE CORPORATION
- Filing Date
- 2024-06-12
- Publication Date
- 2026-07-07
AI Technical Summary
Existing technologies lack sophisticated cross-system development solutions for converting libraries from modern development environments to legacy systems like z/VM, particularly lacking support for visually recognizable function names and memory dump analysis tools, and require significant investment in updating legacy systems to support modern software development environments.
A method and system that adds fixed-length eye catcher information derived from source symbol names to the target memory image, allowing developers to analyze and debug software on legacy systems using familiar hooks, even if these hooks are not available in the deployment environment, by enhancing the target memory image with this information during the conversion process.
Enables developers to analyze and debug software on legacy systems using modern development environments without needing a full understanding of the target legacy system model, reducing the need for significant investment in updating legacy systems and facilitating efficient cross-platform development.
Smart Images

Figure 2026522171000001_ABST
Abstract
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 a library from a source operating system to a target operating system. The present invention further relates to a related conversion system and a related computer program product.
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 portion of the available IT budget must be used for 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, modern C compiler support has not been available since z / OS 1.13 became 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 regarding computer implementations for converting libraries from a source operating system to a target operating system. For example, U.S. Patents.
[0005] U.S. 2020 / 0 334 129 discloses a method for selectively tracing portions of the execution of a computer process. This results in some extra tracing beyond the code that the developer wishes to trace, but significantly reduces the computational cost by decreasing the number of trace enable and disable operations.
[0006] Additionally, U.S. Patent 10 592 220 B2 discloses a metadata-driven method for linking converted source code to the original source code. The relevant method may be used to convert computer program source code from a first high-level language to a second high-level language that is functionally equivalent to the first high-level language.
[0007] However, none of the available technologies offer sophisticated cross-system development solutions, particularly those targeting or deploying systems like z / VM, and none support visually recognizable function names, especially when using memory dump analysis tools. [Overview of the project]
[0008] 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. The source operating system may include a source application binary interface (ABI), the target operating system may include a target application binary interface, the target application binary interface may be different from the source application binary interface, the library may be 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, the source relocation information may not include relative relocation information.
[0009] 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 image is enhanced using fixed-length eye catcher 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 target library is implemented by the target object file.
[0010] According to another 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 may be 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 may include at least a source memory image, source symbol information, and source relocation information, the source relocation information not including relative relocation information.
[0011] The conversion system may comprise one or more processors and memory operablely coupled to the one or more processors, wherein the memory may store portions of program code that, when executed by the one or more processors, create a target memory image, wherein the target memory image conforms to the target application binary interface, the target memory image is enhanced using fixed-length eye catcher information derived from source symbol names for each external source symbol derived from the source memory image, and the target memory image is written to the target object file so that the target library is implemented by the target object file.
[0012] 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.
[0013] The concept proposed here can address the challenges of cross-platform development, i.e., when a modern software development environment may be used for developing new software, but the deployment environment may rather be a legacy system type like z / VM. Unfortunately, gcc and other Linux-based compilers like clang do not support an automatic eye catcher as part of the entry point prologue. Additionally, they do not support features equivalent to XLC PROLOG and EPILOG.
[0014] Therefore, the proposed concept uses an additional memory space before or inside the entry point (i.e., the starting address of the binary function code). This additional memory space may be added by a slightly adapted compiler, i.e., the source-side, i.e., development-side compiler. These additional memory space regions are sometimes referred to as hot-patch regions. Additional information, such as eye-catcher information, can be added here, thus making it much easier for developers to analyze, for example, traces and core dumps of the deployment-side system.
[0015] As a result, especially when the development system is a Linux-type development environment and the deployment environment is rather legacy-type, developers can find familiar hooks to analyze and debug the software they have developed, even if these hooks are not available in publicly known solutions. Other solutions can also generate such hooks, but this document explains how it is possible to add these hooks after the compilation or assembly process. The hooks can be added by the transformation process, which also means that a standard compiler can be used.
[0016] This can reduce the need for significant investment in updating and improving target deployment systems to support modern software development environments. This can be particularly beneficial for newly hired development staff, as they do not need a full understanding of the target legacy system model to develop software libraries using a familiar, up-to-date development environment on a modern computing system. Specifically, modern software development environments 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, available resources, specifically more conventional, highly reliable computing environments and architectures, can be used without having to reinvent all the tools available within the modern software development environment for legacy systems. This can help save time, money, and power, and thus help protect the environment.
[0017] The use of the proposed technology may also have additional advantages in terms of (self)discovery and tracing or memory dumping of possible function names in the deployed computing environment.
[0018] The following describes additional embodiments of the present invention that are applicable to methods and systems.
[0019] According to an advantageous embodiment of the method, the step of enhancing the target memory image may be carried out by placing the eye catcher information at a target memory image location in the target memory image, at a fixed offset from the target symbol address. This could be, for example, the 8 bytes preceding the target symbol address. Additional space in the target memory image may also have gone through the linking process and may have been created by the source compiler, if any relevant option flags have been set.
[0020] According to a preferred embodiment of the method, the eye catcher information may include debug information. Debug information can take various different options and types of forms that will be used for (core) dump analysis. Developers of legacy systems are familiar with this additional debug data in core dumps (and traces) for effective analysis in the event of system failure. However, as other types of debugging options have become available over time, and thus the need for such core dump analysis has decreased, this information in memory dumps is no longer available in modern development environments with current technological capabilities.
[0021] According to an improved embodiment of the method, a step of checking that the target memory image location was created by a supporting compiler may precede the step of enhancing the target memory image. This checking step may be performed by a component that adds eye catcher information to the target memory image, namely a source linker or a specific conversion tool.
[0022] According to another advanced embodiment of the method, the checking step is performed by verifying that the target memory image location contains only predetermined assembly instruction sequences. These may be NOP (no operation) instructions, all-zero, all-one, or any predetermined bit code that can be clearly identified.
[0023] According to another interesting embodiment, the method may also include a step of determining whether the target memory image location is available for the enhancement. These can ensure that unoccupied target memory image data may be corrupted. If one of the preceding systems (e.g., compiler, source linker, translation system, etc.) has not made additional space available, the original code or data may be overwritten.
[0024] According to a useful embodiment of the method, the conversion may also include character conversion between different character sets, specifically, conversion from the ASCII character set to the EBCDIC character set for character symbols and the codes used. This may be a useful side effect that can be achieved in parallel with integrating eye catcher information into the binary code stream.
[0025] According to another advantageous embodiment of the method, the conversion may also include a step of constructing a hash value having a predetermined number of characters for the names or symbols used in the source image data. This can be useful because function names in modern development environments may not be limited to a small number of characters (e.g., only 8 characters). In this way, function or symbol names can be compressed (e.g., by hashing) and therefore they are meaningless to the average novice programmer. However, this feature may become a requirement for conversion when modern development environments or legacy deployment environments are involved.
[0026] It may also be possible to provide a mapping from long source code function or symbol names to target symbol names. This would allow for inference from the target symbol or target function name back to the original symbol or function name in the source code.
[0027] Furthermore, embodiments may take the form of a related computer program product accessible from a computer-enabled or computer-readable medium that provides program code used by or in connection with a computer or any instruction execution system. For the purposes of this description, the computer-enabled or computer-readable medium may be any device that includes means for storing, communicating, propagating, or transporting programs used by or in connection with an instruction execution system, apparatus, or device. [Brief explanation of the drawing]
[0028] Note that embodiments of the present invention are described with reference to different subjects. 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, unless otherwise stated, consider that any combination of features belonging to one type of subject, as well as any combination between features relating to different subjects, particularly between the features of method type claims and the features of apparatus type claims, is also disclosed within this document, as can be inferred from the above and the following description.
[0029] 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.
[0030] Preferred embodiments of the present invention will be described by way of example only and with reference to the following drawings:
[0031] [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.
[0032] [Figure 2] FIG. is a block diagram of an embodiment comprising means components for a proposed solution, specifically a target object file comprising a target memory image and a target symbol name.
[0033] [Figure 3] FIG. visualizes a workflow diagram for converting a library between two given exemplary platforms.
[0034] [Figure 4]This figure shows a diagram containing a binary code stream that includes the function binary code and eye catcher information.
[0035] [Figure 5] This diagram shows the compute / linker pipeline used by the method proposed here.
[0036] [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.
[0037] [Figure 7] This figure shows one embodiment of a computing system comprising the system shown in Figure 6. [Modes for carrying out the invention]
[0038] In the context of this explanation, the following technical idioms, terms, and / or expressions may be used:
[0039] The term "translating libraries from a source operating system to a target operating system" can here refer to the process of translating all executable code within a development environment to meet the requirements of the target or deployment computing environment. This may include translating different character sets, such as length limitations for symbol or function names, and reflecting architectural differences between the two involved computing platforms, namely the development platform versus the deployment platform (e.g., little-endian versus big-endian).
[0040] The term "source operating system" can refer to an operating system having a first application binary interface (ABI) that runs on a first predetermined hardware architecture. A source operating system can typically be used as a program development environment. Exemplarily, 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. Thus, 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 be directly dependent on the processor architecture of the computer system and may simply be loosely coupled to the operating system 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 using operating system libraries to become executable code.
[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 “source symbol” or “source symbol information” may refer to a location in the source memory image, often located at the beginning of the function’s binary code, in a shared data area, or somewhere else defined by the linker. The term “source symbol name” may refer here to the name of the source symbol, often the name of a function, a data area, or somewhere else.
[0047] The term "library" here may be used to refer to any object file or binary object compiled to produce a GOT (global offset table) and a PLT (procedure linkage table). This can 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 transformation, for example, to which eye-catching information is provided for the purpose of tracing and analyzing core dumps, for example, if the concepts proposed here are useful.
[0048] 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.
[0049] The term "enhancing the target memory image using fixed-length eye catcher information" may indicate that the compiler may add additional space within the object file, such as a hot patch area, which can be filled with debug information by the source linker or associated translation system.
[0050] The term "eyecatcher information" can refer to a human-readable sequence of characters within executable code, and therefore also within a core dump. Developers or debugners may recognize this eyecatcher information as a familiar sequence of characters. Eyecatcher information could be, for example, a mangled function name in source code from a development environment. Compilers may require long, predetermined function names in source code to be mangled or hashed to create compressed function names, because the deployment environment, including its linker (system), may only support function names with a maximum length of, for example, eight characters (or any other architecture-defined length).
[0051] 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. Further embodiments and embodiments of related conversion systems are then described.
[0052] Figure 1 shows a block diagram of a preferred embodiment of a computer implementation method for converting a library from a source operating system to a target operating system. The method requires the following prerequisites: the source operating system, e.g., a development environment OS, e.g., a Linux-type OS, has a source application binary interface, and the target operating system, e.g., a deployment OS (e.g., zOS), has a target application binary interface. Both OSs may operate on the same instruction set architecture or different ones. Furthermore, the target ABI differs from the source ABI, where the library is implemented by source object files. In addition, the source object files conform to the source ABI and include at least a source memory image, source symbol information, and source relocation information, where the source relocation information does not include relative relocation information. This is a useful feature because the target OS may not necessarily enable relative relocation techniques.
[0053] Method 100 comprises the steps of creating a target memory image 102, wherein the target memory image conforms to the target application binary interface, wherein the target memory image is enhanced with fixed-length eye catcher information of, for example, 8 characters derived from the source symbol name (i.e., the name of the external function) for each external source symbol derived from the source memory image, and writing the target memory image to the target object file 106, such that the target library is implemented by the target object file.
[0054] 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 and source symbol information 210; optionally, source relocation information (not shown).
[0055] 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.
[0056] The lower part of the figure shows the target operating system 212 with its target application binary interface 214. The conversion 216 is a means for creating a target memory image 218 with eye catcher information 220. Thus, the conversion creates the target memory image 218, enhances it, and writes the target memory image 218 to the target object file 222.
[0057] 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 (as long as the architecture development system and deployment system are the same), and further compiler options are set as usual to reflect architecture details, linking phases, and / or further desired characteristics of the resulting object files. Additional compiler options and / or linking phase characteristics required to create the shared library may be set, if necessary, to prepare and / or configure the merging phase.
[0058] Another interesting detail is that the compiler needs to be run with a parameter that ensures a specific, predetermined number of bytes are generated before each function entry. This can be done by specifying the following parameter, for example, gcc"-mhotpatch=4.0" to specify 8 bytes, which is the hotpatch area, before the function.
[0059] 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.
[0060] 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.
[0061] 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.
[0062] During conversion stage 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 type, name, symbol, and / or address space to the relocation type, naming convention, 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. To include eye-catcher information, the following process may be used: (i) count the number of available bytes before each function by counting the number of NOP operation codes (or any other predetermined codes) working backward from each function entry point; (ii) verify that the available space thus created is greater than or equal to the (mangled) function name; (iii) write the (mangled) function name into the binary image before the function entry.
[0063] 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.
[0064] Figure 4 shows a diagram 400 with a stream of binary code 402, which also includes an exemplary function binary code 404 (e.g., a linked 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, prior to each symbol or integrated function binary code 404, several additional available bytes, e.g., 8 bytes (or any other sufficient number of bytes), are reserved in a hotpatch region for eye catcher information 406. The hotpatch region of 406 is immediately before the target symbol address 408 and contains the eye catcher information.
[0065] Figure 5 shows a compile / linker pipeline 500 available by the method proposed herein. It begins with source code 502, which is used as input to the 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 the source linker 508 to produce a shared object 510. Optionally, this goes through a transformation by a converter 512, as proposed herein. Alternatively, the transformation may also be performed by an extended source linker 508. The output of the converter 512 (or extended source linker) is then directed to a target linker 516, which uses the transformed object 514 as input to produce a target executable file 518. This can then be loaded into the target system under the target OS.
[0066] 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 following prerequisites must be met: the source operating system has a source application binary interface, and the target operating system has a target application binary interface. Thus, the target application binary interface is different from the source application binary interface, where the library is implemented by a source object file. 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, where the source relocation information does not include relative relocation information.
[0067] In this case, the conversion system 600 comprises one or more processors 602 and a memory 604 operably coupled to one or more processors 602, wherein the memory 604 stores a portion of program code that, when executed by one or more processors 602, enables one or more processors 604 to create a target memory image, specifically a creation unit 606, wherein the target memory image conforms to a target application binary interface, and the target memory image is derived from a source memory image. One or more processors are also enabled to enhance the target memory image using fixed-length eye catcher information derived from source symbol names for each external source symbol, specifically an enhancement module 608, and to write the target memory image to a target object file, specifically a writer module 610, so that the target library is implemented by the target object file.
[0068] It should also be noted that all functional units, modules, and functional blocks, specifically one or more processors 602, memory 604, creation unit 606, enhancement module 608, and writer module 610, may be coupled to each other in a selected one-to-one manner for signaling or message exchange. Alternatively, functional units, modules, and functional blocks may be linked to the system internal bus system 612 for selective signaling or message exchange.
[0069] 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.
[0070] 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.
[0071] 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.
[0072] 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.
[0073] 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.
[0074] 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.
[0075] 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.
[0076] 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.
[0077] 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.
[0078] 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. 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.
[0079] 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.
[0080] 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.
[0081] 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.
[0082] 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.
[0083] 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.
[0084] 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.
[0085] 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.
[0086] 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.
[0087] 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.
[0088] 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.
[0089] 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.
[0090] 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, where the 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, wherein the source relocation information does not include relative relocation information. The aforementioned method, The step of creating a target memory image, wherein the target memory image conforms to the target application binary interface, and the target memory image is derived from the source memory image; The steps include enhancing the target memory image using fixed-length eye catcher information derived from the source symbol name for each external source symbol, and The step of writing the target memory image to the target object file so that the target library is implemented by the target object file. A computer implementation method comprising the following features. [Item 2] The method according to item 1, wherein the step of enhancing the target memory image is performed by placing the eye catcher information at a target memory image position of the target memory image, which is a fixed offset from the target symbol address. [Item 3] The aforementioned target symbol address is generated by the supporting compiler as described in item 2. [Item 4] The aforementioned eye catcher information includes debug information, as described in item 2 or 3. [Item 5] The method according to any one of items 2 to 4, wherein the step of checking that the target memory image location was created by a supporting compiler precedes the step of enhancing the target memory image. [Item 6] The method according to item 5, wherein the checking step is performed by confirming that the target memory image location contains only predetermined assembly instruction sequences. [Item 7] The predetermined assembly instruction sequence is a no-operation instruction, as described in item 6. [Item 8] The step of determining that the target memory image location is available for the enhancement. The method described in any of items 2 through 7, also comprising: [Item 9] The aforementioned conversion is Character conversion between different character sets A method of any of the preceding items, including the method described above. [Item 10] The aforementioned conversion is The step of constructing a hash value having a predetermined number of characters for the name used in the source image data. A method of any of the preceding items, including the method described above. [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 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, where the 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, wherein the source relocation information does not include relative 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 is derived from the source memory image. The target memory image is enhanced using fixed-length eye catcher information derived from the source symbol name for each external source symbol, and The target memory image is written to the target object file so that the target library is implemented by the target object file. A conversion system that stores the program code portion that enables this functionality. [Item 12] While enhancing the target memory image, one or more processors The system described in item 11 can also be implemented by placing the eye catcher information at a target memory image position of the target memory image, which is a fixed offset from the target symbol address. [Item 13] The aforementioned target symbol address is generated by the supporting compiler, as described in item 12 of the system. [Item 14] The aforementioned eye catcher information includes debug information, as described in item 12 or 13 of the system. [Item 15] The system according to any one of items 12 to 14, wherein, before enhancing the target memory image, it is checked that the target memory image location was created by a supporting compiler. [Item 16] The system described in item 15, wherein the check is performed by confirming that the one or more processors contain only predetermined assembly instruction sequences for the target memory image location. [Item 17] The predetermined assembly instruction sequence is a no-operation instruction, as described in item 16 of the system. [Item 18] The aforementioned one or more processors The system according to any one of items 12 to 17, which also enables determining whether the target memory image location is available for the enhancement. [Item 19] The aforementioned conversion includes character conversion between different character sets, as described in any of items 11 through 18. [Item 20] A computer program product for converting shared libraries to convert 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, where the 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, wherein the source relocation information does not include relative 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 is derived from the source memory image. The target memory image is enhanced using fixed-length eye catcher information derived from the source symbol name for each external source symbol, and The target memory image is written to the target object file so that the target 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, where the 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, wherein the source relocation information does not include relative 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 image is derived from the source memory image; The steps include enhancing the target memory image using fixed-length eye catcher information derived from the source symbol name for each external source symbol, and The step of writing the target memory image to the target object file so that the target 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 step of enhancing the target memory image is performed by placing the eye catcher information at a target memory image position of the target memory image, which is a fixed offset from the target symbol address.
3. The method according to claim 2, wherein the target symbol address is generated by a supporting compiler.
4. The method according to claim 2 or 3, wherein the eye catcher information includes debug information.
5. The method according to any one of claims 2 to 4, wherein the step of checking that the target memory image location was created by a supporting compiler precedes the step of enhancing the target memory image.
6. The method according to claim 5, wherein the checking step is performed by confirming that the target memory image location contains only predetermined assembly instruction sequences.
7. The method according to claim 5, wherein the predetermined assembly instruction sequence is a no-operation instruction.
8. The step of determining that the target memory image location is available for the enhancement. The method according to any one of claims 2 to 7, further comprising:
9. The aforementioned conversion is Character conversion between different character sets The method according to any one of the prior claims 1 to 8, including the method described above.
10. The aforementioned conversion is The step of constructing a hash value having a predetermined number of characters for the name used in the source image data. The method according to any one of the prior claims 1 to 9, including the method described above.
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 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, where the 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, wherein the source relocation information does not include relative 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 is derived from the source memory image. The target memory image is enhanced using fixed-length eye catcher information derived from the source symbol name for each external source symbol, and The target memory image is written to the target object file so that the target library is implemented by the target object file. A conversion system that stores the program code portion that enables this functionality.
12. While enhancing the target memory image, one or more processors The system according to claim 11, which can also be implemented by placing the eye catcher information at a target memory image position of the target memory image, which is a fixed offset from the target symbol address.
13. The system according to claim 12, wherein the target symbol address is generated by a supporting compiler.
14. The system according to claim 12 or 13, wherein the eye catcher information includes debug information.
15. The system according to any one of claims 12 to 14, wherein, before enhancing the target memory image, it is checked that the target memory image location was created by a supporting compiler.
16. The system according to claim 15, wherein the checking is performed by confirming that the one or more processors contain only predetermined assembly instruction sequences for the target memory image location.
17. The system according to claim 16, wherein the predetermined assembly instruction sequence is a no-operation instruction.
18. The aforementioned one or more processors are The system according to any one of claims 12 to 17, which also enables determining whether the target memory image location is available for the enhancement.
19. The aforementioned conversion is Character conversion between different character sets The system according to any one of claims 11 to 18, including the system described above.
20. A computer program product for converting shared libraries in order to convert 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, where the 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, wherein the source relocation information does not include relative 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 is derived from the source memory image. The target memory image is enhanced using fixed-length eye catcher information derived from the source symbol name for each external source symbol, and The target memory image is written to the target object file so that the target library is implemented by the target object file. A computer program product that performs a certain action.