Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

(import "hellowasi" "reverse" (func $reverse (type 4)))

@yowl Typically we would start with an issue with the API proposal. I will create that quickly and point to this PR. However, this PR will need a few things.

Instead of a new attribute, could you add a new CallingConvention.Wasm or CallingConvention.WasmImport that is used to identify a specific DllImport as one that's a wasm import? So instead of
[DllImport("foo_module", EntryPoint="bar"), WasmImport]
you would have
[DllImport("foo_module", EntryPoint="bar", CallingConvention=CallingConvention.Wasm)]

@kg Calling conventions are orthogonal to symbol resolution. For example, CallingConvention.WasmImport would not apply to function pointers and indirect calls.

@pavelsavara

Are there limits to what the wasm import could do ?

Should we support full set of existing DllImport features from day 1 ?
(maybe it's easier to add functionality across releases than remove it later)

What would be behavior of DllImport for call conventions ? Should we explicitly limit it to particular call convention?
(as compared to usual native function with a stack, registers, ... )
In particular we have 2 "stacks" one is the wasm import arguments and the other is the shadow stack of LLVM.
Is there some issue with passing structs on stack ?

Do we expect that the imported functions could malloc, free, stackAlloc or WASI cabi_realloc ?
(that probably also assumes we export those functions)

Should we support all string marshaling options ?

Are all unsupported scenarios compile time errors ?

Is this act of opening new ABI ?

@pavelsavara the attribute will not affect the ABI or calling convention (which both default to C interop, with marshalling, shadow stacks, arbitrary reentrancy, etc).

@pavelsavara the attribute will not affect the ABI or calling convention (which both default to C interop, with marshalling, shadow stacks, arbitrary reentrancy, etc).

C calling conventions are OS/CPU/compiler dependent behavior. From whatever consumes this wasm import it's "undefined" details unless they share the exact same compiler (and maybe compiler flags). Are we hand-waving it ?

I think we have this problem with incompatible behavior of different versions of emscripten between versions of dotnet already. The existing use-case is when we link static library into .wasm file. Hope I remember it correctly. @lewing ?

Are we hand-waving it ?

@pavelsavara No, "the C ABI" I was referring to is https://github.com/WebAssembly/tool-conventions/blob/main/BasicCABI.md. It is stable.

There are unstable variations (-mmulti-value) and aspects (v128 passing/returning) of it; I don't think these are important for us right now.

I think we have this problem with incompatible behavior of different versions of emscripten between versions of dotnet already. The existing use-case is when we link static library into .wasm file.

This is true, and the reason is that Emscripten has its own ABI conventions of top of C, and does not promise ABI compatibility. Static libraries are by their nature fragile too (though I don't know the precise extent of compatibility promised by LLVM; I believe that if you communicate using "plain C", it should be more or less stable).

All that said, ABI is a higher-level concern than this attribute, which is just about linkage.

Thanks!

@dotnet/interop-contrib or @dotnet/nativeaot-llvm Can I get another sign off?