Exception handle ability for c++

[xingkaiyu]

We are using wamr and write the program mainly with c++.
I want do some try catch throw in my program but I found that all the excetion I throw will be catch by wamr. And I only can get "c++ excetion happen" then my app goto fail.
Will you please consider to give the catch ability for wasm app?

And I have anther question. I sometime will get some excetion send by wamr like "out of bound XXX". And it mainly becauce my wasm app code has some error. But I can not find which line cause the problem quickly but only by add log line by line or delete code line by line.
Could you please info me which line cause the problem?

Thanks~

[xujuntwt95329]

C++ exception is disabled by wasi-sdk currently, we just provide some wrappers to print that some exception occurs, but we can't get more information from the runtime layer.

static void
__cxa_throw_wrapper(wasm_exec_env_t exec_env,
                    void *thrown_exception,
                    void *tinfo,
                    uint32 table_elem_idx)
{
    wasm_module_inst_t module_inst = get_module_inst(exec_env);
    char buf[32];

    snprintf(buf, sizeof(buf), "%s", "exception thrown by stdc++");
    wasm_runtime_set_exception(module_inst, buf);
}

You can enable WAMR_BUILD_DUMP_CALL_STACK and WAMR_BUILD_CUSTOM_NAME_SECTION, then you can use wasm_runtime_dump_call_stack to dump the call stack, please refer to this document for more details. The call stack can only help to identify which function cause the exception, locating a single source line is not supported yet.

[xingkaiyu]

For the second question, I will try WAMR_BUILD_DUMP_CALL_STACK and WAMR_BUILD_CUSTOM_NAME_SECTION.

For the first question, I see wasm has a topic about exception handle https://github.com/WebAssembly/exception-handling. Is this topic undone or it is not what I want?

[xujuntwt95329]

exception-handling is a phase-2 proposal, we will pay attention to this proposal continually. In addition, it should be implemented both in runtime and compiler to support the exceptions.

[xingkaiyu]

@xujuntwt95329
I have tried WAMR_BUILD_DUMP_CALL_STACK and WAMR_BUILD_CUSTOM_NAME_SECTION. Now I can get some stack.
But except the export function and the __cxa_throw function, the other function name are all numbers. Can they be real name?
wasm_runtime::: #00 __cxa_throw
wasm_runtime::: #1 $f52
wasm_runtime::: #2 $f29
wasm_runtime::: #3 $f24
wasm_runtime::: #4 TestPthreadDouble

[xujuntwt95329]

Seems the function names are missing in your wasm file, rebuild with -g option to emit function name information

[xingkaiyu]

Did you mean add -g here?
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} --target=wasm32-wasi -O3 -g \

[xujuntwt95329]

Yes，and you can use wasm-objdump to check whether there is custom name section in the generated wasm file.

[xingkaiyu]

@xujuntwt95329
I know the problem. It is because I used strip-all when build wasm app....
Now, I can see the stack.
But I want to know whether I can see the line No. in the stack

The stack I see is:
2021-06-08 10:33:28.077 23961-23961/com.example.wamrtest I/wasm_runtime::: #00 __cxa_throw
2021-06-08 10:33:28.077 23961-23961/com.example.wamrtest I/wasm_runtime::: #1 bool nlohmann::detail::parser<nlohmann::basic_json<std::__2::map, std::__2::vector, std::__2::basic_string<char, std::__2::char_traits, std::__2::allocator >, bool, long long, unsigned long long, double, std::__2::allocator, nlohmann::adl_serializer, std::__2::vector<unsigned char, std::__2::allocator > >, nlohmann::detail::iterator_input_adapter<char const*> >::sax_parse_internal<nlohmann::detail::json_sax_dom_parser<nlohmann::basic_json<std::__2::map, std::__2::vector, std::__2::basic_string<char, std::__2::char_traits, std::__2::allocator >, bool, long long, unsigned long long, double, std::__2::allocator, nlohmann::adl_serializer, std::__2::vector<unsigned char, std::__2::allocator > > > >(nlohmann::detail::json_sax_dom_parser<nlohmann::basic_json<std::__2::map, std::__2::vector, std::__2::basic_string<char, std::__2::char_traits, std::__2::allocator >, bool, long long, unsigned long long, double, std::__2::allocator, nlohmann::adl_ser
2021-06-08 10:33:28.077 23961-23961/com.example.wamrtest I/wasm_runtime::: #2 nlohmann::detail::parser<nlohmann::basic_json<std::__2::map, std::__2::vector, std::__2::basic_string<char, std::__2::char_traits, std::__2::allocator >, bool, long long, unsigned long long, double, std::__2::allocator, nlohmann::adl_serializer, std::__2::vector<unsigned char, std::__2::allocator > >, nlohmann::detail::iterator_input_adapter<char const*> >::parse(bool, nlohmann::basic_json<std::__2::map, std::__2::vector, std::__2::basic_string<char, std::__2::char_traits, std::__2::allocator >, bool, long long, unsigned long long, double, std::__2::allocator, nlohmann::adl_serializer, std::__2::vector<unsigned char, std::__2::allocator > >&)
2021-06-08 10:33:28.077 23961-23961/com.example.wamrtest I/wasm_runtime::: #3 nlohmann::basic_json<std::__2::map, std::__2::vector, std::__2::basic_string<char, std::__2::char_traits, std::__2::allocator >, bool, long long, unsigned long long, double, std::__2::allocator, nlohmann::adl_serializer, std::__2::vector<unsigned char, std::__2::allocator > > nlohmann::basic_json<std::__2::map, std::__2::vector, std::__2::basic_string<char, std::__2::char_traits, std::__2::allocator >, bool, long long, unsigned long long, double, std::__2::allocator, nlohmann::adl_serializer, std::__2::vector<unsigned char, std::__2::allocator > >::parse<char const (&) [1]>(char const (&) [1], std::__2::function<bool (int, nlohmann::detail::parse_event_t, nlohmann::basic_json<std::__2::map, std::__2::vector, std::__2::basic_string<char, std::__2::char_traits, std::__2::allocator >, bool, long long, unsigned long long, double, std::__2::allocator, nlohmann::adl_serializer, std::__2::vector<unsigned char, std::__2::allocator >
2021-06-08 10:33:28.077 23961-23961/com.example.wamrtest I/wasm_runtime::: #4 TestPthreadDouble

[xujuntwt95329]

Hi, currently it is not possible to get the line number from the WAMR call stack. The line number information is stored in the DWARF sections, and it should be parsed by the debugger to get these information. So currently the simple call stack can only help to find the functions, you still need some print to analyze which line actually cause the exception before the release of debugger feature.

[xingkaiyu]

ok, thanks~