Exception filters handling in WebAssembly AOT

[marek-safar]

Unfortunately, CLR supports exception filters that don’t unwind the stack. This is something that is not supported by WASM. We'll have to mitigate this somehow as exception filters are C# feature that is generally used nowadays. This is problematic for other targets that generate intermediate representations like is WASM. We have a few options on how to handle this for WebAssembly.

Implement basic blocks transformation inside MonoVM

This is an interesting option from a tooling perspective as it would allow us to target only methods that are AOT-ed and don't complicate build process. We would have to do a similar transformation for an interpreter to keep the behaviour consistent.

Unfortunately, it's the most expensive option as Mono does not have a place where we could do the transformation and the exception logic is scattered everywhere.

Write a new build task

We could write a tool that rewrites IL as part of the build process. We have a prototype of that work and it's a non-trivial amount of code which we'd need to re-process during every build unless we add some extra caching.

Rewrite IL code as part of ILLink run

This is the same as the option above but we would run it as part of the trimming process which would mean running linker possibly inside faster inner-dev loop.

Rewrite original C# code

This alternative is interesting as it would give the developers and end-users exactly same behaviour in hot-reload and publish-ed output. Although without aggressive analyzers and code-fixes it's quite unlikely we'll succeed in changing developers habits on using this C# feature.

@vargaz @lewing

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Unfortunately, CLR supports exception filters that don’t unwind the stack. This is something that is not supported by WASM. We'll have to mitigate this somehow as exception filters are C# feature that is generally used nowadays. This is problematic for other targets that generate intermediate representations like is WASM. We have a few options on how to handle this for WebAssembly.

Implement basic blocks transformation inside MonoVM

This is an interesting option from a tooling perspective as it would allow us to target only methods that are AOT-ed and don't complicate build process. We would have to do a similar transformation for an interpreter to keep the behaviour consistent.

Unfortunately, it's the most expensive option as Mono does not have a place where we could do the transformation and the exception logic is scattered everywhere.

Write a new build task

We could write a tool that rewrites IL as part of the build process. We have a prototype of that work and it's a non-trivial amount of code which we'd need to re-process during every build unless we add some extra caching.

Rewrite IL code as part of ILLink run

This is the same as the option above but we would run it as part of the trimming process which would mean running linker possibly inside faster inner-dev loop.

Rewrite original C# code

This alternative is interesting as it would give the developers and end-users exactly same behaviour in hot-reload and publish-ed output. Although without aggressive analyzers and code-fixes it's quite unlikely we'll succeed in changing developers habits on using this C# feature.

@vargaz @lewing

Author:	marek-safar
Assignees:	-
Labels:	arch-wasm
Milestone:	-

[marek-safar]

This issue targets WebAssembly but any intermediate representation can be affected (#47197)

[vargaz]

An alternative approach might be to run these methods with the interpreter. Since interpreter frames are linked together, it might be possible to execute the filters in the first pass before 'throwing' the exception. Will experiment.

[vargaz]

#47551

[vargaz]

With the above PR merged, filter clauses seem to work in aot+interp mode for simple tests.

[vargaz]

This test still fails:
dotnet/linker#1770 (comment)

[lewing]

#52883 mitigated this issue by doing all exception handling in the interpreter. Should we resolve this or keep it open to continue to explore other options?

[vargaz]

I think the current approach is good enough.