add comment

remove an unnecessary line in the test

i added a test.

In D142615#4090846, @yamt wrote:

In D142615#4090795, @asb wrote:

Are you able to provide a test case that demonstrates the codegen change?

this function is broken without this change: https://github.com/yamt/garbage/blob/51ec5aaea4e30c9eece7665dea78cb71364076e2/wasm/tail-call/b.c#L12

In D142615#4090795, @asb wrote:

Are you able to provide a test case that demonstrates the codegen change?

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.

In D81689#3621510, @sbc100 wrote:

IIUC, with commands you can call back into the module, but only while the command entry point (_start) is running. i.e. while _start is running it can call out, and you can callback in as much as you want.

Once _start returns the instance is no longer in a valid state and can no longer called into (for example it would not be valid to call malloc after _start returns since the heap data structures may have been torn down).

If you want to call into a module after _start returns (and have the state preserved between calls) then what you want is a reactor and you should use _initialize rather than _start.

In D81689#3619437, @sunfish wrote:

In D81689#3614033, @yamt wrote:

In D81689#3613499, @sunfish wrote:

In D81689#3612529, @sbc100 wrote:

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

In D81689#3613499, @sunfish wrote:

In D81689#3612529, @sbc100 wrote:

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

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

In D90139#2353878, @ldionne wrote:

Thanks! If you need someone to commit this on your behalf, please provide the Author Name <email@domain> you'd like to be used.