Compiler Explorer中ARM架构执行器故障分析与修复

Compiler Explorer作为一款流行的在线编译器工具，近期出现了一个影响ARM架构编译后代码执行的严重问题。本文将深入分析该故障的技术细节、根本原因以及解决方案。

问题现象

当用户使用ARM架构的编译器（如ARM64 GCC 14.2.0或ARMV8-A Clang 20.1.0）编译代码后尝试执行时，系统会返回错误代码127，并显示"failed to run command 'output.s': No such file or directory"的错误信息。值得注意的是，这一问题在几周前并不存在，属于近期引入的回归性错误。

技术分析

错误代码127在Unix/Linux系统中通常表示"command not found"，结合错误信息中提到的"output.s"文件缺失，可以初步判断问题出在执行环节的文件路径处理上。

通过深入研究Compiler Explorer的架构，我们发现其执行流程通常包含以下步骤：

1. 源代码编译生成可执行文件
2. 将可执行文件部署到执行环境
3. 通过特定接口调用执行

在ARM架构下，系统错误地尝试执行中间汇编文件(output.s)而非最终生成的可执行文件，这表明编译流程虽然成功完成，但后续的文件处理环节出现了逻辑错误。

根本原因

经过代码审查，我们发现问题的根本原因在于：

1. 近期对多架构支持的代码重构中，ARM执行路径的文件命名逻辑出现了偏差
2. 系统错误地将中间汇编文件而非最终二进制文件传递给了执行器
3. 路径解析逻辑在ARM架构下未能正确处理文件扩展名

解决方案

项目维护者迅速响应并修复了该问题，主要修改包括：

1. 修正ARM架构下的文件路径生成逻辑
2. 确保执行器接收正确的可执行文件路径
3. 增加跨架构的文件处理单元测试

经验教训

这一事件提醒我们：

1. 跨架构支持需要特别谨慎，即使是看似简单的文件处理逻辑
2. 回归测试对于多架构项目至关重要
3. 错误代码127是一个重要的诊断线索，表明命令执行环境存在问题

结论

Compiler Explorer团队快速响应并修复了ARM架构执行器故障，展现了良好的项目维护能力。这一事件也凸显了在线编译工具在支持多架构时面临的挑战，以及健全的自动化测试体系的重要性。对于开发者而言，理解这类问题的诊断思路也有助于在自己的项目中快速定位类似问题。