Add interpreter support for the exception handling proposal #1749
Conversation
takikawa
force-pushed
the
eh-interpreter
branch
2 times, most recently
from
a3a194f
to
9167cfd
Compare
|
Added f260e67, which is a small fixup commit that can be squashed later. It fixes a bug triggered by a newer version of the spec tests, with a cross-instance throw. It's difficult to test this with the wabt test framework, but the spec tests will catch it. |
|
Thanks for the merging the other two PRs @aheejin :) I forgot to also CC you on this big patch. |
|
Can you re-base on top of the already landed parts. Also, if there are remaining separate commits can you split them out into their own PRs maybe? Or does that make no sense in this case? |
Details about the implementation approach:
* Try blocks generate metadata tracking the instruction ranges for the
handlers and which exception tags are handled (or if a `catch_all` is
present). The metadata is stored in a function's `FuncDesc`, and is
transferred into the `Frame` when a function call is executed.
* The stack is unwound when a `throw` is executed. This unwinding also
handles tag dispatch to the appropriate catch. The metadata to find
the matching handler is looked up in the call `Frame` stack.
* If a `try-delegate` is present, it is used in the stack unwinding
process to skip over to the relevant handler.
* A separate `exceptions_` stack in call frames tracks caught
exceptions that can be accessed via a `rethrow`. The stack is popped
on exit from a try block or when exiting via control instructions
like `br`.
* Because stack unwinding relies on finding metadata in the call
frame, `return_call` needs to be modified slightly to adjust the
current frame when executing the call, rather than re-using the
frame completely as-is.
takikawa
force-pushed
the
eh-interpreter
branch
from
f260e67
to
46ef4dd
Compare
Sure, no problem. I just pushed a rebased version. Also I squashed the other commit into this too as it's not really a separate thing (since I was force pushing for the rebase anyway). |
|
Re: tests, there is some redundancy with spec tests in that there's overlap in what's tested and so they look similar (though I didn't copy-paste the spec tests). I did try to write tests that specifically target the more tricky bits of the wabt interpreter implementation (e.g., the exception stack for |
|
lgtm. WDYT @aheejin ? |
|
Friendly ping on this @aheejin, any feedback or comments appreciated :) |
|
Sorry! I was OOO for a while. I will take a look shortly. |
|
Thanks for the review feedback! I think I've addressed pretty much all the feedback now, although I still need to check if |
|
Pushed an extra commit that should fix the CI failure |
|
I pushed a fix for the This assert caught another bug, so I included that fix (some |
|
Thanks for all the comments! I think I've addressed everything now, and CI looks good. |
This PR adds interpreter support for the exception handling proposal.
Details about the implementation approach:
catch_allis present). The metadata is stored in a function'sFuncDesc, and is transferred into theFramewhen a function call is executed.throwis executed. This unwinding also handles tag dispatch to the appropriate catch. The metadata to find the matching handler is looked up in the callFramestack.try-delegateis present, it is used in the stack unwinding process to skip over to the relevant handler.exceptions_stack in call frames tracks caught exceptions that can be accessed via arethrow. The stack is popped on exit from a try block or when exiting via control instructions likebr.return_callneeds to be modified slightly to adjust the current frame when executing the call, rather than re-using the frame completely as-is.Spec tests will be followed up in future PRs once the proposal tests are merged into the official testsuite.