Rust cc-rs项目中的函数签名不匹配问题分析

背景介绍

在Rust与C语言交互开发中，cc-rs是一个常用的构建工具，它简化了Rust项目中调用C代码的过程。本文分析一个在wasm32-unknown-emscripten目标平台下出现的函数签名不匹配问题，这个问题在x86_64-unknown-linux-gnu平台上却能正常工作。

问题现象

开发者定义了一个Rust导出函数：

#[no_mangle]
pub extern "C" fn gidispatch_get_objrock_fileref(ptr: FileRefPtr) -> DispatchRockPtr {
    ...
}

对应的C语言声明为：

extern gidispatch_rock_t gidispatch_get_objrock_fileref(void *obj);

在x86_64平台下工作正常，但在wasm32-unknown-emscripten目标下出现错误：

wasm-ld: error: function signature mismatch: gidispatch_get_objrock_fileref
>>> defined as (i32, i32) -> void in ...
>>> defined as (i32) -> i32 in ...

根本原因分析

问题的核心在于C语言和Rust语言对返回类型的处理方式不同：

1. C语言中gidispatch_rock_t是一个联合体(union)类型
2. Rust中DispatchRockPtr是一个裸指针类型

虽然这两种类型在x86_64平台上具有相同的大小和对齐方式，但不同平台的ABI(应用二进制接口)对它们的处理方式不同：

• x86-64 Linux的C ABI恰好将这种联合体当作单个整数传递
• WebAssembly的C ABI只对"单例"联合体和结构体有特殊处理规则，而gidispatch_rock_t不属于这类情况，因此它被归入"间接"传递类别

这就是为什么在WebAssembly目标下，函数签名变成了(i32, i32) -> void，其中第二个参数实际上是用于返回值的指针。

解决方案

针对这类跨平台ABI差异问题，有以下几种解决方案：

1. 使用输出参数替代返回值： 修改函数设计，通过指针参数传递返回值，而不是直接返回。这是最可靠的跨平台解决方案。

2. 确保类型完全匹配： 在Rust端也使用完全相同的联合体类型定义，并确保使用#[repr(C)]属性。理论上这应该能解决问题，但在实际测试中可能还需要进一步调整。

3. 平台特定代码： 对于不同平台使用不同的函数签名，但这会增加代码维护成本。

经验总结

1. 在跨语言交互开发中，不能仅凭类型大小和对齐方式相同就认为它们ABI兼容
2. 不同平台对复合类型(结构体、联合体)的传递规则可能有显著差异
3. 输出参数方式通常是最可靠的跨平台解决方案
4. 在开发初期就应该在所有目标平台上进行测试，避免后期发现问题

这个问题提醒我们，在Rust与C交互开发中，特别是在多平台支持的情况下，必须仔细考虑每种类型的ABI处理方式，而不仅仅是关注内存布局。