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

YAMAMOTO Takashi via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jun 27 17:44:04 PDT 2022


yamt added a comment.

In D81689#3613499 <https://reviews.llvm.org/D81689#3613499>, @sunfish wrote:

> 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.



- if "outside the duration of that call" mean it's ok to access exports during the call of _start, the wamr api seems compatible to me. (those malloc/free exports are used during the execution of _start, as far as i understand.)

- does the "command" concept implies wasi?

- i feel it's simpler to have two types of --export (eg. a new cli option to specify extra entry points), rather than flipping the semantics of all --export with a global command/reactor switch.

>>> 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.

unfortunately the meeting is at midnight for me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81689



More information about the llvm-commits mailing list