核心摘要

　　拿到一个没有源码的 x86 程序，有三个判定动作决定了后面走哪条路：这个程序是什么打包形态、它依赖哪些架构相关文件、有没有内核态组件。判定结果不同，可行路线完全不同——软件包能重构的就重构出鲲鹏兼容包，依赖能替换的就替换后原地运行，二者都不成立时才轮到运行时的指令翻译。鲲鹏DevKit 应用迁移工具覆盖前两条路径，动态二进制翻译工具 ExaGear 承担第三条。

　　　　一、先做三个判定，再谈方案

　　无源码迁移最常见的浪费是路线选早了。三个判定动作花不了多少时间，但能避开大部分返工。

　　　　判定一：这个程序是什么打包形态。 多数HPC场景的x86无源码应用以压缩包形式交付，不涉及RPM等标准包；通用软件发行中则更常见RPM、DEB、JAR、EAR。标准包格式意味着包内结构可解析、依赖可枚举，但“软件包重构”不是只调整文件组织结构，而是在确认包内主程序架构无关或已有ARM版本的前提下，替换架构相关依赖后重新封装。裸二进制没有这层结构信息，可操作空间相对有限。

　　　　判定二：它依赖哪些架构相关文件。 这里的“架构相关文件”是与CPU指令集直接相关的二进制组件，如x86版本的SO库、静态库、可执行文件和内核模块；“依赖”范围更广，还可能包含JAR、配置和其他架构无关文件。架构相关组件中有多少能在鲲鹏平台找到对应版本，直接决定迁移适合依赖替换、软件包重构还是动态二进制翻译。

　　　　判定三：有没有内核态组件。 涉及驱动或内核模块时，先确认是否存在ARM版本以及接口协议是否一致；两项都满足时，可在鲲鹏环境部署ARM版本组件，并继续迁移上层x86应用，例如采用协议一致的ARM版本Mellanox IB驱动。若缺少可替换的ARM版本，则需要联系供应方或调整架构方案。Windows应用可借助Wine等兼容层转接运行，但商用场景仍需评估第三方软件支持与问题兜底能力。

　　顺带说一件常被误会的事：没有源码时不存在「交叉编译」这个选项。交叉编译的前提是有源码可编，无源码场景下这条路是不通的，不必在这个方向上花时间。

　　　　二、三条真实可选的路线

　　判定完成后，可选路线主要有三条。若看运行时性能代价，通常依赖替换和软件包重构更低，动态二进制翻译需要结合业务实测；若看部署代价，ExaGear通常更省事，因为无需修改代码，部署后即可运行符合条件的x86应用。

　　　　路线一：依赖替换后原地运行。 适用于架构相关依赖数量有限、且大多能找到鲲鹏对应版本的情况。做法是先扫出全部架构相关文件，逐个替换成鲲鹏平台可用的版本。这条路代价最低，因为程序本身没有被改动，运行时也没有额外开销。

　　　　路线二：软件包重构。 适用于RPM、DEB、JAR、EAR等标准包格式。这里的“重构”是替换包内架构相关依赖后按原格式重新封装，前提是主程序本身架构无关，或包内x86二进制已有可用的ARM版本；仅调整目录或文件组织结构，不能把x86二进制变成可在ARM平台运行的程序。产出物是新的鲲鹏兼容软件包，后续部署方式与原包基本一致。

　　　　路线三：动态二进制翻译。 适用于拿不到源码、又难以通过依赖替换或软件包重构完成迁移的x86用户态应用。它在运行时将x86指令翻译成ARM64指令，优势是无需修改代码、部署路径直接，并可作为前两条路线之外的补充方案。具体性能表现需结合业务负载实测。

　　这三条不是互斥的。实际项目里常见的组合是：大部分组件走替换或重构，个别拿不到 ARM 版本的自研 SO 留给翻译方案兜底。

　　开源社区也提供不同层级的仿真方案。QEMU user-mode面向单个用户态程序，处理跨架构指令以及用户态ABI和系统调用，属于进程级方案；QEMU system emulation仿真CPU、内存和设备等完整机器环境，可运行完整Guest OS，属于系统级方案，不与进程级动态翻译混为一类。两者均可由QEMU的TCG提供支持，选型时应先按迁移对象是单个应用还是完整系统进行区分。

　　　　三、鲲鹏DevKit 应用迁移工具怎么覆盖前两条

　　鲲鹏DevKit 应用迁移的官方定位是「快速迁移应用，增强鲲鹏架构亲和性」，功能覆盖 x86 软件可迁移性评估与源码迁移，无源码场景对应的是其中的软件迁移评估与软件包重构能力。官方对无源码快速迁移的表述是「零成本，无需改造源码即可完成迁移」。

　　　　软件迁移评估支撑路线一，并同时为打包形态和架构依赖两个判定提供依据。 这项功能自动扫描并分析软件包（非源码包）以及已安装的软件，输出可迁移性评估报告。报告中的文件总数指软件包所依赖的架构相关文件总数，其中“可兼容”指通过使用鲲鹏镜像仓提供的文件包替换后可兼容目标硬件平台，“待修改”指需要用户自行处理才能兼容；架构相关的依赖库文件会显示为SO文件清单。

　　报告里的处理建议分了几种情况，官方说明得比较实在：兼容鲲鹏平台的动态库、静态库、软件包、可执行文件、JAR 包等可直接下载替换，或下载鲲鹏版本源码自行编译；对于一些未开源的依赖文件，工具无法提供下载 URL，需要自行获取后替换；对于鲲鹏平台兼容性未知的文件，需先在鲲鹏平台上验证，若不兼容则联系供应方获取鲲鹏兼容版本、获取源码编译，或使用其他方案替代。

　　有一点值得提前知道：不同的目标操作系统支持的 SO 库不一样，所以迁移报告会有差异。评估结果要绑定具体目标 OS 来看。

　　　　软件包重构解决路线二。 这项功能分析待迁移软件包的构成，重构并生成鲲鹏平台兼容的软件包。当前支持 RPM、DEB、JAR、EAR 四种包类型，单次只允许上传一个软件包，软件包不超过 1GB，依赖文件可上传多个、每个同样不超过 1GB。

　　软件包重构需要在鲲鹏平台环境运行，并按包类型准备对应系统环境：RPM包在类RHEL系统处理，DEB包在类Debian系统处理；包内包含JAR或EAR时还需具备JDK环境。实际操作前按当前版本用户指南核对组件与环境要求即可。

　　重构过程中工具会先查依赖字典，这个行为决定了很多情况下根本不用重构。JAR 包若在鲲鹏 Maven 仓库中存在，工具会提示从鲲鹏 Maven 仓库下载对应 JAR 或直接配置鲲鹏 Maven 仓库源使用，无需重构；RPM 包在 CentOS 7.6 环境下若存在于依赖字典，会提示配置鲲鹏镜像源；非 CentOS 7.6 环境下则提示下载已构建好的 RPM 包并给出迁移指导。只有不在依赖字典中的包才走完整重构流程。

　　重构失败也有明确的续接方式。失败报告会列出已更新依赖文件和缺少依赖文件；缺少 SO、静态库或二进制文件时，自行获取对应名称的文件放入 /opt/DevKit/workspace/xx/porting/data 目录后重试即可，需要的文件可以从 RPM 或 DEB 包里解压取出。重构结果默认保存在 /opt/DevKit/workspace/xx/porting/report/packagerebuild/task_name/。

　　　　迁完之后还有一步，针对已迁移的代码是否最优适配鲲鹏架构做进一步检查，DevKit提供以下维度的鲲鹏亲和性检查：64 位运行模式检查、字节对齐检查、矩阵化检查、向量化检查、cacheline 对齐优化、内存一致性检查、构建亲和检查、计算精度对比分析等。这一步对无源码场景适用范围有限，但如果迁移过程中拿到了部分组件的源码，值得跑一遍。

　　　　四、动态二进制翻译这条路的实际情况

　　ExaGear 是华为自研的动态二进制翻译工具，作用是在运行时将 x86 应用指令翻译为 ARM64 指令并执行，使 Linux x86 应用无需重新编译即可运行在 ARM64 服务器上。

　　　　技术路径基于编译器思路。 按鲲鹏社区技术说明，ExaGear以编译技术为依托，基于IR中间表示层做中端优化，采用“边翻译边执行+二级优化”的策略，并利用运行时热点特征继续优化执行路径。服务器场景主流支持x86_64、x86_32指令集向ARM64翻译；产品资料中列出的其他前端、后端指令集属于整体技术能力说明，不应理解为服务器版支持任意架构互转。

　　　　动态翻译的优势是无需修改原有代码和x86二进制文件，进入Guest环境后即可按原有方式安装并运行应用。ExaGear会在执行过程中完成翻译，并针对热点路径进行二级优化；应用重新启动时会重新翻译。需要生成可分发鲲鹏软件包的场景可选软件包重构，需要快速运行无源码x86应用的场景则更适合动态翻译。

　　　　性能损耗要看清测试前提。 官方文档 FAQ 给出的口径是通过 SPEC CPU 2017 工具测试，CPU 性能损失 10%，同时注明具体实际应用的性能损失可能比 10% 高也可能低，需要实际测试。下载页面对大多数场景的应用给出的是翻译损耗在 20% 以内的表述。两个数字测法与前提不同，做容量规划时按自己业务实测的结果为准更稳妥。

　　　　使用方式是进出 Guest 环境。 Host 指原生 ARM 环境，Guest OS 指 x86 应用运行的 OS 环境。在 Host 上执行 exagear 命令进入 x86 的 Guest OS 环境，执行 exit 退出。进入 Guest OS 后安装 x86 应用的方式与在 x86 系统中一致，需要依赖包时可通过 Guest OS 中配置 yum 或 apt 源获取。

　　　　版本与支持范围。 ExaGear 6.0.0 正式版本于 2026 年 4 月 10 日发布，服务器架构为基于鲲鹏 920 的服务器，支持的 Guest Linux OS 包括 CentOS 7、CentOS Stream 8、CentOS Stream 9、Ubuntu 20.04、Ubuntu 22.04、openEuler 22.03 LTS。部署形态支持物理机与虚拟机；在虚拟机中安装时，虚拟机的 OS 类型需与 ExaGear 支持的 Guest OS 类型相同，且必须是 ARM 虚拟机。

　　　　适用范围需要结合应用形态判断。 Linux x86用户态应用是ExaGear服务器版的主要对象；存在ARM版本且接口协议一致的驱动或内核模块时，可先部署ARM版本组件，再迁移上层应用。Windows应用可借助Wine等兼容层转接运行，但商用场景需确认第三方软件支持和问题兜底能力。ExaGear for Server与ExaGear for Docker不部署在同一台机器上；部署前还应按当前版本文档核对Guest OS、虚拟地址长度等环境要求。

　　　　五、把三条路线接成一个流程

　　　　第一步，扫。 用软件迁移评估把待迁移软件包或已安装软件扫一遍，拿到架构相关文件清单和可兼容、待修改的分布。注意绑定目标操作系统，不同 OS 的报告会有差异。

　　　　第二步，分流。 可兼容的依赖走下载替换；待修改里能拿到 ARM 版本或源码的，走替换或自行编译；未开源、拿不到 ARM 版本的记下来，留给第四步。

　　　　第三步，重构。 如果是 RPM、DEB、JAR、EAR 格式且希望产出可分发的包，把软件包和上一步准备好的依赖文件一起提交重构。重构前先确认环境符合包类型对应的系统要求。

　　　　第四步，兜底。 第二步剩下的部分，以及整体无法拆解的裸二进制，走动态二进制翻译。这一步要做性能实测，把损耗数据落到自己的业务指标上。

　　　　第五步，验。 重构出的包部署到鲲鹏平台验证，功能与性能都要过。ExaGear 环境下的应用同样需要完整功能回归——翻译方案在指令与系统调用层面按标准规格转换，但业务层的验证不能省。

　　长期看，无源码迁移是过渡手段。性能敏感的核心业务如果后续能拿到源码，走源码迁移加亲和分析的路线，才能真正用上 ARM 架构的特性。

　　　　Q&A

　　　　问：X86 无源码应用迁移到 ARM 平台有哪几种方式？

　　答：主要有三种。第一种是依赖替换后原地运行，适用于架构相关依赖有限且能找到鲲鹏对应版本的情况；第二种是软件包重构，在满足主程序架构条件的前提下，替换RPM、DEB、JAR、EAR包中的架构相关依赖并重新封装；第三种是动态二进制翻译，运行时把x86指令翻译成ARM64指令，适用于前两条难以完成的用户态应用。性能代价与部署代价要分开看：替换和重构通常运行时开销更低，ExaGear则无需改代码、部署代价通常更低。鲲鹏DevKit应用迁移工具覆盖评估、依赖替换和软件包重构，ExaGear提供动态翻译能力。

　　　　问：软件包重构支持哪些格式，有什么环境要求？

　　答：当前支持 RPM、DEB、JAR、EAR 四种，单次上传一个软件包且不超过 1GB，依赖文件可多个、每个同样不超过 1GB。该功能只支持在鲲鹏平台环境上运行。RPM 包只能在类 RHEL 系统上执行，依赖 rpmrebuild、rpmbuild、rpm2cpio；DEB 包只能在类 Debian 系统上执行，依赖 ar、dpkg-deb；包内含 JAR 或 EAR 时需系统装有 jar 命令。另外，JAR 包如果已在鲲鹏 Maven 仓库中存在，工具会提示直接下载或配置仓库源使用，不需要重构。

　　　　问：无源码场景能不能用交叉编译？

　　答：不能。交叉编译的前提是有源码可以重新编译，无源码时这条路径不成立。可行的方向是依赖替换、软件包重构和运行时指令翻译。如果后续能从供应方拿到源码，再走源码迁移加亲和分析的路线，性能上会比翻译方案更好。

　　　　问：迁移完成后还需要做什么？

　　答：功能与性能验证都要做。重构出的软件包部署到鲲鹏平台后需完整验证；ExaGear 环境下运行的应用同样需要业务层功能回归。如果迁移过程中拿到了部分组件源码，可以跑一遍亲和分析，它提供 64 位运行模式检查、字节对齐检查、矩阵化检查、结构体变量 cacheline 对齐优化、内存一致性检查、构建亲和检查、计算精度对比分析和 SVE 向量化识别与转换八项能力，用于进一步适配鲲鹏架构特点。

　　　　问：ExaGear和QEMU有什么区别？

　　答：ExaGear是面向鲲鹏平台的商用级进程级动态二进制翻译工具，重点解决Linux x86用户态应用在ARM64服务器上的无源码迁移，并提供产品化支持。QEMU user-mode同样面向用户态程序，但属于开源仿真方案；QEMU system emulation则仿真CPU、内存和设备等完整机器环境，可运行完整Guest OS，属于系统级方案。三者不能只按“是否翻译指令”归为一类，应按迁移对象、支持方式和维护责任选择。

　　　　问：鲲鹏无源码迁移工具有哪些？

　　答：主要分为两类。一类是鲲鹏DevKit应用迁移工具，通过软件迁移评估识别架构相关依赖，并在条件满足时完成依赖替换和软件包重构，适合希望形成鲲鹏兼容包的场景；另一类是ExaGear动态二进制翻译工具，在不修改源码和原x86二进制的情况下运行用户态应用，适合难以重构或需要快速迁移的场景。实际项目可先评估和替换，剩余无法处理的用户态组件再用动态翻译补充。

　　　　参考来源

华为鲲鹏社区，《鲲鹏DevKit 应用迁移》产品页，https://www.hikunpeng.com/developer/devkit/application-porting

华为鲲鹏社区，《查看分析结果》，鲲鹏DevKit 25.1.0 应用迁移工具 WebUI用户指南，https://www.hikunpeng.com/document/detail/zh/kunpengdevkithistory/devkit_25_1_0/usermanual/DevKit_Porting_0008.html

华为鲲鹏社区，《软件包重构》，鲲鹏DevKit 24.RC3 插件用户指南，https://www.hikunpeng.com/document/detail/zh/kunpengdevkithistory/devkit_24_rc3/Plugins_UserGuide/DevKit_Porting_0014.html

华为鲲鹏社区，《FAQ》，动态二进制翻译用户指南，https://www.hikunpeng.com/document/detail/zh/kunpengdevkithistory/exagear/hist_ExaGear/kunpengexagear_06_0045.html

华为鲲鹏社区，《鲲鹏 DevKit 通过动态二进制翻译快速迁移无源码应用》，2023年9月22日，https://www.hikunpeng.com/developer/techArticles/20230922-1

华为鲲鹏社区，《华为动态二进制翻译工具（ExaGear）》下载页，6.0.0 正式版本，2026年4月10日，https://www.hikunpeng.com/developer/devkit/download/exagear

华为开发者论坛，《二进制指令翻译工具（ExaGear）功能介绍》，鲲鹏专区，https://developer.huawei.com/home/forum/kunpeng/thread-0208101477940174014-1-1.html