[PATCH] D81689: [WebAssembly] New-style command support

Mon Jun 27 13:50:37 PDT 2022

sunfish added a comment.

In D81689#3612529 <https://reviews.llvm.org/D81689#3612529>, @sbc100 wrote:

> In D81689#3611504 <https://reviews.llvm.org/D81689#3611504>, @yamt wrote:
>
>> there are use cases for a command to export non-main functions.
>> eg. malloc/free stuff mentioned in https://github.com/bytecodealliance/wasm-micro-runtime/blob/main/doc/memory_tune.md
>> this change broke them.

One consideration is that that wamr API doesn't seem compatible with closest thing we have to a spec <https://github.com/WebAssembly/WASI/blob/main/legacy/application-abi.md#current-unstable-abi>, which states "Command instances may assume that they will be called from the environment at most once. Command instances may assume that none of their exports are accessed outside the duration of that call.". It's debatable how authoritative that spec is, but the big picture is that there's not currently much clarity on the relationship between LLVM and engines.

>> for my very specific case it can be worked around eg. by "-mexec-model=reactor -emain". but i feel it isn't a right thing to do.

It's difficult to talk about the "right thing to do" in the short term. I'm giving a presentation at the upcoming WASI meeting about "WASI Preview2", which is a plan for a major new successor to the current wasi_snapshot_preview1 API, which will include a new clear definition of "commands", which I expect will be our best chance at fixing these issues.

> I believe the correct fix is to reference `__wasm_call_ctors()` somewhere, either by calling it or by exporting.   A common way to do this is to have a `_start` function that calls `__wasm_call_ctors` and then `main`.

This may work for now, but note that it isn't a documented workaround, and we may break it in future LLVM releases.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81689