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

[YAMAMOTO Takashi via Phabricator via llvm-commits]

yamt added a comment.

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

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

the sentence made me think it was only about the entry point of the command. (_start)
what's "called" here is "command instances", not exported functions, isn't it?

a related question:
does it mean to prevent any callback-style apis?
i have a system in which the embedder provides C-callback style api to modules.
it's via C function pointers (func table indexes), not via exports, though.

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

ok. thank you for explanation.

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

i agree it isn't the best moment to make changes.

my point is that some of exports are entry points of the command and the others are not.

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

ok. thank you.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81689