WASM traces do not correspond to expected offsets

[ludamad]

Hi! I am arriving here via using jest 22+. I have quite a headache debugging why my WASM stack traces in jest:

RuntimeError: Aborted(-1)
    at abort (/mnt/user-data/adam/scratch/out.js:986:11)
    at _logstr (/mnt/user-data/adam/scratch/out.js:1502:36)
    at void info<char const*, unsigned long, char const*>(char const*, unsigned long, char const*) (wasm://wasm/16a7a962:wasm-function[236]:0x548d7)
    at test_async_func (wasm://wasm/16a7a962:wasm-function[235]:0x547d4)

were being rewritten:

RuntimeError: Aborted(-1)
    at abort (/mnt/user-data/adam/scratch/out.js:986:11)
    at _logstr (/mnt/user-data/adam/scratch/out.js:1502:36)
    at void info<char const*, unsigned long, char const*>(char const*, unsigned long, char const*) (wasm://wasm/16a7a962:1:346266)
    at test_async_func (wasm://wasm/16a7a962:1:346007)

This interfered with the way I was transforming to line numbers as these numbers don't quite line up.
I came to this repo as restoring prepareStackTrace to the default alleviated the issue (of course, also disabling source maps though) I was wondering if light could be shed on the behaviour, I'm not sure how this rewrite was intended to be used but I cannot pass this through a DWARF-based stack trace translator, at least not in a way I can see

Thanks for any insight
Adam

[ludamad]

It seems a workaround is to save callSite.origToString = frame.toString() and return it for WASM stack frames

[ludamad]

I can provide a PR here if the above approach seems doable - it would help anyone looking to transform WASM stack after this tool. I have local changes that work (currently automatically translating WASM, but I don't think I can upstream that)