Beyond debugging a live process, there are times when "post-mortem" debugging is required, and extracting data like stack-frames with source locations, or local values (where possible) is desired.
An example being a process crash/coredump, where it is not feasible that the crashing process would do much further processing in the act of generating a dump (let alone run any further Wasm code). It should be possible to open the process dump, fetch the symbol info, and do some basic analysis correlated to the original source.
Another example could be application/site telemetry, where a Wasm trap would like to report the equivalent of JavaScript's Error.stack. Again, it wouldn't be desirable here that the browser (or Node process, or whatever) would go fetch and load all the symbol information for the Wasm modules (in whatever form that takes), but it should be able to report some data that can be correlated on the backend to provide details - probably at least the call-stack and source location for the fault.
Beyond debugging a live process, there are times when "post-mortem" debugging is required, and extracting data like stack-frames with source locations, or local values (where possible) is desired.
An example being a process crash/coredump, where it is not feasible that the crashing process would do much further processing in the act of generating a dump (let alone run any further Wasm code). It should be possible to open the process dump, fetch the symbol info, and do some basic analysis correlated to the original source.
Another example could be application/site telemetry, where a Wasm trap would like to report the equivalent of JavaScript's
Error.stack
. Again, it wouldn't be desirable here that the browser (or Node process, or whatever) would go fetch and load all the symbol information for the Wasm modules (in whatever form that takes), but it should be able to report some data that can be correlated on the backend to provide details - probably at least the call-stack and source location for the fault.