__wasm_call_ctors broken previously wokring rust wasm reactors

[ValeryAntopol]

Lately rust updated to 1.56 and started compiling modules to wasm32-wasi target with exec-model=command, which resulted in all exports wrapped with __wasm_call_ctors and __wasm_call_dtors calls, which look like this:

  (func $__wasm_call_ctors (type 8)
    call $__wasilibc_initialize_environ_eagerly)

  (func $dummy (type 8))
  (func $__wasm_call_dtors (type 8)
    call $dummy
    call $dummy)

So, __wasm_call_ctors allocates memory for environment variables and writes pointer to a global variable, and __wasm_call_dtors does nothing. This behavior led to memory leaks in our "handmade" reactors, each call to each export function leaks a small amount of memory, and in our usecase there can be unlimited number of export calls, a module can reach 4GB limit in several days!

I am looking for ways to fix it. I found two ways here WebAssembly/WASI#471: add explicit call to __wasm_call_ctors or use nightly rust feature -Z wasi-exec-model=reactor. We don't want to switch to the nightly in our sdk, so the second solution is not an option, and the first solution will force us to make backwards-incompatible changes in the interface. So we tried to pass -mexec-model=reactor to LLVM through rustc, to make it compile reactor without switching to nightly rust, but did not wind a way.

My question is: is there a way to change this behaviour by supplying any flags to the latest stable rust without adding an explicit call to __wasm_call_ctors? Are there workarounds not mentioned in this issue?

[sunfishcode]

I myself am unaware of any other workarounds. The background here is that the current commands and reactors concepts were meant to be steps toward having a plan for how to support this in a reasonably robust way, however the standards proposals they were meant to be layered on top of changed, and those designs no longer make sense.

I am currently working on a WASI Preview2 plan, which will be a path forward to a completely new system for commands and reactors (which I expect we'll rename to just "libraries"). The standards proposals below Preview2 are now settling down, so it'll be easier to add these features in places like the Rust toolchain, which users expect to be stable, with decent confidence that things won't change underneath.

[ValeryAntopol]

Thank you! Thats sad that there is no better workaround. The only thing left for as is an explicit __wasm_call_ctors call and hope that rust stabilizes reactors support before breaking this workaround.