[NativeAOT-LLVM] Output non component

[cyraid]

Hey there! Is it possible to generate a non component wasm file? One that would be runnable with wasmtime (for .net) in it's current state? (Wasmtime cli can, but the dotnet can't do components yet)

Looking to export a few static functions for now until components are more ready in wasmtime dotnet.

What would be nice is if I could embed wasmtime and expose some API and run some .net sandboxed plugins.

[yowl]

You can't really do a non component wasi library. You can force the compiler to create one, and if it doesn't use any WASI imports then it may work. You can also do components which is supported, as much as anything here is supported, using wit-bindgen. We don't support the p3 things like async or streams yet. Have you tried wit-bindgen?

[cyraid]

Can wit-bindgen generate export methods from my c# API for the embedded wasmtime to import and run? I thought it took a .wit file and generated c#?

The goal is having methods from a class decorated with wasmexport attributes of some sort and be able to import them in a dotnet wasmtime embedded environment and execute them as plugins.

Componentize looks like it does some of this but it generates a component file instead of a "flat file" (for lack of words).

And while I like that it generates a component, support in wasmtime dotnet just isn't there yet.

[SingleAccretion]

Hi @cyraid, as Yowl said above, we can't produce a non-component WASI library currently because of upstream limitations (there is no native target for modules with WASIp2 ABI yet). The best you can currently do is to build the component and then extract a module out of it via:

wasm-tools component unbundle <component path> --module-dir <modules directory> > $null

It will have a mix of WASIp1 and WASIp2 imports, like so:

Import[33]:
 - func[0] sig=6 <__imported_wasi_snapshot_preview1_args_get> <- wasi_snapshot_preview1.args_get
 - func[1] sig=6 <__imported_wasi_snapshot_preview1_args_sizes_get> <- wasi_snapshot_preview1.args_sizes_get
 - func[2] sig=6 <__imported_wasi_snapshot_preview1_environ_get> <- wasi_snapshot_preview1.environ_get
...

You can then stub out these __wasm_import* methods in C code that you can link into the resulting binary with NativeLibrary (the methods are declared in wasi-libc, e. g. https://github.com/WebAssembly/wasi-libc/blob/08799da37ae52955427ebec1336b49d6a8eb5051/libc-bottom-half/sources/__wasilibc_real.c#L16):

> clang -O2 -c wasi_stubs.c -o wasi_stubs.o
> <NativeLibrary Include="wasi_stubs.o" />

Or provide them in the host (also as stubs since again there is no "WASIp2 module" ABI).

Some references:

1. [NativeAOT-LLVM] Add a property to build Wasm core modules for library project types #3126.
2. Wasmtime C API for components (which wasmtime-dotnet needs to implement them): Expose component model in C api bytecodealliance/wasmtime#9812.
3. "WASIp2 module": Add BuildTargets.md WebAssembly/component-model#378.

[GerardSmit]

One that would be runnable with wasmtime (for .net)

I've done this in the following repository: https://github.com/GerardSmit/DnnWasmModules

It's hacky and I was just messing around. It's probs better to follow the steps that @SingleAccretion provided.

In the guest/WASM file added -s STANDALONE_WASM in the "guest":
https://github.com/GerardSmit/DnnWasmModules/blob/main/src/WasmModule/WasmModule.csproj#L17

Then in host, I defined dummy implementations of all the functions that are needed from NativeAOT-LLVM:
https://github.com/GerardSmit/DnnWasmModules/blob/main/src/WasmHost/WasmControl.cs#L49

I still added linker.DefineWasi(), I'm not sure if this was needed for something...

[cyraid]

@SingleAccretion I did what you suggested, and I was getting crashes after defining the stubs (out of memory error?).

@GerardSmit I saw what you did in your github, got Emscripten, and added:

<PublishProfile>FolderProfile</PublishProfile>
<MSBuildEnableWorkloadResolver>false</MSBuildEnableWorkloadResolver>

The linking stage kept hanging, and maybe it was timing or dumb luck, but I applied one of the things from previous tries, the disabling of the workload resolver, and lo-and-behold, it linked!

After defining:

    linker.Define("env", "RhpGetBiasedWasmFunctionIndexForFunctionPointer", Function.FromCallback(store, (Caller caller, double address) => 0));
    linker.Define("env", "mono_wasm_browser_entropy", Function.FromCallback(store, (Caller caller, int a, int b) => 0));
    linker.Define("env", "RhpGetCurrentBrowserThreadStackTrace", Function.FromCallback(store, (Caller caller, int a, double b, int c) => 0));
    linker.Define("env", "emscripten_notify_memory_growth", Function.FromCallback(store, (Caller caller, int a) => { }));

And having:

using System.Runtime.InteropServices;

public static class Program {

  [UnmanagedCallersOnly(EntryPoint = "run")]
  public static int Run() {
    return 42;
  } // Function //

} // Class //

I do indeed have a working wasm which wasmtime dotnet can run, using browser-wasm. The resulting .wasm is also smaller.

@SingleAccretion Perhaps at some point I may investigate the wasi approach more if I need to.

[SingleAccretion]

I did what you suggested, and I was getting crashes after defining the stubs (out of memory error?).

It's not totally unexpected that something wouldn't work, but it still needs to be fixed. Let's use this issue as a tracking one for creating a sample that'd do something like what I outlined above.

[cyraid]

Hi @SingleAccretion , I went a bit on the rabbit hole again of wasi-wasm. Originally I used OutputType exe and tried _start, but this time I'm doing OutputType Library and using Run (an exported method). I did manage to get it to work with a super basic test and putting in the stubs, but my problem comes from trying to import a method into the wasm module.

//========[[ Imports ]]=======================================================//

using System.Runtime.InteropServices;

//****************************************************************************//
//========[[ Program Class
//****************************************************************************//

public static class Program {

  //========[[ Public Class Methods ]]========================================//

  [UnmanagedCallersOnly(EntryPoint = "run")]
  public static int Run() {

    var str = "Hello World!";

    Test(GetStringAddress(ref str), str.Length);

    return str.Length;

  } // Function //

  //========[[ Private Class Methods ]]=======================================//

  [WasmImportLinkage]
  [DllImport("main", EntryPoint = "test")]
  private static extern void Test(int address, int length);

  private static int GetStringAddress(ref string str) {
    unsafe {
      fixed (char* addr = str) {
        return (int)addr;
      } // Fixed //
    } // Unsafe //
  } // Function //

} // Class //

When I build the .wasm using this for browser-wasm, it works when I call _initialize and main::run (defining the host function). But with wasi-wasm, linking with WasmImportLinkage is a problem, because the linker expects main::test to be present.

Caused by:
1>    0: failed to decode world from module
1>    1: module was not valid
1>    2: failed to resolve import `main::test`
1>    3: module requires an import interface named `main`

I'm probably doing something wrong for importing at this point. Any ideas? @SingleAccretion

If I don't include WasmImportLinkage, I try to run main::run and I get:

Unhandled exception. Wasmtime.TrapException: error while executing at wasm backtrace:
    0:  0x9d5e1 - <unknown>!<wasm function 2415>
    1:  0x375f1 - <unknown>!<wasm function 696>
    2:  0x642e9 - <unknown>!<wasm function 1561>
    3:  0x58032 - <unknown>!<wasm function 1378>
    4:  0x4b0b3 - <unknown>!<wasm function 1187>
    5:  0x5ccd7 - <unknown>!<wasm function 1471>
    6:  0x946d0 - <unknown>!<wasm function 2272>
    7:  0x6b745 - <unknown>!<wasm function 1665>
    8:  0x50c6e - <unknown>!<wasm function 1283>
    9:  0x61e38 - <unknown>!<wasm function 1532>
   10:  0x395d0 - <unknown>!<wasm function 894>
   11:  0x5cc86 - <unknown>!<wasm function 1470>

Caused by:
    wasm trap: wasm `unreachable` instruction executed
   at Wasmtime.NonTupleTypeFactory`1.Create(StoreContext storeContext, Store store, IntPtr trap, Span`1 values)
   at Wasmtime.Function.InvokeWithReturn[TR](Span`1 argsAndResults, IReturnTypeFactory`1 factory, StoreContext storeContext)
   at Wasmtime.Function.<>c__DisplayClass188_0`1.<WrapFunc>b__0()
   at Console.Desktop.Program.Main(String[] args) in D:\Projects\Pulse\Console\Console.Desktop\Program.cs:line 108

[SingleAccretion]

I'm probably doing something wrong for importing at this point. Any ideas?

Another problem with this workaround is that you still need WIT to describe your import (and export) set. I. e. you need to pass:

; example.wit
package library:library;

world library {
    import main: interface {
        test: func(a: u32, b: u32);
    }
}

; .csproj
<WasmComponentTypeWit Include="example.wit" />

Originally I used OutputType exe and tried _start, but this time I'm doing OutputType Library and using Run (an exported method).

That's the correct approach. An OutputType == exe-type binary doesn't support exports other than main/run (it initializes the runtime in main).

[cyraid]

@SingleAccretion Yup, adding the WIT interface works with WasmImportLinkage now for wasi-wasm. The browser-wasm approach needs a few less steps to unpack the modules first and not needing to run an extra command and not needing a wit file. I did setup my project to use a property flag to enable both.

And I'm relying on faith that unbundled-module0.wasm is the one I need out of how many that would come out (currently 2).

I'll probably end up going toward the browser-wasm (with emscripten) for the short term until wasmtime dotnet catches up with component support.

Thank you @GerardSmit and @SingleAccretion for the help!