Provide source location for traps about wasm-c-api HOT 4 OPEN

This would still be useful.

from wasm-c-api.

I'd like to be able to get the entire stacktrace from a trap (or other exception) in terms of (instance,function,offset) triplets or (instance,module_offset) pairs. The reason that in my language project, the instance is needed in that transforming wasm frames to source-language frames is not one-to-one; the translation is accomplished by a callback exported from the module (e.g. render_frames(func_index: i32, offset: i32)) that transforms a wasm frame into one or more source-level frames. The metadata needed for the translation is encoded entirely within the module itself; i.e. the engine embedding does not know how to interpret it, since it is densely encoded and may change from language version to language version.

Sourcefiles are not that useful, since my embedding would then need to map the source files back to the instances in order to get to the callback that renders source-level frames.

So I would propose that the engine has an API roughly like:

wasm::Engine::GetTrapStackTrace(own<wasm::Trap*> trap) -> own vec<pair<wasm::Instance*, module_offset: int32_t>>

wdyt?

from wasm-c-api.

In principle this makes sense to me (especially since it avoids source names). OTOH, I can imagine engines that would not want to maintain this information (esp. the byte offset). So maybe this should be some kind of optional feature?

from wasm-c-api.

We should think about a set of debugging features for dynamic introspection. That should probably be a separate sub-API, with a mirror-like interface. I'm happy to defer the design of that API until later (when I need it :-)). This feature falls somewhere in-between raw execution and that more general debugging API, though I'd argue for languages that make every effort to guarantee some kind of stack trace (like Virgil), it's not really optional. For comparison, the JVM produces "source level" stack traces from the source mapping in class files. It assumes that each class file is produced from a single source file and does the bytecode offset->line number translation for you via a table inlined into the classfile. That means it has no (direct) support for inlining. This makes it a huge pain to get exact stack traces the way Virgil expects, which I pretty much gave up on after native bootstrapping. The JVM would have been more useful it if would have given classfile (or method) + bytecode offset pairs like I propose.

Wasm can do better here, in my opinion, and the function+offset pairs is enough to be fully general, I think.

from wasm-c-api.