[PATCH] D135903: [wasm-ld] Add support for calling constructors in reactors.

[Dan Gohman via Phabricator via llvm-commits]

sunfish added a comment.

In D135903#3856975 <https://reviews.llvm.org/D135903#3856975>, @sbc100 wrote:

> 



> However, shouldn't the long term goal be to have all wasi loaders run the `_initialize` function correctly, as spec'd?

I'll be proposing we drop the `_initialize` convention altogether. It was never properly standardized, and I now think we're better off without it. One of the nice things about this will be that we don't need wasi-specific loaders for reactors. Given a reactor, we can just load it into any wasm runtime and call functions on it, and it just works. This is how Web-oriented Wasm tends to work—you create a wasm module that exports/imports stuff, and then write JS code that instantiates it and calls it. You don't expect an implicitly-created `_initialize` function that you have to remember to call first. So dropping the `_initialize` function will make this kind of reactor-like use case less different from Wasm on the Web.

> Also, IIUC if `_initialize` exists and calls `__wasm_call_ctors` then these wrappers won't be generated (because `__wasm_call_ctors` will be referenced)  .. so this solution doesn't help modules that contain a valid `_initialize` function.

Yeah; the next step here will be to change the clang driver to stop passing `--entry=_initialize` and use `--no-entry` when linking a reactor, which will stop emitting `_initialize` and enable the wrappers.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D135903/new/

https://reviews.llvm.org/D135903