Fix some more spelling issues (#3393)

This commit is contained in:
Benbuck Nason
2024-05-07 18:30:29 -07:00
committed by GitHub
parent ca61184ced
commit 1c2a8fca4e
37 changed files with 134 additions and 134 deletions

View File

@ -79,7 +79,7 @@ cmake -DWAMR_BUILD_PLATFORM=linux -DWAMR_BUILD_TARGET=ARM
#### **Enable memory64 feature**
- **WAMR_BUILD_MEMORY64**=1/0, default to disable if not set
> Note: Currently, the memory64 feature is only supported in classic interpreter running mode.
> Note: Currently, the memory64 feature is only supported in classic interpreter running mode.
#### **Enable thread manager**
- **WAMR_BUILD_THREAD_MGR**=1/0, default to disable if not set
@ -137,7 +137,7 @@ cmake -DWAMR_BUILD_PLATFORM=linux -DWAMR_BUILD_TARGET=ARM
#### **Enable Exception Handling**
- **WAMR_BUILD_EXCE_HANDLING**=1/0, default to disable if not set
> Note: Currently, the exception handling feature is only supported in classic interpreter running mode.
> Note: Currently, the exception handling feature is only supported in classic interpreter running mode.
#### **Enable Garbage Collection**
- **WAMR_BUILD_GC**=1/0, default to disable if not set
@ -210,7 +210,7 @@ Currently we only profile the memory consumption of module, module_instance and
> }
> ```
>
> and then use `cmake -DWAMR_BH_VPRINTF=my_vprintf ..` to pass the callback function, or add `BH_VPRINTF=my_vprintf` macro for the compiler, e.g. add line `add_defintions(-DBH_VPRINTF=my_vprintf)` in CMakeListst.txt. See [basic sample](../samples/basic/src/main.c) for a usage example.
> and then use `cmake -DWAMR_BH_VPRINTF=my_vprintf ..` to pass the callback function, or add `BH_VPRINTF=my_vprintf` macro for the compiler, e.g. add line `add_definitions(-DBH_VPRINTF=my_vprintf)` in CMakeLists.txt. See [basic sample](../samples/basic/src/main.c) for a usage example.
#### **WAMR_BH_LOG**=<log_callback>, default to disable if not set
> Note: if the log_callback function is provided by the developer, WAMR logs are redirected to such callback. For example:
@ -285,7 +285,7 @@ Currently we only profile the memory consumption of module, module_instance and
- **WAMR_BUILD_AOT_INTRINSICS**=1/0, enable the AOT intrinsic functions, default to enable if not set. These functions can be called from the AOT code when `--disable-llvm-intrinsics` flag or `--enable-builtin-intrinsics=<intr1,intr2,...>` flag is used by wamrc to generate the AOT file.
> Note: See [Tuning the XIP intrinsic functions](./xip.md#tuning-the-xip-intrinsic-functions) for more details.
#### **Configurale memory access boundary check**
#### **Configurable memory access boundary check**
- **WAMR_CONFIGUABLE_BOUNDS_CHECKS**=1/0, default to disable if not set
> Note: If it is enabled, allow to run `iwasm --disable-bounds-checks` to disable the memory access boundary checks for interpreter mode.

View File

@ -207,7 +207,7 @@ There are two runtime APIs available for this purpose.
/**
* malloc a buffer from instance's private memory space.
*
* return: the buffer address in instance's memory space (pass to the WASM funciton)
* return: the buffer address in instance's memory space (pass to the WASM function)
* p_native_addr: return the native address of allocated memory
* size: the buffer size to allocate
*/
@ -219,7 +219,7 @@ wasm_runtime_module_malloc(wasm_module_inst_t module_inst,
* malloc a buffer from instance's private memory space,
* and copy the data from another native buffer to it.
*
* return: the buffer address in instance's memory space (pass to the WASM funciton)
* return: the buffer address in instance's memory space (pass to the WASM function)
* src: the native buffer address
* size: the size of buffer to be allocated and copy data
*/

View File

@ -36,7 +36,7 @@ void foo2(wasm_exec_env_t exec_env, char * msg, uint8 * buffer, int buf_len)
}
```
The first parameter exec_env must be defined using type **wasm_exec_env_t** which is the calling convention by WAMR.
The first parameter exec_env must be defined using type **wasm_exec_env_t** which is the calling convention by WAMR.
The rest parameters should be in the same types as the parameters of WASM function foo(), but there are a few special cases that are explained in section "Buffer address conversion and boundary check". Regarding the parameter names, they don't have to be the same, but we would suggest using the same names for easy maintenance.
@ -47,10 +47,10 @@ The rest parameters should be in the same types as the parameters of WASM functi
Register the native APIs in the runtime, then everything is fine. It is ready to build the runtime software.
``` C
// Define an array of NativeSymbol for the APIs to be exported.
// Define an array of NativeSymbol for the APIs to be exported.
// Note: the array must be static defined since runtime
// will keep it after registration
static NativeSymbol native_symbols[] =
static NativeSymbol native_symbols[] =
{
{
"foo", // the name of WASM function name
@ -61,7 +61,7 @@ static NativeSymbol native_symbols[] =
"foo2", // the name of WASM function name
foo2, // the native function pointer
"($*~)" // the function prototype signature
}
}
};
// initialize the runtime before registering the native functions
@ -69,12 +69,12 @@ wasm_runtime_init();
int n_native_symbols = sizeof(native_symbols) / sizeof(NativeSymbol);
if (!wasm_runtime_register_natives("env",
native_symbols,
native_symbols,
n_native_symbols)) {
goto fail1;
}
// natives registeration must be done before loading WASM modules
// natives registration must be done before loading WASM modules
module = wasm_runtime_load(buffer, size, error_buf, sizeof(error_buf));
```
@ -86,7 +86,7 @@ The function signature field in **NativeSymbol** structure is a string for descr
Each letter in the "()" represents a parameter type, and the one following after ")" represents the return value type. The meaning of each letter:
- '**i**': i32
- '**I**': i64
- '**I**': i64
- '**f**': f32
- '**F**': f64
- '**r**': externref (has to be the value of a `uintptr_t` variable), or all kinds of GC reference types when GC feature is enabled
@ -101,13 +101,13 @@ The signature can defined as NULL, then all function parameters are assumed as i
The `NativeSymbol` element for `foo2 ` above can be also defined with macro EXPORT_WASM_API_WITH_SIG. This macro can be used when the native function name is the same as the WASM symbol name.
```c
static NativeSymbol native_symbols[] =
static NativeSymbol native_symbols[] =
{
EXPORT_WASM_API_WITH_SIG(foo2, "($*~)") // wasm symbol name will be "foo2"
};
```
## Call exported API in WASM application
@ -124,7 +124,7 @@ int main(int argc, char **argv)
int c = foo(a, b); // call into native foo_native()
foo2(msg, buffer, sizeof(buffer)); // call into native foo2()
return 0;
}
```
@ -157,9 +157,9 @@ As function parameters are always passed in 32 bits numbers, you can also use 'i
// for buffer address or string parameters, here
// is how to do address conversion and boundary check manually
//
void foo2(wasm_exec_env_t exec_env,
uint32 msg_offset,
uint32 buffer_offset,
void foo2(wasm_exec_env_t exec_env,
uint32 msg_offset,
uint32 buffer_offset,
int32 buf_len)
{
wasm_module_inst_t module_inst = get_module_inst(exec_env);
@ -169,7 +169,7 @@ void foo2(wasm_exec_env_t exec_env,
// do boundary check
if (!wasm_runtime_validate_app_str_add(msg_offset))
return 0;
if (!wasm_runtime_validate_app_addr((uint64)buffer_offset, (uint64)buf_len))
return;
@ -187,7 +187,7 @@ void foo2(wasm_exec_env_t exec_env,
## Sandbox security attention
The runtime builder should ensure not broking the memory sandbox when exporting the native function to WASM.
The runtime builder should ensure not broking the memory sandbox when exporting the native function to WASM.
A ground rule:
@ -196,7 +196,7 @@ A ground rule:
A few recommendations:
- Never pass any structure/class object pointer to native (do data serialization instead)
- Never pass a function pointer to the native
- Never pass a function pointer to the native
Note: while not recommended here, nothing prevents you from passing
structure/function pointers as far as the native API is aware of

View File

@ -48,7 +48,7 @@ A WASM linear memory is either shared or non-shared.
A WASM linear memory has `min` and `max` sizes.
(They correspond to `wasm-ld`'s `--init-memory` and `--max-memory` options.)
They are in the number of WASM pages, each of which is of 65536 bytes.
The `max` is optional for non-shared memory. When omitted, it effectivily
The `max` is optional for non-shared memory. When omitted, it effectively
means unlimited.
The linear memory is allocated via `os_mmap` and `os_mem_commit`/`os_mprotect`.

View File

@ -132,7 +132,7 @@ make
```
## Aux stack seperation
## Aux stack separation
The compiler may use some spaces in the linear memory as an auxiliary stack. When pthread is enabled, every thread should have its own aux stack space, so the total aux stack space reserved by the compiler will be divided into N + 1 parts, where N is the maximum number of threads that can be created by the user code.
The default value of N is 4, which means you can create 4 threads at most. This value can be changed by an option if you are using product-mini:

View File

@ -13,7 +13,7 @@ There are three parts in the new version string:
## Legacy versions
All legacy versions(tags) will keep their current status. No existed releasings names
All legacy versions(tags) will keep their current status. No existing release names
and links will be changed.
## Reference

View File

@ -13,8 +13,8 @@ llvm-dwarfdump-12 test.wasm
## Debugging with interpreter
See [Debuggging with interpreter](source_debugging_interpreter.md).
See [Debugging with interpreter](source_debugging_interpreter.md).
## Debugging with AOT
See [Debuggging with AOT](source_debugging_aot.md).
See [Debugging with AOT](source_debugging_aot.md).

View File

@ -31,7 +31,7 @@ are helpful.
- call `wasm_engine_new` or `wasm_engine_delete` multiple times in
different threads
## unspported list
## unsupported list
Currently WAMR supports most of the APIs, the unsupported APIs are listed as below: