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

Wed Jun 29 08:59:56 PDT 2022

sunfish added a comment.

In D81689#3614033 <https://reviews.llvm.org/D81689#3614033>, @yamt wrote:

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

I'm referring to the "will be called from the environment at most once" part.
If I understand correctly, these `malloc`/`free` exports are used to make
additional calls into the instance.

> - does the "command" concept implies wasi?

That's a complex question :-). The concept of a "command" isn't in core
WebAssembly, at least. Consequently, it needs to be defined in some other
standards layer. At the moment, WASI has a definition for its own use.

It looks like the component model will provide a definition soon, with the
canonical ABI defining how a "command" looks in core WebAssembly, and with
WASI Preview2 I'm planning to propose WASI switch to that.

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

I don't currently have a clear view of what functionality LLVM should support,
and am reluctant to add more compatibility surface area until we have more
clarity about this.

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

I'll post the slides in the meeting notes, and I'll be following up with
documentation and standards proposals.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81689