如何保障AArch64与Arm32间共享内存中C/C++结构体的兼容性

核心结论 #

遵循Arm官方的C ABI（Arm32用AAPCS，AArch64用AAPCS64），即可保证结构体仅添加满足对齐要求的最小填充，且POD结构体在两个平台的内存布局完全一致，可直接通过共享内存传递。

Arm ABI的布局规则确认 #

Arm的AAPCS（32位）和AAPCS64（64位）对POD结构体的布局有明确且严格的规定：

• 结构体成员严格按声明顺序排列
• 成员之间仅插入满足下一个成员对齐要求的最小填充字节，无额外的编译器自由填充
• 结构体整体的对齐值等于其成员中对齐要求最严格的那个的对齐值
• 结构体总大小会被调整为其对齐值的整数倍（仅为满足整体对齐的最小填充）

只要两个平台的编译器都遵循对应的Arm ABI，结构体的填充位置和数量就完全确定。

跨平台传递的可行性 #

只要满足以下前提，AArch64和Arm32的程序可直接通过共享内存传递结构体：

• 仅使用POD类型定义结构体：排除非平凡构造/析构函数、虚函数、引用成员等，确保遵循C ABI规则（非POD类型的C++ ABI在两个平台可能存在差异）
• 基础类型的大小和对齐一致：如你所述，int、float、double等标准类型在Arm32和AArch64的大小、对齐均相同（int=32位，float=32位，double=64位，对齐值等于自身大小）

最优实现步骤 #

1. 定义POD结构体 #

仅使用标准基础类型或其他POD类型，避免非POD特性：

// 符合要求的POD结构体示例
struct SharedMessage {
    uint32_t id;
    float temperature;
    int64_t timestamp;
};

2. 显式指定对齐（可选但更严谨） #

用__attribute__((aligned(N)))显式指定结构体的对齐值（N为最严格成员的对齐值，比如上述示例中int64_t对齐为8，所以N=8），避免编译器的非标准扩展：

struct __attribute__((aligned(8))) SharedMessage {
    uint32_t id;
    float temperature;
    int64_t timestamp;
};

3. 禁用破坏ABI的编译选项 #

确保编译时不使用-fpack-struct、#pragma packed或__attribute__((packed))这类破坏对齐和布局的选项，保留ABI规定的最小填充。

4. 编译期验证布局 #

用static_assert检查结构体的大小和成员偏移，确保两个平台的编译结果一致：

#include <cstddef>
#include <cstdint>

struct __attribute__((aligned(8))) SharedMessage {
    uint32_t id;
    float temperature;
    int64_t timestamp;
};

// 编译期断言，验证大小和偏移符合ABI预期
static_assert(sizeof(SharedMessage) == 16, "SharedMessage size mismatch across platforms");
static_assert(offsetof(SharedMessage, temperature) == 4, "Temperature offset mismatch");
static_assert(offsetof(SharedMessage, timestamp) == 8, "Timestamp offset mismatch");

5. 确保编译器遵循Arm ABI #

编译时指定正确的目标架构（如Arm32用-march=armv7-a，AArch64用-march=armv8-a），GCC/Clang默认会针对目标架构使用对应的ABI，无需额外参数。

为什么不推荐#pragma packed？ #

如你所述，packed属性会强制取消填充，带来以下问题：

• 成员未对齐时，创建指针或引用属于未定义行为，编译器会抛出警告
• 访问未对齐成员需要额外的指令处理，降低性能
• 新增成员时，容易破坏后续成员的位置，导致布局意外变更

而遵循Arm ABI的方式既保证了布局的确定性，又保留了正确的对齐，完全避免这些问题。

对比Rust的#[repr(C)] #

Rust的#[repr(C)]本质是强制结构体遵循目标平台的C ABI布局，和我们在C/C中遵循Arm ABI的效果完全一致——只是Rust用语法明确标注，而C/C通过遵循ABI规范来实现。

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