Non-standard WASM stack traces

• Component: WebAssembly
• Status: NEW ---

Created attachment 472396 [details]
The attached test code

TL;DR; JSC's WASM stack trace format does not match the one specified in "Developer Facing Conventions" (https://webassembly.github.io/spec/web-api/index.html#conventions), which makes implementing functionality that relies on the latter hard/impossible.

I am involved in developing a toolchain (NativeAOT-LLVM) that targets WASM. As part of our public API contract, we need to implement stack traces - in the format of our existing system. The details don't matter here; what matters is that the mechanism to implement this is by using the WASM function index as a key, parsing the JS (`new Error().stack`) trace looking for WASM frames, extracting the WASM function index, and then doing our thing with it.

This works quite well in Chrome/Node/FF. Unfortunately, it is not so straightforward with JSC, because the stack trace may omit the function index in case the `names` section was supplied. It means that to implement the functionality I will need to parse the names section at runtime, to build what is essentially a reverse mapping of "Function Name" -> "Function Index" (and that's assuming there is a unique mapping). Needless to say, this will be quite a bit of overhead (and complexity).

In the attachments, there is a `test.js` that I used for testing. It builds a WASM module on the fly and prints the stack trace from an import. Here is what it currently prints:
```
[e-mail]:73:63
wasm-stub@[wasm code]
<?>.wasm-function[ForeignModuleFrame]@[wasm code]
wasm-stub@[native code]
global [e-mail]:76:18
```
(Note: I only have a Windows machine, so I am using the JSC shell in WSL to test this.)

Note the `<?>.wasm-function[ForeignModuleFrame]@[wasm code]` WASM frame. Here are the concrete problems, in the order of 'importance' to the use cases such as mine:
1) Function index is missing and is replaced by the function name.
2) The "PC" is missing and is separated from `wasm-function[...]` by `@` instead of the expected `:0x`. This makes it impossible to map back to source code (file and line number) via symbolication tools. Note that Emscripten's `emcripten_get_return_address` also relies on this PC field.
3) There are `wasm-stub` frames that look like an implementation detail not relevant to the user. They are hard to reliably skip programmatically in the general case. Maybe a JSC-shell only artifact (I asked someone with a Mac to run this code through Safari, and it didn't have this issue).
4) `wasm-function[...]` is separated from the module name by `.` while `:` is expected.
5) Some kind of unique module identifier is missing, making it impossible to distinguish two different modules calling each other where the function indices collide. I know this is kind of an unsolvable problem because there can be two different _instances_ of the same module, or two modules that have the same name, but it would be nice to have something here anyway. In our system, since we know 'our' module will be on the stack just above the stack trace parsing code, we can make the "foreign vs not-foreign" distinction reasonably reliable, provided there is some identifier.

I would also like to bump the very old bug in the adjacent space https://bugs.webkit.org/show_bug.cgi?id=181439 up. It has similar functionality-breaking implications and will be even more painful to work around.

[Radar WebKit Bug Importer]

<rdar://problem/135513436>