Cross-ISA extension program translation method based on binary rewriting

Abstract

The invention discloses a cross-ISA (Industrial Standard Architecture) extension program translation method based on binary rewriting, which comprises the following steps of: 1) naming an instruction set ISA of a program to be translated as an original ISA, and naming an instruction set ISA on target hardware for running original ISA extension as a target ISA; 2) performing comparative analysis on a binary file corresponding to the original ISA extension compilation and a binary file corresponding to the target ISA extension compilation to obtain an instruction needing to be translated relative to the target ISA extension in the original ISA extension, and segmenting the instruction into a plurality of program basic blocks needing to be translated; 3) allocating a jump instruction and an address space for translating and storing translated codes to each program basic block; (4) distributing the program basic blocks into the corresponding address spaces through a jump instruction to carry out static binary translation, and generating a static file; and (5) distributing a loading address for the static file by utilizing a loader according to the address distribution information in the static file, and loading the static file to a corresponding position.

Description

Technical Field

[0001] This invention belongs to the field of computer software technology and relates to a cross-ISA extension program translation method based on binary rewriting. Background Technology

[0002] Binary rewriting refers to creating a new binary file based on an existing binary program, using methods such as patching or regeneration. Cross-ISA extension translation refers to the need for binary rewriting of the instruction set architecture (ISA) of the program before rewriting to generate a binary program that can run on hardware with ISA extensions that are inconsistent with the original ISA. Here, ISA extension refers to additional instructions and hardware designs added on top of the original ISA set for scenarios including but not limited to energy consumption and accelerated computing.

[0003] CPUs with ISA extensions have proven to have significant advantages in performance, power consumption, and parallelism, but often encounter cross-ISA execution issues. Commercial instruction sets (such as x86 and Arm) have fixed extensions (determined by the publisher). To address these issues, existing ISAX heterogeneous computing systems have provided customized adaptations for different extensions. However, this approach is no longer feasible in RISC-V for the following reasons: 1. The open-source nature of RISC-V allows for a large number of user-customized extensions. There is even work developing infrastructure for RISC-V hardware extension design, accelerating the development process. This extension model implies an explosive growth in extensions, and the previous customized ISA extension system design pattern could not achieve customized development of the system and compilation toolchain for each extension.

[0004] Existing translation efforts are not designed for ISA extensions, but primarily target cross-ISA translation, such as mutual translation between ARM and x86. These translations are generally divided into static translation and dynamic translation.

[0005] Static translation separates instruction translation from code execution, translating instructions offline and fully optimizing the generated code on a per-input source-program basis, resulting in high execution efficiency. However, static translation cannot obtain complete control flow information in advance, leading to insufficient handling of issues such as code mining and code relocation, causing translation uncertainty and performance costs, and severely limiting the application scenarios of static translation.

[0006] Dynamic translation employs a just-in-time (JIT) compilation strategy, translating and executing code on a block-by-block or function-body basis. When untranslated code is encountered, control flow switches to the translator for translation. Dynamic translation overcomes the limitation of static translation in obtaining complete control flow information; however, the runtime translation of dynamic translation incurs significant overhead.

[0007] Binary rewriting involves further optimizing the binary file of the same ISA to enhance its performance, security, and aid in debugging and performance analysis. Current binary rewriting work is mainly divided into two categories: binary lifting and binary patching.

[0008] Binary promotion refers to translating the assembly code obtained from binary analysis into a specific intermediate representation (IR), and then recompiling the IR into a binary file according to the needs of binary rewriting (security, performance, or debugging, etc.), thus completing the binary rewrite. Binary patching, on the other hand, uses jump instructions to replace certain instructions and relocates them into the rewritten binary code, thereby modifying the program's execution logic and achieving the purpose of binary rewriting.

[0009] However, the above work cannot meet the requirements for cross-ISA extension translation. First, binary translation and binary promotion require control flow analysis, but existing control flow analysis is incomplete, which will lead to changes in the semantics of the translated work, which is unacceptable in the ISA extension translation scenario. Second, existing binary patching work has strong architecture dependence (for x86) and limitations in use cases (binary code segment size), making it unsuitable for ISA extension translation. Therefore, it is necessary to design a cross-ISA extension program translation technology based on binary rewriting. Summary of the Invention

[0010] To address the problems existing in the prior art, the purpose of this invention is to provide a cross-ISA extension program translation method based on binary rewriting. This method converts the program into a version that can run on hardware with an ISA extension inconsistent with the original. For ease of description, the ISA of the program to be translated will be referred to as the original ISA, its extension as the original ISA extension, and the ISA of the target hardware to be run on as the target ISA, with its extension referred to as the target ISA extension. Compared to previous work, this invention can guarantee the correctness of cross-ISA extension translation, i.e., it does not change the program's external semantics. Furthermore, it is applicable to ISA extension scenarios, supports large-scale software, and supports RISC architectures, etc.

[0011] The technical solution of this invention is as follows:

[0012] A cross-ISA extension translation method based on binary rewriting, comprising the following steps:

[0013] 1) The instruction set ISA of the program to be translated is called the original ISA, the extension of the original ISA is called the original ISA extension, the instruction set ISA on the target hardware used to run the original ISA extension is called the target ISA, and the extension of the target ISA is called the target ISA extension.

[0014] 2) Compare and analyze the binary file corresponding to the original ISA extension compilation with the binary file corresponding to the target ISA extension compilation to obtain the instructions in the original ISA extension that need to be translated relative to the target ISA extension and divide them into several basic program blocks that need to be translated;

[0015] 3) Allocate a jump instruction and an address space for translating and storing the translated code for each of the program basic blocks;

[0016] 4) The program's basic blocks are allocated to the corresponding address spaces using jump instructions for static binary translation, generating static files;

[0017] 5) The loader allocates a loading address to the static file based on the address allocation information in the static file and loads it into the corresponding location to avoid conflicts between the virtual address of the static file and other runtime modules on the target hardware.

[0018] Furthermore, the method for allocating a jump instruction and an address space to each program basic block is as follows: determine the jump instruction of each program basic block according to the characteristics of the target ISA; if the jump instruction of the program basic block is a short jump instruction, directly replace the translated instruction with a single jump instruction in the ISA; if the jump instruction of the program basic block is a long jump instruction, compress the long jump instruction using a compressed instruction set.

[0019] Furthermore, the compression instruction set includes, but is not limited to, RISC-VC extensions and Arm thumb.

[0020] Furthermore, the method for modifying the error handling module in the kernel of the target hardware is as follows: the kernel captures unidentified instruction errors generated by untranslated code and translates them at runtime, and then resumes program execution; for unidentified error jumps, the kernel first maintains a recovery table at the position of each candidate error jump when loading the binary file, and when a candidate error jump occurs, the execution flow is restored to the position of the candidate error jump to continue execution.

[0021] Furthermore, the error handling module in the kernel of the target hardware is modified to implement runtime translation and runtime error code relocation mechanism to handle edge cases caused by unrecognized instructions and jump instructions.

[0022] The overall architecture of this invention is as follows Figure 1 As shown, the input of this invention is a binary file compiled from the original ISA extension, and the output is a binary file that can run on the target ISA. This invention mainly consists of five parts: binary analysis, jump board insertion, extension translation, program loading, and error handling. Binary analysis primarily analyzes the parts of the original ISA extension that need translation relative to the target ISA extension and divides them into basic program blocks that need translation. The jump board insertion part, based on the results of the binary analysis, allocates address spaces for jump instructions and translation code to the divided basic program blocks, allowing the jump instructions to jump to the allocated address space (located after existing segments in the binary file). Subsequently, the extension translation part performs static binary translation within the allocated address space according to the content of the basic program blocks, generating a static file. The program loading part modifies the loader so that it can allocate appropriate loading addresses (virtual addresses) for the translated basic blocks based on the address allocation information in the static file and load them into the corresponding locations, avoiding conflicts between the virtual addresses of the translated code blocks and other runtime modules (such as shared libraries). Finally, the error handling section modifies the error handling module in the hardware kernel to implement runtime translation and a runtime error code relocation mechanism, ensuring that edge cases caused by unrecognized instructions and jump instructions are handled correctly. The specific module description is as follows:

[0023] I. Binary Analysis Section

[0024] Extended instruction identification: Based on the disassembler, the input binary program is disassembled to identify the extended instruction parts that need to be rewritten and mark their locations.

[0025] Generate translation base blocks: During the disassembly process, the basic blocks of the program are first generated, that is, the different binary codes are divided into blocks by control flow; after obtaining the basic blocks of the program, the basic blocks that need to be rewritten for the extended instructions are marked; then, based on the distribution of the basic blocks containing the extended instructions that need to be rewritten, the basic blocks of specific combinations are searched and merged based on the control flow analysis results to obtain the final basic blocks that need to be translated.

[0026] II. Inserting the scaffold

[0027] The beginning of the basic program block that needs to be rewritten is replaced with a jump instruction, and then execution jumps to the translated basic block. We call the jump instruction a jump table. Inserting a jump table involves two steps: the first step is selecting the jump table, and the second step is constructing the instruction space for instruction translation.

[0028] Skip selection involves two steps: selecting the jump instruction and selecting the jump register. Different jumps of different lengths require different jumps. The specific jump length is selected based on the original ISA jump instruction length limit. Since the address space of the translated code is after all segments of the binary file, when the size of the binary file is less than the jump instruction length limit, a single jump instruction from the ISA can be used to directly replace the translated instruction. When the size of the binary file is greater than the jump instruction length limit, multiple instructions are required for the jump, but this will corrupt the program's address space and thus the program's semantics. In this invention, long jumps need to be compressed using a compressed instruction set (including but not limited to RISC-VC extensions and Arm thumb, etc.) to ensure the correctness of the program's semantics. The specific compression method is as follows:

[0029] A typical long jump instruction consists of a register write instruction and a register jump instruction. Often, directly replacing the instruction to be translated with a long jump instruction will result in a potential jump to the second instruction of the long jump instruction, leading to a semantic error in the program.

[0030] This method compresses the second instruction of a long jump instruction and uses a compressed nop instruction to offset the jump table. This ensures that potential jumps will only occur in the middle of a register write instruction, generating an instruction unrecognized error; this error is then handled by the error handling module, guaranteeing the correctness of the program.

[0031] Meanwhile, register write instructions in long jumps require selecting a jump register to save the target address. To avoid overwriting the original values ​​of the registers, this work uses a live-in register analysis method for register selection. When live-in register analysis cannot find a usable register, this method utilizes ISA special registers (e.g., the gp register in RISC-V). Since the values ​​of these registers do not change, this method completes the jump by first overwriting the values ​​of these registers and then restoring the values ​​of these registers.

[0032] Translation instruction space construction: After selecting a jump table, the code segment that needs to be rewritten is first replaced with the jump table to facilitate access by unknown control flow; then, according to the target address of the jump, the rewritten code space and the instruction to jump back to the original code segment are allocated.

[0033] III. Extended Translation

[0034] After identifying the rewritten block and inserting the jumper, the rewritten executable code needs to be inserted into the address space constructed in the previous step. This code is a translation of the extended instructions in the code block, which is mainly divided into two parts: code translation and static file generation.

[0035] Code translation: This step translates the original ISA extension instructions that need to be translated in the code block into the target ISA extension instructions, then optimizes the translated instructions and writes them into the corresponding address space.

[0036] Binary file generation: This step constructs the rewritten code written to the address space into an independent segment in the binary file, and retains its address information in the binary file to generate the final binary file.

[0037] IV. Program Loading & Error Handling

[0038] This step is divided into two parts: the program address building module and the kernel error handling module. The program address building module uses the address information stored in the modified binary file to correctly load the translated code into memory based on the loader. The kernel error handling module handles errors caused by incomplete binary analysis through runtime translation and redirection.

[0039] Loader: The loader needs to read the address information of the rewritten code and the location of the rewritten code segment stored in the binary file by the static file generation module. Based on this address information and the rewritten code, the loader loads the rewritten code into the correct virtual memory so that the modified binary file can run correctly.

[0040] Kernel module modifications: Some special cases exist, such as unreliable binary analysis results, leading to: 1. Some code requiring translation not being translated, or the registers for jumps not being found; 2. Some control flows not being correctly identified, resulting in erroneous jumps. The kernel needs to handle these situations. First, untranslated code will generate an instruction unrecognized error. The kernel will catch this error and translate it at runtime, then resume program execution. Second, for unrecognized erroneous jumps, the kernel first maintains a recovery table for all possible erroneous jump locations when loading the binary file. When an erroneous jump occurs, it will restore the execution flow of these jumps to the location where the jump error occurred and continue execution.

[0041] Figure 2 The flowchart for the rewriting process is as follows, with specific steps described below:

[0042] Step 1, Binary Analysis and Instruction Identification: Use a disassembler to analyze the input binary program containing the original ISA extensions, identify and mark the extended instruction parts that need to be rewritten, in order to understand which instructions need to be translated.

[0043] Step 2, Generate translation basic blocks: Divide the program into basic blocks according to the control flow graph, and further subdivide the basic blocks of instructions that need to be rewritten based on the tags obtained in Step 1, so as to manage and translate these code blocks more accurately.

[0044] Step 3, Jump Insertion: The code block that needs to be rewritten, obtained in Step 2, is replaced using jump instructions (jump keys) to allow the execution order to jump to the modified instruction section. Specifically, this includes:

[0045] 1. Jump instruction selection: Select the appropriate jump instruction based on the jump length and architecture characteristics.

[0046] 2. Register selection: Use live-in register analysis to select the appropriate register for the jump.

[0047] Step 4, Translation Instruction Space Construction: Allocate space to store the rewritten code, making room for the rewritten instructions and instructions that jump back to the original code.

[0048] Step 5, Extended Instruction Translation and Optimization: Translate the original ISA extension in the basic block generated in Step 2 into the target ISA instruction, and use the translated basic block as the jump target in Step 3.

[0049] Step 6, Generate binary file: Write the translated code region from Step 5 into a separate segment and write it into the binary file, while retaining the address space information from Step 4 to ensure that these new segments can be correctly identified and loaded at runtime.

[0050] Step 7, program loading and error handling, is divided into two parts:

[0051] 1. Loader modification: Ensure that the loader can read the translation code in step 5 and the address information in step 4 from the static binary file generated in step 6 and load the static binary file into the correct memory location.

[0052] 2. Kernel error handling: Resolves errors caused by unrecognized instructions and unrecognized control flow, ensuring the program runs normally.

[0053] The advantages of this invention are as follows:

[0054] (1) Traditional binary translation methods only consider binary translation across ISAs and do not have a translation mechanism for extensions. This invention designs a translation mechanism for ISA extensions based on binary rewriting, which enhances the running efficiency after translation.

[0055] (2) This invention utilizes the compression extension under the RISC instruction set and the special registers in ISA to design a rewrite mechanism, which ensures reliability and enhances rewrite capability compared to the previous binary rewrite work. Attached Figure Description

[0056] Figure 1 This is a block diagram of the method of the present invention.

[0057] Figure 2 This is a flowchart of the method of the present invention. Detailed Implementation

[0058] The present invention will now be described in further detail with reference to the accompanying drawings. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0059] Suppose an edge IoT device (supporting only the RVI instruction set) needs to run a program (with a relatively long code segment) containing RISC-V Vector Extensions (RVV) locally. The process of binary rewriting the program can be achieved through the following steps:

[0060] Step 1, Binary Analysis and Instruction Identification: Analyze the binary program containing RVV instructions using a disassembler. In this stage, identify all RVV instructions and mark their locations within the program. This process relies on the recognition of the inherent instruction patterns of RVV.

[0061] Step 2, Generate Translation Base Blocks: Mark each base block containing RVV instructions. After identifying these base blocks, further subdivide them to generate the base blocks that need to be translated.

[0062] Step 3, Jump Insertion: Replace the beginning of each RVV instruction block that needs to be translated with a jump instruction, so that the program control flow can jump to the translated RVI instruction section.

[0063] 1. Jump instruction selection: Since the target program segment is long, a long jump board is used to replace the target instruction.

[0064] 2. Register selection: Analyze which live-in registers are used and select the appropriate register to store the return jump address.

[0065] Step 4, Translation Instruction Space Construction: Allocate space to store the translated RVI code. Ensure the target memory of the jump board is sufficient to store the translated instructions, and set the location of the jump instruction to return to the original flow.

[0066] Step 5, Extended Instruction Translation and Optimization: Each identified RVV instruction in the basic block generated in Step 2 is sequentially translated into an equivalent RVI instruction. Since RVI itself does not support vector operations, vector operations typically need to be decomposed into multiple scalar operations. These scalar instructions are optimized to reduce the performance overhead introduced by the translation. Subsequently, these basic blocks serve as the jump targets for the springboards inserted in Step 3.

[0067] Step 6, Generate Binary File: Embed the translated RVI instructions from Step 5 into the binary file as a separate code segment. Ensure that the address information of all translated RVI segments generated in Step 4 is correctly recorded for use during loading.

[0068] Step 7, Program Loading and Error Handling:

[0069] 1. Loader modification: Adjust the loader based on the binary file generated in step 6, recognize the RVI code segment rewritten in step 5 and the code information generated in step 4, so that the binary file generated in step 6 can be executed normally at runtime.

[0070] 2. Kernel Error Handling Module: When an untranslated vector instruction is encountered during execution, an instruction not recognized error occurs. The kernel catches and translates this error, and then continues execution. Simultaneously, when loading the binary file, the kernel maintains a recovery table for all possible error jump locations. When an error jump occurs, it restores the execution flow of these jumps to the location where the error occurred and continues execution.

[0071] Although specific embodiments of the invention have been disclosed for illustrative purposes to aid in understanding and implementing the invention, those skilled in the art will understand that various substitutions, variations, and modifications are possible without departing from the spirit and scope of the invention and the appended claims. Therefore, the invention should not be limited to the content disclosed in the preferred embodiments, and the scope of protection claimed by the invention is defined by the claims.

Claims

1. A method for translating cross-ISA extension programs based on binary rewriting, comprising the following steps: 1) The instruction set ISA of the program to be translated is called the original ISA, the extension of the original ISA is called the original ISA extension, the instruction set ISA on the target hardware used to run the original ISA extension is called the target ISA, and the extension of the target ISA is called the target ISA extension. 2) Compare and analyze the binary file corresponding to the original ISA extension compilation with the binary file corresponding to the target ISA extension compilation to obtain the instructions in the original ISA extension that need to be translated relative to the target ISA extension and divide them into several basic program blocks that need to be translated; 3) Allocate a jump instruction and an address space for translating and storing the translated code for each of the program basic blocks; 4) The program's basic blocks are allocated to the corresponding address spaces using jump instructions for static binary translation, generating static files; 5) The loader allocates a loading address to the static file based on the address allocation information in the static file and loads it into the corresponding location to avoid conflicts between the virtual address of the static file and other runtime modules on the target hardware.

2. The method according to claim 1, characterized in that, The method for allocating a jump instruction and an address space to each program basic block is as follows: determine the jump instruction of each program basic block according to the characteristics of the target ISA. If the jump instruction of the program basic block is a short jump instruction, use a single jump instruction in the ISA to directly replace the translated instruction; if the jump instruction of the program basic block is a long jump instruction, use a compressed instruction set to compress the long jump instruction.

3. The method according to claim 2, characterized in that, The compressed instruction set includes, but is not limited to, RISC-VC extensions and Arm thumb.

4. The method according to claim 1, characterized in that, The method for modifying the error handling module in the kernel of the target hardware is as follows: the kernel captures unrecognized instruction errors generated by untranslated code and translates them at runtime, and then resumes program execution; for unrecognized error jumps, the kernel first maintains a recovery table at the position of each candidate error jump when loading the binary file, and when a candidate error jump occurs, the execution flow is restored to the position of the candidate error jump to continue execution.

5. The method according to claim 1, characterized in that, Modify the error handling module in the kernel of the target hardware to implement runtime translation and runtime error code relocation mechanism to handle edge cases caused by unrecognized instructions and jump instructions.

Images