PaperlayerView exact revision on arXiv

Source-linked AI summary

No More Translation at Runtime: LLM-Empowered Static Binary Translation

Zhibo Liu, Huaijin Wang, Wai Kin Wong, Daoyuan Wu, Shuai Wang

arXiv:2610.05999v1cs.OScs.SE

TL;DR

ARM adoption faces a software hurdle because decades of development target x86-64, while closed-source, platform- or CPU-specific translators and ISA complexity impede research. The paper translates x86-64 assembly to AArch64 ahead of execution using LLM-generated reusable rules and semantic verification of simplified snippets. LLMSbt reportedly outperforms traditional open-source tools and a leading industrial translator, producing portable binaries with near-native performance.

  • Problem

    ARM adoption faces a software hurdle because decades of development target x86-64, while closed-source, platform- or CPU-specific translators and ISA complexity impede research.

    Source: §1 · pp. 1–2

  • Method

    The paper translates x86-64 assembly to AArch64 ahead of execution using LLM-generated reusable rules and semantic verification of simplified snippets.

    Source: §1 · p. 2, §4.1 · p. 5, §4.2 · p. 6

  • Results

    LLMSbt reportedly outperforms traditional open-source tools and a leading industrial translator, producing portable binaries with near-native performance.

    Source: §1 · p. 2, §9 · p. 14

  • Takeaways & Limitations

    The work presents static assembly-to-assembly translation as a promising new avenue for binary translation research.

    Source: §9 · p. 14

    Translated code's performance depends on how well it uses CPU microarchitecture, and designing translators that account for this remains an open challenge.

    Source: §6.3 · p. 12

Abstract

from arXiv · show

While AArch64 CPUs are becoming strong market contenders, their software ecosystem lags behind the mature x86-64 environment, hindering the adoption of the new architectures and impacting user experience. Binary translation bridges this divide by converting binary code from one architecture (e.g., x86-64) to run on another (e.g., AArch64), allowing legacy software to benefit from modern hardware's performance and energy efficiency advantages. Current translation methods are typically either dynamic, which adds significant runtime overhead, or static, which struggles with reliability due to the inherent complexities of binary analysis. This paper introduces a new static, assembly-to-assembly translation paradigm that transforms binary code ahead of execution, generating portable, efficient native-like binaries that run on AArch64 devices without runtime frameworks. Benefiting from recent breakthroughs in large language models (LLMs), we provide a practical and automated translation engine that produces high-quality code with minimal human intervention. To ensure correctness, we introduce a crucial verification step, where we split the assembly code into simplified snippets, enabling efficient and scalable semantic verification. Our evaluation shows that this approach significantly outperforms existing open-source solutions with a large margin, producing binaries with near-native performance. Furthermore, it shows substantial improvements over the leading industrial translator, ExaGear, illuminating a promising new direction for cross-architecture binary translation research.

1 Introduction

The x86-64 software ecosystem and the AArch64 hardware ecosystem are mismatched, while existing translation approaches face reliability or runtime-cost challenges. The paper proposes LLM-assisted static assembly-to-assembly translation, with verification, to produce portable binaries and reduce translator-development effort.

1 Introduction

  • AArch64 adoption faces a software hurdle because decades of development have targeted x86-64, and legacy applications may lack source code or complete build environments for recompilation.The paper frames binary translation as a way to migrate software between instruction-set architectures.Source: §1 · pp. 1–2
  • Static translation lifts assembly to an intermediate representation and faces difficulty recovering semantics lost during compilation, while dynamic translation adds runtime overhead and requires its framework.The passage identifies symbols and variables as examples of discarded semantic information.Source: §1 · p. 2
  • Closed, platform- or CPU-specific state-of-the-art translators and the complexity of cross-ISA instruction semantics make translator development difficult and slow academic research.The paper identifies a need for an automated solution requiring less specialized effort.Source: §1 · p. 2
  • The paper proposes ahead-of-time x86-64-to-AArch64 assembly translation to produce portable binaries without runtime translation overhead.It also parameterizes translation results into reusable rules for future translations.Source: §1 · p. 2
  • LLMSbt reportedly outperforms open-source tools and a leading industrial translator, with translated binaries achieving near-native performance while remaining portable.The introduction says ExaGear is surpassed in some real-world scenarios.Source: §1 · p. 2
  • LLMSbt uses LLMs to build its translation engine and verifies simplified code snippets to support correctness and scalability.The stated aim is to reduce reliance on costly expert knowledge and manual effort.Source: §1 · p. 2

2 Background

The background describes challenges in recovering program structure from binaries, the promise and reliability risks of LLMs, and the trade-offs among binary-translation designs. It positions LLMSbt as an automated, static approach while noting that it is not intended to replace mature industrial translators.

2.1 Binary Analysis and Reverse Engineering

  • Disassembly can miss indirect control-flow targets, and compilation discards symbols, leaving offsets that can obstruct correct recompilation; binary analysis and relocation data can help recover symbols.Symbolic execution instead tracks symbolic values across branches and uses constraints to check program properties.Source: §2.1 · pp. 2–3

2.2 Large Language Models

  • LLMs have shown promise in language and code tasks, but can produce plausible incorrect outputs, motivating a semantic-equivalence check in the translation pipeline.The paper points to that check in Section 4.4.Source: §2.2 · p. 3

2.3 Binary Translation

  • Binary translators disassemble software and may translate assembly directly or lift it to an intermediate representation; translation blocks can be cached to avoid redundant work.The paper distinguishes concise IR lifters, emulational IR lifters, low-level IR translators, and assembly translators.Source: §2.3 · pp. 3–4
  • LLMSbt automates translation with LLMs and separates its framework from translation rules, which are mostly extracted from generated examples and require minimal expert knowledge.The static approach also allows LLMs and verification to be incorporated into translation.Source: §2.3 · p. 4
  • LLMSbt is presented as a source of new concepts and a translation paradigm, not as a replacement for mature industrial translators.The paper notes that binary translation remains complex and that unresolved problems require further research.Source: §2.3 · p. 4
  • The taxonomy compares translators by functional fidelity and flexibility, and the paper reports that several approaches have limitations for reliable cross-architecture translation.The authors say their evaluation focuses on McSema, Instrew, QEMU, and ExaGear; BinRec is described as unsuitable for cross-architecture translation.Source: §2.3 · p. 4

3 Motivation

The motivation identifies static disassembly’s difficulty with indirect targets and missed symbols, while dynamic disassembly carries runtime and portability costs. The paper proposes static assembly translation, LLM-generated reusable rules, and snippet-level semantic verification as responses to these challenges.

3 Motivation

  • Static disassembly can miss indirect targets and symbols, while dynamic disassembly requires runtime translation and prevents portable output independent of its framework.The paper proposes using binary rewriting to support static assembly-to-assembly translation while bypassing IR-lifting challenges.Source: §3 · p. 5
  • LLMs can automatically generate translation results, and parameterized translations can be reused to accelerate future work.The passage presents this as a practical foundation for research and a way to replace the need for human experts.Source: §3 · p. 5
  • Instruction variants often share translation patterns, while instruction semantics are intricate and manual translation testing is tedious and error-prone.The paper also notes symbolic execution can face path-explosion scalability issues.Source: §3 · p. 5
  • The proposed verification method splits assembly into small snippets, checks them with symbolic execution, and then reassembles them.The approach is intended to provide feedback to human experts or LLMs while streamlining translator development.Source: §3 · p. 5

4 Design

LLMSbt is a static x86-64-to-AArch64 translation design that combines snippet-based translation, LLM assistance, semantic verification, and assembly stitching. Its components aim to make translation manageable while preserving correctness across the pipeline.

4.1 Overview

  • LLMSbt rewrites disassembled code into SSA-like snippets, reuses matching translation rules or invokes an LLM, verifies translations, and stitches them into AArch64 assembly.Translation results can also be parameterized for later reuse.Source: §4.1 · p. 5

4.2 Binary Code Splitting

  • Splitting code into small snippets simplifies LLM translation and verification; each snippet assigns a variable at most once, while all memory is treated as one variable.The adapted SSA format allows variables to be used before definition; each snippet therefore has at most one memory access.Source: §4.2 · p. 6

4.3 LLM-Empowered Translation

  • LLM translation uses interpretation-first prompting, retrieves similar valid syntax examples, and iteratively refines output from verification feedback, stopping on success or after five iterations.The pipeline uses GCC for compilation and angr for verification.Source: §4.3 · p. 7

4.4 Semantic Verification

  • Semantic verification symbolically executes branch-free snippets, then uses Z3 to test whether a register mapping makes corresponding output expressions equivalent.The mapping checks equal initial symbolic values and requires output expressions to match; temporary AArch64 registers can be accommodated.Source: §4.4 · p. 8

4.5 Translation Rule Parameterization

  • Verified translations are generalized by replacing concrete operands with parameters, then reused when a new snippet matches the rule’s instruction sequence and parameter types.A fixed register mapping restores concrete operands, and the growing rule database can reduce repeated LLM queries.Source: §4.5 · pp. 8–9

4.6 Snippets Stitching

  • Stitching restores control flow and handles stack alignment and call-ABI differences, but its correctness assumes no hidden cross-snippet dependencies and mediated ABI compatibility.Specialized data types or non-standard ABIs may cause argument-passing or return-address problems; affected libraries should be translated as well.Source: §4.6 · pp. 9–10

5 Implementation

LLMSbt combines symbolic execution and GPT-4 with binary rewriting to translate user-level, single-threaded C programs from x86-64 to AArch64. Its current target excludes obfuscation, self-modification, and x87 floating-point instructions.

5 Implementation

  • The roughly 6K-LoC Python prototype uses angr for symbolic execution, GPT-4 as its LLM, and RetroWrite for disassembling and symbolizing binaries.The binaries were compiled with GCC 11.4.0 on Ubuntu 22.04; translated programs ran on an rk3588 board, with ExaGear comparisons on a Kunpeng 920 virtual machine.Source: §5 · p. 10
  • The implementation targets user-level, single-threaded C programs compiled without obfuscation or self-modification, and supports core general-purpose and frequently used SSE instructions.Support for floating-point operations is limited because x87 FPU instructions are excluded.Source: §5 · p. 10

6 Evaluation

The evaluation examines translation rules and performance across 23 programs, comparing LLMSbt with open-source translators and ExaGear, then profiling instruction, cycle, and microarchitecture behavior.

6.1 Characteristics of Translation Rules

  • The collection contains 3,149 rules covering 3,756 x86-64 and 7,784 AArch64 instructions; about 95% of rules use three or fewer x86-64 instructions.Each rule maps an average of 1.2 x86-64 instructions to 2.5 AArch64 instructions.Source: §6.1 · p. 10, Table 3 · p. 11
  • Rule collection cost about 2,036K tokens and less than $130, covering 148 x86-64 and 102 AArch64 instructions, with 68 rules added manually where the LLM failed.The work focuses on 259 core general-purpose and frequently used SSE instructions; specialized hardware-dependent instructions are outside its scope.Source: §6.1 · p. 11

6 Evaluation

  • The benchmark suite comprises 23 programs, including CHStone, Coremark-Pro, SPEC CPU, Zydis, and yyjson; correctness is assessed through consistent input-output behavior on test cases.The suite is intended to assess LLMSbt across diverse programs and complex instructions.Source: §6.2 · p. 11

6.2 Performance Overhead

  • QEMU and Instrew sometimes exceed 20× overhead; frequent restarts in low-workload tests trigger repeated translation, while Instrew also incurs LLVM runtime optimization and code-generation overhead.By contrast, LLMSbt and McSema translate offline and produce portable binaries that execute natively; the authors attribute LLMSbt’s performance and robustness to this approach and reduced runtime overhead.Source: §6.2 · p. 11
  • On the tested cases, LLMSbt consistently and significantly outperforms other translators; McSema failed on 11 of 23 cases, while Instrew and QEMU failed on xz.Against ExaGear, LLMSbt showed consistently stable and superior overall performance.Source: §6.2 · p. 11

6.3 Performance Analysis

  • Translated binaries execute more instructions and consume more CPU cycles than native binaries, but avl-tree uses only 27% more cycles despite executing 50% more instructions.The authors suggest CPU pipeline behavior mitigates some overhead from increased instruction count.Source: Table 7 · p. 12, §6.3 · p. 12
  • Native binaries generally have more branch misses, while translated binaries have more cache misses; avl-tree has over 200K additional cache misses and many backend stalled cycles.The authors attribute avl-tree’s overhead primarily to poor cache efficiency and identify microarchitecture-aware translation as an open challenge.Source: Table 8 · p. 12, §6.3 · p. 12

7 Discussion

The discussion identifies challenges beyond the current pipeline’s scope, including concurrency, complex C++ features, floating-point operations, and system calls. It also describes manual rule authoring as a practical fallback when LLM translation fails.

7 Discussion

  • Concurrent-program translation remains challenging because the architectures have different memory models; prior work on inserting and optimizing fences may be adaptable.The cited methods target lifted IR rather than assembly-level translation.Source: §7 · pp. 12–13
  • C++ exceptions and virtual functions complicate disassembly by affecting control-flow graphs and data flow, while the method depends on correct disassembly.Improving binary rewriting and disassembly could extend coverage of these language features.Source: §7 · p. 13
  • The implementation excludes x87 floating-point instructions because mapping x86-64’s stack-based FPU to AArch64 NEON requires substantial manual effort and expertise.The authors leave a more efficient automated method for this translation to future work.Source: §7 · p. 13
  • The evaluation targets user-level applications, where native libraries handle system calls; translating system calls remains complex because conventions and data layouts differ.Preliminary experiments suggest patching native libraries to enforce data-structure consistency can resolve some issues with minimal performance impact.Source: §7 · p. 13
  • LLM failures required 68 manually created translation rules, but short snippets and simple data flow let experienced developers author equivalents in minutes and verify them automatically.Verified code is parameterized into a reusable rule.Source: §7 · p. 13

8 Related Work

Related work spans translation validation, binary-translation extensions, and automated generation of translation logic. This paper distinguishes its approach by having LLMs generate assembly directly rather than relying on extensive training data or a separate compilation process.

8 Related Work

  • Prior translation-validation work targets lifting to LLVM IR, compiler optimizations, semantic program alignment, or language-parametric frameworks, whereas this work validates assembly-level cross-architecture translation.The cited approaches include instruction-level checking, bounded validation, trace-state matching, and more general validation frameworks.Source: §8 · p. 13
  • Binary-translation research addresses weak memory models, multithreaded programs, stack-layout recovery, indirect branches, and use of debug or source-level information.The section also identifies LLM-based decompilation as related but orthogonal because this work translates binaries rather than recovering source code.Source: §8 · p. 13
  • Earlier automated translation-logic work includes peephole superoptimization, compiler-based lifting, and learned rules for dynamic and system-level translation.Parameterization has also been used to derive more general rules from less training data.Source: §8 · pp. 13–14
  • Unlike those approaches, this method uses LLMs to generate assembly directly, without extensive training data or a separate compilation process.The paper presents this as a contrast with prior learning-based translation-logic generation.Source: §8 · p. 14

9 Conclusion

LLMSbt uses LLMs and semantic verification of small code snippets for static x86-64-to-AArch64 translation, producing portable binaries with near-native performance. It outperforms traditional open-source tools and a leading industrial translator.

9 Conclusion

  • LLMSbt outperforms traditional open-source tools and a leading industrial translator while producing binaries with near-native performance.The conclusion identifies this as an evaluation result.Source: §9 · p. 14
  • The static assembly-to-assembly paradigm converts x86-64 binaries to AArch64 ahead of execution and produces portable binaries.Source: §9 · p. 14
  • LLMs substantially reduce the manual effort and expertise required to build translation engines.Source: §9 · p. 14
  • Correctness is addressed through efficient semantic verification of small, simplified code snippets.Source: §9 · p. 14

A Appendix

The appendix includes a table titled “Evaluated software.”

A Appendix

A.1 Performance of Static Concise IR Lifters

On the same 23 software used in the paper’s evaluation, Mctoll, RetDec, and Rev.ng all failed to provide functionally correct, usable lifted IR.

A.1 Performance of Static Concise IR Lifters

  • All three evaluated static concise IR lifters failed on the 23 software cases: RetDec and Rev.ng produced non-compilable or functionally incorrect IR, while Mctoll lifted none.RetDec left skipped or unimplemented instructions undefined, and Rev.ng binaries crashed immediately.Source: §A.1 · p. 18

A.2 Binary-Level Data Structure Inconsistency

The x86-64 and AArch64 Linux kernels define the stat structure with different member ordering, and binary-level offsets can therefore target the wrong members after translation.

A.2 Binary-Level Data Structure Inconsistency

  • The x86-64 and AArch64 stat layouts order st_nlink and st_mode differently, creating a binary-level data-structure inconsistency.Source: §A.2 · p. 18, Figure 10 · p. 18
  • Although glibc keeps the same fstat API and parses returned data according to the target architecture, binary references use constant offsets and may access the wrong members.Source: §A.2 · p. 18
Loading 2610.05999v1…