Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WAMR Exception Handling #756

Merged
merged 15 commits into from
May 26, 2023
Merged

WAMR Exception Handling #756

merged 15 commits into from
May 26, 2023

Conversation

csegarragonz
Copy link
Collaborator

@csegarragonz csegarragonz commented May 25, 2023

Faasm relies on exceptions being propagated from native function calls (i.e. host interface functions called from WASM) to the runtime code. For example, WASM code may call __faasm_migrate_point which, in turn, will throw a faabric::util::FunctionMigratedException. A very simplfied call stack would look something like the following:

<__faasm_migrate_point> -> throws exception
<functionDef2> -> WASM function
<functionDef1> -> WASM function
<WASM runtime call to invoke WASM> -> PROBLEM: may be written in C
<Faasm's runtime call to WASM runtime> -> try/catch exception

The previous works fine when the WASM runtime is implemented in C++ (e..g WAVM), as C++ exceptions are correctly propagated. Unfortunately, WAMR is written in C, so exceptions are not correctly propagated, and they are impossible to catch.

To work around this issue, we make use of setjmp/longjmp, inspired from here. This may feel like a big hack, but I don't think there's another way around it. This also means that we need to add a layer of indirection when throwing exceptions from native function calls (and potentially a number of dynamic_casts), but exception throwing and catching is not really performance critical (for now) so we can bear the cost.

In the process I homogeneise the interface to execute WASM functions with WAMR (i.e. making call by name and call by pointer use the same low-level functions).

@csegarragonz csegarragonz self-assigned this May 25, 2023
@csegarragonz csegarragonz marked this pull request as ready for review May 25, 2023 17:23
@csegarragonz csegarragonz mentioned this pull request May 26, 2023
45 tasks
@csegarragonz csegarragonz merged commit f850d7f into main May 26, 2023
13 checks passed
@csegarragonz csegarragonz deleted the wamr-exception branch May 26, 2023 18:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant