ARMv8同一进程内混合Aarch32与Aarch64用户态二进制可行性问询

你的方案可行性分析 #

你提出的同一进程内通过系统调用切换EL0执行状态的方案不可行，核心原因如下：

• ARMv8的EL0执行状态（Aarch32/Aarch64）由异常返回时的SPSR_EL1寄存器M字段决定，但单个进程的用户态上下文是统一绑定的：当从Aarch32 EL0进入内核，内核仅保存32位寄存器组（r0-r12、lr、sp等）；若强行切换到Aarch64 EL0返回，原32位上下文会直接丢失，且64位寄存器无有效初始化，必然导致进程崩溃。
• 标准Linux内核中，进程的执行状态由personality属性和内存布局全局锁定，不允许单个进程在EL0随意切换状态——内核仅维护对应状态的用户态上下文，跨状态返回会破坏进程一致性，触发内核错误。
• 你设想的内核设置Aarch64栈和LR的操作，无法解决寄存器集不兼容的本质问题：32位与64位用户态寄存器完全独立，内核无法在一次系统调用中完成两套上下文的无缝切换与保存。

64位ARM内核下的可行协同方案 #

若要实现32位与64位代码的协同工作，可采用以下方式：

• 跨进程协作+共享内存：将32位和64位代码拆分到两个独立进程中，通过共享内存传递数据，使用管道、Unix域套接字或信号同步执行。这种方式模拟了“同一进程内”的协作逻辑，且符合内核规则——32位进程在COMPAT模式下运行，64位进程以原生模式运行，两者通过IPC机制交互。
• 封装为独立服务进程：将64位功能封装为守护进程，32位进程通过标准IPC（如套接字）发起功能请求。这种方式适合功能解耦的场景，无需考虑执行状态冲突。
• 动态二进制翻译：使用qemu-user或自定义翻译层，将32位代码动态翻译为64位代码（或反之），在同一64位进程内执行翻译后的代码。但该方式会带来一定性能开销，适合对性能要求不高的场景。

内容的提问来源于stack exchange，提问作者pcp