C FFI functions have incorrect signatures in wasm bundle when targeting wasm32-unknown-unknown

[lopopolo]

We have a crate called mruby-sys which uses the cc crate to build a C static library. Building this library fails to link when building the wasm32-unknown-unknown target due to function signature mismatches. When using the same build process for the C code with clang-8, the code links and is runnable in node via its WebAssembly infrastructure. This code links and runs correctly when targeting x86_64-apple-darwin and x86_64-unknown-linux-gnu.

Our full investigation: artichoke/artichoke#172 (comment).

The function that fails to link has the following prototype in ext.h:

MRB_API struct RClass *mrb_sys_class_of_value(struct mrb_state *mrb,
                                              mrb_value value);

mrb_value is a struct with the following definition:

typedef struct mrb_value {
  union {
    mrb_float f;
    void *p;
    mrb_int i;
    mrb_sym sym;
  } value;
  enum mrb_vtype tt;
} mrb_value;

mrb_sys_class_of_value has the following signature when compiling the C lib standalone:

(export "mrb_sys_class_of_value" (func 758))
(func (;758;) (type 16) (param i32 i32) (result i32)

the Rust compiled version has this signature:

(import "env" "mrb_sys_class_of_value" (func $mrb_sys_class_of_value (type 10)))
(type (;10;) (func (param i32 i64 i32 i32) (result i32)))

and results in this linker error:

  = note: rust-lld: error: function signature mismatch: mrb_sys_class_of_value
          >>> defined as (i32, i64, i32, i32) -> i32 in /app/target/wasm32-unknown-unknown/debug/build/mruby-sys-7c7d5344d44d1927/out/libmrubysys.a(ext.o)
          >>> defined as (i32, i32) -> i32 in lto.tmp

with this rustc:

artichoke@4e306af112ad:/app$ rustc --version --verbose
rustc 1.39.0-nightly (f7af19c27 2019-08-15)
binary: rustc
commit-hash: f7af19c279b8b7ea3d2c21fcbd67164af8d5d968
commit-date: 2019-08-15
host: x86_64-unknown-linux-gnu
release: 1.39.0-nightly
LLVM version: 9.0

I'm not sure what is going on here, or if the bug is in cc, bindgen, rustc, or rust-lld. Any ideas on what is going on?

[alexcrichton]

A bit late to this, but note that wasm32-unknown-unknown hasn't been vetted for interop with the C/clang. The ABI definition file for wasm is extremely bare bones and I suspect clang is matching more what the emscripten ABI looks like.

I think it's probably fine to update the wasm ABI to basically match the default ABI of clang

[lopopolo]

@alexcrichton did this ABI update make it in with @tlively's emscripten PR?

[alexcrichton]

The PR was landed with a compat layer for wasm-bindgen, since unfortunately the ABI change here actually breaks wasm-bindgen and we couldn't land it just yet.

The current plans are to wait for multi-value and migrate to the next version of the ABI, where clang/rustc will agree. This is tracked at WebAssembly/tool-conventions#88.

[alexcrichton]

I'm going to close this because we are unlikely to change this in the near future to avoid breaking existing code, and further changes can be tracked at WebAssembly/tool-conventions#88