wasm-ctor-eval: Remove the start function when we succeed

[kripken]

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.

[kripken]

Fuzzer found a problem here...

[tlively]

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.

[kripken]

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.

[tlively]

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?

[kripken]

Good ideas, done.

[tlively]

Yeah I think wasm-ctor-eval is probably already incorrect for multithreaded modules before this change.