WebAssembly ABI mismatch between clang and rust

When I compile this C code to wasm32-wasi:

typedef struct Vector {
    int a;
    int b;
} Vector;

extern int extract_a(Vector v) {
    return v.a;
}

And this Rust code to wasm32-wasi:

#[repr(C)]
struct Vector {
    a: i32,
    b: i32,
}

extern "C" {
    fn extract_a(v: Vector) -> i32;
}

fn main() {
    unsafe {
        extract_a(Vector { a: 5, b: 4 });
    }
}

And try link them together, I'm getting linking errors:

  = note: lld: error: function signature mismatch: extract_a
          >>> defined as (i32, i32) -> i32 in /home/pierre/Projets/wasm-abi-test/target/wasm32-wasi/debug/deps/wasm_abi_test.67xpw7l331r9o5x.rcgu.o
          >>> defined as (i32) -> i32 in /home/pierre/Projets/wasm-abi-test/target/wasm32-wasi/debug/build/wasm-abi-test-9c49ce7f6c5ca031/out/libfoo.a(test.o)

It seems that, according to clang, passing a struct by value should inline the fields, while for Rust it should be passed by pointer.

I uploaded an example project here: https://github.com/tomaka/wasm-abi-test
It can be built with something like:

AR_wasm32_wasi=/path/to/wasi-sdk-10.0/bin/ar CC_wasm32_wasi=/path/to/wasi-sdk-10.0/bin/clang cargo run --target=wasm32-wasi

Rust version: rustc 1.44.0-nightly (38114ff 2020-03-21)

Apparently this is a known issue:

Pass small structs in parameters instead of memory WebAssembly/tool-conventions#88 (comment)
Clang and Rustc use incompatible Wasm signatures for struct arguments passed by value WebAssembly/tool-conventions#130

This is mostly tracked at rustwasm/team#291 and would be fixed by #79998.

This should now work for wasm32-wasi (on current git head).

Note that #83763 changed the default, so only wasm32-unknown-unknown uses the mismatched ABI, all other wasm targets (including custom targets) now default to using the ABI that matches clang:

rust/compiler/rustc_target/src/spec/wasm32_unknown_unknown.rs

Lines 22 to 30 in 482a3d0

    
           // This is a default for backwards-compatibility with the original 
        
           // definition of this target oh-so-long-ago. Once the "wasm" ABI is 
        
           // stable and the wasm-bindgen project has switched to using it then there's 
        
           // no need for this and it can be removed. 
        
           // 
        
           // Currently this is the reason that this target's ABI is mismatched with 
        
           // clang's ABI. This means that, in the limit, you can't merge C and Rust 
        
           // code on this target due to this ABI mismatch. 
        
           options.default_adjusted_cabi = Some(Abi::Wasm);

There are discussions going on at wasm-bindgen to extend the support to wasm32-wasi in addition to the current wasm32-unknown-unknown.

In short, wasm-bindgen needs a consistent C ABI between wasm32-unknown-unknown and wasm32-wasi to support both of them.

Note that #83763 changed the default, so only wasm32-unknown-unknown uses the mismatched ABI, all other wasm targets (including custom targets) now default to using the ABI that matches clang:

rust/compiler/rustc_target/src/spec/wasm32_unknown_unknown.rs

Lines 22 to 30 in 482a3d0

// This is a default for backwards-compatibility with the original

// definition of this target oh-so-long-ago. Once the "wasm" ABI is

// stable and the wasm-bindgen project has switched to using it then there's

// no need for this and it can be removed.

//

// Currently this is the reason that this target's ABI is mismatched with

// clang's ABI. This means that, in the limit, you can't merge C and Rust

// code on this target due to this ABI mismatch.

options.default_adjusted_cabi = Some(Abi::Wasm);

Can we have ABI that matches clang on wasm32-unknown-unknown as well? I can help with this, but would it be a hard task?

The change itself would be removing options.default_adjusted_cabi = Some(Abi::Wasm) from the target spec and that's it. Because it breaks older wasm-bindgen versions it will probably require waiting months to years before we can actually make this change. And preferably we would introduce a future compat warning for this change. Either against older wasm-bindgen versions or against any extern "C" function for which changing the abi actually has any effect.

I don't see why breaking older versions wasm-bindgen is a blocker when there can be a compatibility warning and it'll take over 12 weeks until stable if the change were to be merged today. Updating wasm-bindgen is as simple as just running cargo update -p wasm-bindgen, we can tell users to run it. wasm-bindgen is also semver 0.x so it makes no stability guarantees

It is unfortunate that we have to break code (that we never promised stability for) but the longer we wait, the worse the problem gets.

I think so too, since the users don't need to refactor their code, this change doesn't need to be warned and waited.

We need to warn because it will breal everyone who uses an older wasm-bindgen version. We have done plenty of warnings and sometimes even crate version specific workaround in the past to avoid breakage even after a fixed crate version exists.

We need to warn because it will breal everyone who uses an older wasm-bindgen version.

May I ask you what things would be broken and users should be aware of?

The reason this discussion started was basically major modules in std are not working in wasm32-unknown-unknown, making various crates be divided into wasm and non-wasm versions. Fixing this fragmentation in Rust ecosystem as soon as possible would be good, in my opinion. Maybe we can use a version-specific workaround as you mentioned.

One thing I'm concerned about is that this issue is being solved too slow. It's older than 3 years. I believe we need some momentum for this issue, or it will just be left unsolved even after 2026 or so..

Unrolled build for rust-lang#117918

Require wasm-bindgen >=0.2.88 to work around rust-lang/rust/issues/71871

upgrade `wasm-bindgen` to 0.2.92 (#5056)

Rollup merge of rust-lang#133952 - bjorn3:remove_wasm_legacy_abi, r=a…

Unrolled build for #133952

Rollup merge of rust-lang#133952 - bjorn3:remove_wasm_legacy_abi, r=a…

Rollup merge of #133952 - bjorn3:remove_wasm_legacy_abi, r=alexcrichton

Navigation Menu

Repository navigation

WebAssembly ABI mismatch between clang and rust #71871

28 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	// This is a default for backwards-compatibility with the original
	// definition of this target oh-so-long-ago. Once the "wasm" ABI is
	// stable and the wasm-bindgen project has switched to using it then there's
	// no need for this and it can be removed.
	//
	// Currently this is the reason that this target's ABI is mismatched with
	// clang's ABI. This means that, in the limit, you can't merge C and Rust
	// code on this target due to this ABI mismatch.
	options.default_adjusted_cabi = Some(Abi::Wasm);

WebAssembly ABI mismatch between clang and rust #71871

Description

Activity

tomaka commented on May 4, 2020

TheBlueMatt commented on Jan 9, 2021

TheBlueMatt commented on Jan 12, 2021

programmerjake commented on Aug 28, 2022

temeddix commented on Oct 26, 2023

bjorn3 commented on Oct 26, 2023

ranile commented on Oct 26, 2023

temeddix commented on Oct 26, 2023

bjorn3 commented on Oct 26, 2023

temeddix commented on Oct 26, 2023

28 remaining items

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions