This fixes unwind destination mismatches caused by 'catch'es, which
occur when a foreign exception is not caught by the nearest catch and
the next outer catch is not the catch it should unwind to, or the next
unwind destination should be the caller instead. This kind of mismatches
didn't exist in the previous version of the spec, because in the
previous spec catch was effectively catch_all, catching all
exceptions.
Details
- Reviewers
dschuff tlively - Commits
- rG9f770b36cbf6: [WebAssembly] Fix catch unwind mismatches
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Target/WebAssembly/WebAssemblyCFGStackify.cpp | ||
---|---|---|
905–906 | What is an example of when the split position could be before catch? | |
1267–1373 | ||
1268 | ||
1321–1322 | ~Is this supposed to be a continue?~ Oh, I see it's just there in service of the else ifs below. I found this confusing when I first saw it (especially without braces). I think it would be clearer if structured a different way. |
llvm/lib/Target/WebAssembly/WebAssemblyCFGStackify.cpp | ||
---|---|---|
905–906 | When fixing catch mismatches. When an inner try is included in a body of an outer try: bb0: try try ... bb1 (ehpad): catch ... ... bb2: (ehpad) end_try catch ... ... Suppose we need to wrap the inner try with try-delegate: bb0: try try ;; new inst try ... bb1 (ehpad): catch ... ... bb-pre: (ehpad) ;; new BB end_try bb-delegate: ;; new BB delegate ;; new inst bb2 (ehpad): catch ... ... The split pos is before the catch in bb2. Because catch's BB should be preserved, because that's what WasmEHFuncInfo remembers. | |
1321–1322 | The reason this is not a continue is it needs to run the common code at the very bottom: EHPadStack.push_back(EHPad); I can add the braces. Do you have any other restructuring suggestions? |
What is an example of when the split position could be before catch?