How to determine module name?

[posutsai]

I try to use preload option to load a function out of the main module and it keeps showing this error message.

error while processing main module my_main_module.wasm: Instantiation error: Link error:env/foo: no provided import function

How to know runtime the exported wasm file's module name?

[posutsai]

Looks like wasmtime doesn't distinguish each module as different names. In handle_module function it passes None to instantiate_module no matter what the preloaded file name is. I think it would be better if wasmtime could name each module to satisfy this kind of need.
Anyway, my target function seems to be linkable through symbol after I manually name my preloaded function. However, I wonder does wasmtime support decode an exported function? It keeps throwing out an error message.

!!! no export named __wasi_memory, or the export isn't a mem: None

[sunfishcode]

There are some open design questions concerning the naming of modules, such as this.

The "!!! no export named __wasi_memory, or the export isn't a mem: None" error message is admittedly confusing. It would say "memory" instead of "__wasi_memory". I've now opened #264 to fix that. That said, what this error message means is that if you're using WASI, you're currently required to have a memory export named "memory", because many WASI functions expect to be able to access it. That's independent of any other exports you have.

[posutsai]

I have read the discussion in the proposal. Looks like this feature haven't been standardized yet. Is there anything that still calls for participation? It would be wonderful if I can contribute even a little thing.

I would like to know if you have any helpful suggestion to help me find out any alternative way to achieve my goal. Here's what I plan to do.

Briefly, I want to implement a tool to do the interposition-like job on Linux dynamic linking for either debugging or profiling. Let's say I have a foo function in foo.wasm and it is called in the main function. I want to replace the callee of call instruction with other function and direct the runtime to execute the code defined in other modules.

In my opinion, the only left option is to do it in the linking stage. Using -c flag, compiler describes how linker interprets the separate object files in customized "linking" section. My tool should parse those object files and modify the "linking" section and pass compiled substituted other object file to the wasm-ld together. In this way, if I do it correctly, wasm-ld would output only one wasm file and behave what I want it to do in the runtime.

[alexcrichton]

I believe the concerns here should be addressed by the wasmtime API crate at this time in terms of being able to preprocess imports, and if there's still an issue regarding WASI mind opening a new issue?