Open pmatos opened 2 years ago
Looks like that additional inlining does lead to issues, yes. The blogpost mentions the relevant reason:
One thing you may notice if you read the instrumented code is that runtime and sleep are not instrumented by Asyncify, as it assumes any function calling its API is “runtime” code - the code that controls when to unwind and rewind, and in particular, unwinding must stop when it reaches there!
We need some way to know when not to instrument a function, and use the presence of API calls for that - which is not great. In particular it can break due to inlining. Ideally we'd mark all the things the runtime calls as noinline, or we'd link in the runtime after optimizing, or something like that. However both of those techniques don't have good support, so in practice, I think disabling the inliner is necessary when using Asyncify with the runtime code linked in. This should probably be documented better...
We should also probably add a flag to disable inlining entirely. Atm, all max values need to be set to zero using something like -aimfs=0 -fimfs=0 -ocimfs=0
.
While reading @kripken 's post on asyncify, I gave the test case shown a go:
I was quite surprised that after:
Bisecting shows that the first bad commit is https://github.com/WebAssembly/binaryen/commit/1a6efdb4233a077bc6e5e8a340baf5672bb5bced . The title of the issue is an assumption due to the description in the first bad commit.