Robin Freyler

@orsinium thanks a lot for your PR! All in all this PR still needs some work before we can merge. How willing are you to do this? Otherwise I could...

Concerning your implementation questions: Wasmi does not really store a mapping of the actual functions on the call stack for performance reasons. However, with the information that you can find...

> > Though this won't provide you with the function's name > > We don't need the function name. All we need is the function index and the instruction index...

Concerning user facing API of how to get the Wasm coredump, I think we should simply do what Wasmtime does and embed `WasmCoreDump` to Wasmi's `Error` type when this option...

Due to the [massive performance regressions](https://github.com/bytecodealliance/wasm-tools/issues/2180) between `wasmparser` v228 -> v229 I decided _not_ to update to `wasm-tools` v229 for the upcoming Wasmi v0.45.0 release.

@bentheiii interesting proposal. Have you measured the actual difference in memory usage? Would be interesting to know the potential gains of such a PR.

> @Robbepop I haven't measured it yet (correct me if I'm wrong, but the only way to measure this is to implement and use my own fork in an example...

@luxinyi0105 Thank you for the bug report and sorry for taking so long to respond! Currently the WASI implementation of `wasmi` is flagged as experimental. The reasons for this are:...

@luxinyi0105 Can you try out if this one now works as intended with the fully-optimized `wasmi` as with https://github.com/paritytech/wasmi/issues/750 and https://github.com/paritytech/wasmi/issues/751?

> It seems right, but [witx spec](https://github.com/WebAssembly/wasi/blob/main/legacy/tools/witx-docs.md#pointers) says misaligned pointers ... shall trap, so in this sence, their results are not entirely correct. That's interesting since `wasmi` does not care...