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

问题背景

在使用Rust的cc-rs项目构建跨平台C/Rust互操作时，开发者遇到了一个有趣的函数签名不匹配问题。具体表现为：当目标平台为wasm32-unknown-emscripten时，一个从C调用的Rust导出函数出现了签名不匹配的错误，而在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);

gidispatch_rock_t gidispatch_get_objrock(void *obj, glui32 objclass) {
    switch (objclass) {
        case gidisp_Class_Fileref:
            return gidispatch_get_objrock_fileref(obj);
    }
}

在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(应用二进制接口)层面，标量类型和聚合类型通常不能互换使用。

ABI差异

不同平台的ABI对参数传递有不同规则：

1. x86_64 Linux ABI：将小型简单聚合类型当作标量处理，因此gidispatch_rock_t被当作单个整数传递
2. WebAssembly C ABI：仅对"单例"(singleton)联合体和结构体有特殊处理，而gidispatch_rock_t不属于此类，因此采用"间接"传递方式

这就是为什么在wasm目标下，函数签名变成了(i32, i32) -> void（第一个参数是输入，第二个参数是返回值的指针），而Rust端仍然是(i32) -> i32。

解决方案

开发者尝试了两种解决方案：

1. 使用联合体类型：将Rust端的DispatchRockPtr改为与C端匹配的联合体类型。理论上，使用repr(C)的联合体应该是ABI兼容的，但实际测试中这种方法未能解决问题。

2. 使用输出参数：改为通过指针参数返回结果，这种方式最终被证实有效。修改后的函数签名类似于：

   #[no_mangle]
   pub extern "C" fn gidispatch_get_objrock_fileref(ptr: FileRefPtr, out: *mut DispatchRockPtr) {
       *out = ...;
   }
   

经验总结

1. 跨语言调用时，类型定义必须严格匹配，包括结构体/联合体与指针的差异
2. 不同平台的ABI规则可能导致看似相同的代码表现不同
3. 输出参数(out parameter)是解决复杂类型跨语言传递的可靠方案
4. 测试时应该覆盖所有目标平台，不能依赖单一平台的"幸运"工作

这个问题虽然出现在cc-rs项目的上下文中，但实际上是一个跨语言调用和平台ABI差异的典型案例，值得所有进行跨平台开发的工程师注意。