per-host function override of native stack requirement about wasm-micro-runtime

[wenyongh]

Hi, it seems both two methods are not so straightforward, how about we just introduce a new API to set the native stack size required for the host native APIs? Some what like:

struct NativeSymbolStack {
    const char *name;
    uint32 stack_size;
}
wasm_runtime_set_native_api_stacks(NativeSymbolStack *native_stacks, uint32 n_symbol_stack);

And the info will be propagated into a field in WASMFunctionImport and AOTFuncImport, and runtime does native stack overflow check according to the field's value before calling the native API, and by default the field value is WASM_STACK_GUARD_SIZE if it isn't set by the API. Also runtime can set the field value of some native APIs after registering some built-in native APIs.

[yamt]

Hi, it seems both two methods are not so straightforward, how about we just introduce a new API to set the native stack size required for the host native APIs? Some what like:

struct NativeSymbolStack {
    const char *name;
    uint32 stack_size;
}
wasm_runtime_set_native_api_stacks(NativeSymbolStack *native_stacks, uint32 n_symbol_stack);

And the info will be propagated into a field in WASMFunctionImport and AOTFuncImport, and runtime does native stack overflow check according to the field's value before calling the native API, and by default the field value is WASM_STACK_GUARD_SIZE if it isn't set by the API. Also runtime can set the field value of some native APIs after registering some built-in native APIs.

at this point, i don't have strong opinion on the api. (how to give the n_symbol_stack value.)
your suggested api would have almost same overflow detection implementation with the first approach, right?
how do you think about the last item in cons?
this one:

   "direct call (what aot_compile_op_call does when signature is available)
   needs something different. maybe the aot compiler can emit the check.
   however, it would effectively make the stack requirement of the native
   function a part of the AOT ABI. i'm not sure if it's acceptable.")

[wenyongh]

Yes, it is very similar to the first approach, but no need to make changes for current runtime native libraries implementation and developer's native library registration if there is no extra requirement from him.

For the last item, yes, had better let aot compiler emit the check directly, not sure whether it is good to pass the native stack size info to wamrc like registering the empty native apis for it with wamrc --native-lib=xxx.so? We can add another option like wamrc --native-stack-lib=xxx.so?

[wenyongh]

BTW, the api had better use module name as the first argument, like wasm_runtime_register_natives: wasm_runtime_set_native_api_stacks(const char *module_name, NativeSymbolStack *native_stacks, uint32 n_symbol_stack)

[wenyongh]

Yes, it is very similar to the first approach, but no need to make changes for current runtime native libraries implementation and developer's native library registration if there is no extra requirement from him.

For the last item, yes, had better let aot compiler emit the check directly, not sure whether it is good to pass the native stack size info to wamrc like registering the empty native apis for it with wamrc --native-lib=xxx.so? We can add another option like wamrc --native-stack-lib=xxx.so?

Or just reuse the option wamrc --native-lib=xxx.so，but require the so to provide extra api to get the native stack info

[yamt]

Yes, it is very similar to the first approach, but no need to make changes for current runtime native libraries implementation and developer's native library registration if there is no extra requirement from him.

even with the first approach, users who don't care can leave it default.
(similarly to what we do for NativeSymbol attachment today)

For the last item, yes, had better let aot compiler emit the check directly, not sure whether it is good to pass the native stack size info to wamrc like registering the empty native apis for it with wamrc --native-lib=xxx.so?

with the first approach, wamrc --native-lib would work as of today.

We can add another option like wamrc --native-stack-lib=xxx.so?

i'm not sure how it looks like.
does xxx.so for --native-stack-lib use an api different from the current get_native_lib/init_native_lib/deinit_native_lib?

Or just reuse the option wamrc --native-lib=xxx.so，but require the so to provide extra api to get the native stack info

do you mean to export an extra symbol?

anyway, my original concern was not really about --native-lib.
let me explain.
by making the aot compiler emit the caller-side check for a native function,
we effectively embed the corresponding n_symbol_stack value into the aot-compiled module.
if we later modify the implementation of the native function and it ends up with changing the n_symbol_stack value,
we need to re-aot-compile all modules which potentially use the native function.
for that reason, right now, i'm inclined toward the approach (b).

[wenyongh]

Yes, it is very similar to the first approach, but no need to make changes for current runtime native libraries implementation and developer's native library registration if there is no extra requirement from him.

even with the first approach, users who don't care can leave it default. (similarly to what we do for NativeSymbol attachment today)

For the last item, yes, had better let aot compiler emit the check directly, not sure whether it is good to pass the native stack size info to wamrc like registering the empty native apis for it with wamrc --native-lib=xxx.so?

with the first approach, wamrc --native-lib would work as of today.

We can add another option like wamrc --native-stack-lib=xxx.so?

i'm not sure how it looks like. does xxx.so for --native-stack-lib use an api different from the current get_native_lib/init_native_lib/deinit_native_lib?

Or just reuse the option wamrc --native-lib=xxx.so，but require the so to provide extra api to get the native stack info

do you mean to export an extra symbol?

anyway, my original concern was not really about --native-lib. let me explain. by making the aot compiler emit the caller-side check for a native function, we effectively embed the corresponding n_symbol_stack value into the aot-compiled module. if we later modify the implementation of the native function and it ends up with changing the n_symbol_stack value, we need to re-aot-compile all modules which potentially use the native function. for that reason, right now, i'm inclined toward the approach (b).

OK, b is also good as long as it is not very trivial for you to add checks in the native apis.