Should there be an `extern "wasm"` ABI?

[fitzgen]

It would make compile-time errors if you tried to pass something that can't be passed across FFI boundaries in wasm, but can in C, such as structs.

Maybe this already exists and I'm ignorant of it?

Anyways, if feels weird to expose wasm APIs with extern "C".

[pepyakin]

I see why are you stating that structs can't pass accross FFI boundaries: wasm can't hold any values other than i32, i64, f32, f64.
However, "real" architectures usually can't either: on these architectures compiler should split structures between registers or spill into the memory.
So, I don't think that "wasm" is a another ABI.

[fitzgen]

Other ABIs have defined rules for how to split structs up, and how their parts cross the boundary. Both sides of FFI can agree on how to split up and paste back together structs.

AIUI, wasm does not have any such rules, and so you cannot pass structs across the boundary because there is no guarantees that both sides will agree on what is being passed and how. For wasm, it would be incorrect for the compiler to allow structs to be used in FFI.

[pepyakin]

Interesting, I thought contrary to that (at least, in cases where on both sides code is produced by LLVM).

[alexcrichton]

An interesting question! Makes me wonder a bit more in general about ABI implications in Rust right now.

At the base leve @pepyakin's right, we can only deal with some integers/floats, but another aspect we're not exposing today is the "two level import" where you import from a module and then an item in that module.

That leads me to two questions:

• How do we expose the "two level import" mechanism? Do we want to do this at the language level? Do we want to do this via attributes? A postprocessing for Rust? Note that all extern imports are implicitly lumped into an env module, but I wouldn't want that to be the case forever.

• What types do we want to allow in imports? Only wasm allowed types? All types and let LLVM figure it out? Wasm, unlike other platforms like x86, (AFAIK) doesn't have a "stable ABI" so when we pass a struct Foo around there's no guarantee it's the same as what anyone else does. In that sense I might be inclined to take a very conservative stance for now and restrict imports to just the wasm types until there's a stable ABI that LLVM is implementing.

There's also the question of ABI strings ("wasm" and "C") and I'm somewhat tempted to forbid "C" and require "wasm" on the wasm target...

[fitzgen]

See also rust-lang/rust#47599

[fitzgen]

What types do we want to allow in imports? Only wasm allowed types? ... I might be inclined to take a very conservative stance for now and restrict imports to just the wasm types until there's a stable ABI that LLVM is implementing.

This is what I'd expect.

[pepyakin]

But what if I would like to actually link to a C code?
Everywhere I would use extern "C", but when I would compile to rust I should use extern "wasm"?

[alexcrichton]

@pepyakin that's true but I also personally have no model for what that even means. Today wasm (in rust at least) has no compilation units, but linking to C code implies some degree of compilation units. In that sense it's difficult to envision what's happening here...

One perhaps reasonable way to rationalize this could be:

• Once we have compilation units, it sounds like they may not be tied to the wasm format. Maybe a stable C ABI will start to emerge? In the meantime LLVM may be the only compiler so we could be good. Perhaps at this point we could say that compilation units communicate over extern "C".
• We would then say that extern "wasm" is how you actually import functions from the wasm file itself. These imports cannot be resolved by other compilation units.

That I imagine would help solve communicating with C (assuming everythign works out, again that doesn't really exist yet!) while also being clear about what you're importing from the environment.

Perhaps then...

#[module = "foo"] // required for `extern "wasm"`
extern "wasm" {
    fn bar() -> i32; // imported from module "foo"

    // fn baz() -> i8; // illegal
}

extern "C" {
    fn another(); // generates a link error if unresolved and final `.wasm` file is created
}

[sunfishcode]

Yes; we are expecting a stable C ABI to emerge for wasm eventually. In fact, most of the C ABI details in clang are pretty stable already.

The one upcoming C ABI change that is I know of is that when wasm gets multiple return values, clang will likely switch to passing and returning "small-ish" structs by value (rather than byval/sret in LLVM). After that, it's likely that wasm's C ABI will be stable.

[pepyakin]

Sounds reasonable!
Also, we shouldn't forget about exports side (approach described by you should work with them well).

Once we have compilation units, it sounds like they may not be tied to the wasm format. Maybe a stable C ABI will start to emerge? In the meantime LLVM may be the only compiler so we could be good. Perhaps at this point we could say that compilation units communicate over extern "C".

There is some demand for linking against bare wast files (e.g. produced by wat2wasm), and I don't know if it is will be supported by LLD. But I guess it should.

[alexcrichton]

@sunfishcode ah while you're here, do you know if there's an idea of how to specify wasm imports from C? (imports that get hooked into the ES module system, that is)

[est31]

If there is we could see this as an opportunity to remove the requirement on the #[no_mangle] tag: rust-lang/rust#46294

[sunfishcode]

@alexcrichton Yeah, there are ongoing discussions. The rough theory is:

• env is what you get by default if you don't specify an import module. Symbols in env are either resolved at link time, or the linker determines the library that will satisfy them and substitutes it (two-level namespacing). No env symbols remain after linking.
• rename env to something less likely to collide with user names
• add a wasm-specific attribute, which for C/C++ might look like __attribute__((import_module("foo"))), for specifying an explicit module name. Functions only, for now. These names would be left untouched by the linker.

[alexcrichton]

@sunfishcode ok cool, thanks!

That actually aligns pretty well with what I had in mind already, and should work perfectly for us!