wasm-ctor-eval: Remove the start function when we succeed#8702
wasm-ctor-eval: Remove the start function when we succeed#8702kripken wants to merge 13 commits into
Conversation
|
Fuzzer found a problem here... |
|
I guess Emscripten can never run wasm-ctor-eval on multithreaded programs, then? They rely on the start function to initialize memory from passive element segments. Precomputing that start function and then running the ctors would produce a module with active element segments that would overwrite memory every time the module is instantiated on a new thread. It would be nice to be able to serialize precomputed state to the passive element segments, but that would require keeping the start function as well. |
|
Yes, I think you're right - if you intend to initialize the module more than once, the model breaks. That is, ctor-eval assumes you will run the module once and that the ctors you give it will each run once during startup, period. |
| (start $s) | ||
|
|
||
| (func $s | ||
| (nop) |
There was a problem hiding this comment.
Maybe have this perform some visible side effect like incrementing a global so we can see that it happens twice?
Could we also construct a similar case where optimization ends after the start function is called but before it is called again as an exported constructor?
| ;; * start writes global2, and traps if global1 is set. | ||
| ;; * test sets global1. | ||
| ;; | ||
| ;; We must eval away the start function, when we eval away the other. That is, |
There was a problem hiding this comment.
| ;; We must eval away the start function, when we eval away the other. That is, | |
| ;; We must eval away the start function when we eval away the other. That is, |
|
Yeah I think wasm-ctor-eval is probably already incorrect for multithreaded modules before this change. |
2 participants
If we remove even one ctor that we were asked to, then we ran the start
function, and we evalled it too (if it trapped or such, we would not have
managed to eval that one ctor). But we left the start function there,
which meant it would run again, even though we evalled it and baked its
results into the wasm already.
Basically, the start function is like a ctor, and after evalling it successfully
we need to empty it out, so it doesn't re-execute, or else we would be
changing the program behavior.
Noticed when working to add fuzzing of the start function.
Reading the tests in reverse order here can help (github sorts by file
name) - the simplest test ended up sorted to the end unfortunately.