[NativeAOT-LLVM] Add support for controlling the import name used for PInvokes.

[yowl]

This PR allows the module name used for WebAssembly imports to be controlled. It follows #1390.

Using these changes it's possible to add

<ItemGroup>
	<WasmImport Include="wasi_snapshot_preview1!random_get" />
</ItemGroup>

to the project file and have the final WebAssembly WAT look like:

 (import "wasi_snapshot_preview1" "random_get" (func $random_get (type 3)))

This will allow WASI functions to be used in user code and will facilitate module linking, e.g. for wit-bindgen.

I realise that mono may put forward an alternative proposal that will take precedence at which point this will have to be redone.

[MichalStrehovsky]

Does WASI support dlopen/dlsym? Just wondering whether we should just reuse the directpinvoke mechanism instead of building an alternative on the side. If dlopen/dlsym doesn't exist, we could make directpinvoke mean something else on WASM.

[yowl]

Yes, Wasm has the module linking proposal which covers dynamic loading of other modules (I think the term is going be adapter modules) Its in flux as you can see from work the ByteCode Alliance are currently doing bytecodealliance/wasm-tools#450. Ive not read the proposal in detail but the structure looks a little more complex that just importing some symbols from another module, there is a concept of nesting and what they call link time virtualization (https://github.com/WebAssembly/module-linking/blob/main/design/proposals/module-linking/Explainer.md#link-time-virtualization) for example:

(adapter module
  (module $A
    (func (export "answer") (result i32) (i32.const 42))
  )
  (module $B
    (func (import "the" "answer") (result i32))
  )
  (instance $a (instantiate $A))
  (instance $b (instantiate $B (import "the" (instance $a))))
)

I'm happy to reuse the directpinvoke configuration here though, and can revisit as necessary when the module linking proposal firms up. I didn't use it initialliy as it seemed to be about the code generation and thought I might be abusing the intention.

Wasi SDK also implements dlopen in it's libc, but I think that predates the changes for the module linking proposal, so not sure how much effort should be spent on that as it's changing.

[yowl]

So in short, I can reuse the directpinvoke configuration, no problem.. Want me to change it?

[MichalStrehovsky]

So in short, I can reuse the directpinvoke configuration, no problem.. Want me to change it?

If WASM is going to have a working dlopen, we'll need a mechanism for deciding whether to generate a WASM import or use dlopen/dlsym, and that's what directpinvoke is for. Let's not overload it then.

I think eventually it would be nice if we could use the name of the DllImport, but that's something Mono will do their own way and then we'll need to adapt here I guess.

It's sad that WASM has this extra attribute and it doesn't work the way it works elsewhere (the decision on how to resolve symbols is determined at linking time, not at compile time).