[EH] Fuzz calls from JS by calling wasm exports, sometimes catching #7067
Conversation
scripts/fuzz_shell.js
Outdated
| // check for that first (wasm2js does not define RuntimeError, so use | ||
| // that for the check). | ||
| var wasm2js = !WebAssembly.RuntimeError; |
There was a problem hiding this comment.
This seems to assume we only fuzz wasm2js in environments that don't support WebAssembly. Otherwise WebAssembly.RuntimeError would be defined even if we were using wasm2js, right? I don't understand why this does what we want.
There was a problem hiding this comment.
Ah, no, when we run wasm2js it does WebAssembly = { .. polyfill .. }, so it tramples any native support. We can't mix native and polyfill stuff, so we have to do that.
There was a problem hiding this comment.
Got it, thanks. It would be good to clarify that in the comment.
| target = callExportCatchImportName; | ||
| // This never traps, so we can be less careful, but we do still want to | ||
| // avoid trapping a lot as executing code is more interesting. | ||
| maxIndex = (maxIndex + 1) * 2; |
There was a problem hiding this comment.
Maybe multiply by less than two here? I don't think we need half of the calls to be out of bounds.
There was a problem hiding this comment.
I was thinking (but I see I didn't document 😄 ) that this is fine because we are doing this as we go, that is, we are still adding functions (we don't know how many in advance). So even larger offsets will have a good chance to be in bounds. What do you think?
There was a problem hiding this comment.
aha, that seems reasonable, I suppose.
| ;; Note that the exported table appears first here, but in the binary and in | ||
| ;; the IR it is actually last, as we always add function exports first. |
There was a problem hiding this comment.
I think we have a TODO in the text parser to fix this and add the exports to the IR in their original order. I guess we'll just have to update this test if we ever fix that.
This adds two new imports to fuzzer modules:
any error, and returning 1 if it saw an error.
The former gives us calls back into the wasm, possibly making various
trips between wasm and JS in interesting ways. The latter adds a try-catch
which helps fuzz wasm EH.
We do these calls using a wasm export index, i.e., the index in
the list of exports. This is simple, but it does have the downside that
it makes executing the wasm sensitive to changes in exports (e.g.
wasm-merge adds more), which requires some handling in the fuzzer.