default WASM_STACK_GUARD_SIZE seems too small for linux about wasm-micro-runtime

[wenyongh]

Yes, how about increasing it to 2048 for linux platform?

BTW, the size of argv_buf in wasm_runtime_invoke_native seems too large and unnecessary since normally the parameter count of wasm function and host function won't be very large:

wasm-micro-runtime/core/iwasm/common/wasm_runtime_common.c

Lines 4883 to 4884 in 30426be

	uint64 argv_buf[32] = { 0 }, *argv1 = argv_buf, *ints, *stacks, size,
	arg_i64;

How about we also decreasing it, e.g. uint64 argv_buf[12]?

[yamt]

Yes, how about increasing it to 2048 for linux platform?

sure, it's the simplest solution.

BTW, the size of argv_buf in wasm_runtime_invoke_native seems too large and unnecessary since normally the parameter count of wasm function and host function won't be very large:

wasm-micro-runtime/core/iwasm/common/wasm_runtime_common.c

Lines 4883 to 4884 in 30426be

	uint64 argv_buf[32] = { 0 }, *argv1 = argv_buf, *ints, *stacks, size,
	arg_i64;

How about we also decreasing it, e.g. uint64 argv_buf[12]?

it makes sense to decrease it.
what's your rationale for 12?

[yamt]

btw, i want to group these issues with a label, say, "native stack overflow detection".
can you give me necessary permissions?

ditto for exception-handling.

[wenyongh]

btw, i want to group these issues with a label, say, "native stack overflow detection". can you give me necessary permissions?

ditto for exception-handling.

OK, done, please have a try.

[yamt]

btw, i want to group these issues with a label, say, "native stack overflow detection". can you give me necessary permissions?
ditto for exception-handling.

OK, done, please have a try.

i can assign existing labels. but i can't create new labels.

[wenyongh]

btw, i want to group these issues with a label, say, "native stack overflow detection". can you give me necessary permissions?
ditto for exception-handling.

OK, done, please have a try.

i can assign existing labels. but i can't create new labels.

I just assigned you with Triage role, creating the new label requires Write role, we need to discuss it internally. Shall I create the "native stack overflow detection" and "exception handling" labels for you first?

[yamt]

btw, i want to group these issues with a label, say, "native stack overflow detection". can you give me necessary permissions?
ditto for exception-handling.

OK, done, please have a try.

i can assign existing labels. but i can't create new labels.

I just assigned you with Triage role, creating the new label requires Write role, we need to discuss it internally. Shall I create the "native stack overflow detection" and "exception handling" labels for you first?

yes. it's enough.

[wenyongh]

Yes, how about increasing it to 2048 for linux platform?

sure, it's the simplest solution.

BTW, the size of argv_buf in wasm_runtime_invoke_native seems too large and unnecessary since normally the parameter count of wasm function and host function won't be very large:

wasm-micro-runtime/core/iwasm/common/wasm_runtime_common.c

Lines 4883 to 4884 in 30426be

	uint64 argv_buf[32] = { 0 }, *argv1 = argv_buf, *ints, *stacks, size,
	arg_i64;

How about we also decreasing it, e.g. uint64 argv_buf[12]?

it makes sense to decrease it. what's your rationale for 12?

In current libc-wasi, it seems that API wasi_path_open has the maximum argument count: 9 arguments + 1 exec_env = 10, I suppose 12 is big enough for most cases. Or any suggestion from you?

[wenyongh]

btw, i want to group these issues with a label, say, "native stack overflow detection". can you give me necessary permissions?
ditto for exception-handling.

OK, done, please have a try.

i can assign existing labels. but i can't create new labels.

I just assigned you with Triage role, creating the new label requires Write role, we need to discuss it internally. Shall I create the "native stack overflow detection" and "exception handling" labels for you first?

yes. it's enough.

Done, the two labels were created.

[yamt]

btw, i want to group these issues with a label, say, "native stack overflow detection". can you give me necessary permissions?
ditto for exception-handling.

OK, done, please have a try.

i can assign existing labels. but i can't create new labels.

I just assigned you with Triage role, creating the new label requires Write role, we need to discuss it internally. Shall I create the "native stack overflow detection" and "exception handling" labels for you first?

yes. it's enough.

Done, the two labels were created.

thank you.

[yamt]

Yes, how about increasing it to 2048 for linux platform?

sure, it's the simplest solution.

BTW, the size of argv_buf in wasm_runtime_invoke_native seems too large and unnecessary since normally the parameter count of wasm function and host function won't be very large:

wasm-micro-runtime/core/iwasm/common/wasm_runtime_common.c

Lines 4883 to 4884 in 30426be

	uint64 argv_buf[32] = { 0 }, *argv1 = argv_buf, *ints, *stacks, size,
	arg_i64;

How about we also decreasing it, e.g. uint64 argv_buf[12]?

it makes sense to decrease it. what's your rationale for 12?

In current libc-wasi, it seems that API wasi_path_open has the maximum argument count: 9 arguments + 1 exec_env = 10, I suppose 12 is big enough for most cases. Or any suggestion from you?

well, the principle "whatever largest commonly-used api needs" sounds reasonable to me.

however, the actual value seems a bit more larger than that:

wasm-micro-runtime/core/iwasm/common/wasm_runtime_common.c

Lines 4910 to 4915 in d39d2ba

	#if WASM_ENABLE_SIMD == 0
	argc1 = 1 + MAX_REG_FLOATS + (uint32)func_type->param_count + ext_ret_count;
	#else
	argc1 = 1 + MAX_REG_FLOATS * 2 + (uint32)func_type->param_count * 2
	+ ext_ret_count;
	#endif

[yamt]

Yes, how about increasing it to 2048 for linux platform?

sure, it's the simplest solution.

probably 2048 is not enough as
aot_call_indirect + invoke_native_with_hw_bound_check + wasm_runtime_invoke_native
seems to consume about 1000 bytes. (macOS amd64)
how about 3KB?

[wenyongh]

Yes, how about increasing it to 2048 for linux platform?

sure, it's the simplest solution.

BTW, the size of argv_buf in wasm_runtime_invoke_native seems too large and unnecessary since normally the parameter count of wasm function and host function won't be very large:

wasm-micro-runtime/core/iwasm/common/wasm_runtime_common.c

Lines 4883 to 4884 in 30426be

	uint64 argv_buf[32] = { 0 }, *argv1 = argv_buf, *ints, *stacks, size,
	arg_i64;

How about we also decreasing it, e.g. uint64 argv_buf[12]?

it makes sense to decrease it. what's your rationale for 12?

In current libc-wasi, it seems that API wasi_path_open has the maximum argument count: 9 arguments + 1 exec_env = 10, I suppose 12 is big enough for most cases. Or any suggestion from you?

well, the principle "whatever largest commonly-used api needs" sounds reasonable to me.

however, the actual value seems a bit more larger than that:

wasm-micro-runtime/core/iwasm/common/wasm_runtime_common.c

Lines 4910 to 4915 in d39d2ba

	#if WASM_ENABLE_SIMD == 0
	argc1 = 1 + MAX_REG_FLOATS + (uint32)func_type->param_count + ext_ret_count;
	#else
	argc1 = 1 + MAX_REG_FLOATS * 2 + (uint32)func_type->param_count * 2
	+ ext_ret_count;
	#endif

Oh, that's really upsetting, suppose MAX_REG_FLOATS is 8 and SIMD is enabled, allocation will occur when the native API has 8 arguments: 1 + 8 * 2 + 8 * 2= 33 > 32. Maybe we had better keep 32 unchanged.

[wenyongh]

Yes, how about increasing it to 2048 for linux platform?

sure, it's the simplest solution.

probably 2048 is not enough as aot_call_indirect + invoke_native_with_hw_bound_check + wasm_runtime_invoke_native seems to consume about 1000 bytes. (macOS amd64) how about 3KB?

It sounds good to me.

[wenyongh]

BTW, we are planning to release WAMR-2.0.0 since we haven't released a new version for some time and also there are some developers asking for the new release, is it ok to create the release before your enhancement PR for native stack overflow check is finished? Maybe we can add it in the release 2.0.1.

[yamt]

BTW, we are planning to release WAMR-2.0.0 since we haven't released a new version for some time and also there are some developers asking for the new release, is it ok to create the release before your enhancement PR for native stack overflow check is finished? Maybe we can add it in the release 2.0.1.

#3325 might or might not involve abi breakage.