Skip to content

[release/11.0] [mono][llvm] Properly link endfinally to leave targets - #133242

Merged
akoeplinger merged 1 commit into
release/11.0from
backport/pr-133011-to-release/11.0
Sep 9, 2026
Merged

akoeplinger merged 1 commit into
release/11.0from
backport/pr-133011-to-release/11.0

Conversation

@github-actions

@github-actions github-actions Bot commented Sep 4, 2026 •

Copy link
Copy Markdown
Contributor

Backport of #133011 to release/11.0

/cc @BrzVlad

Customer Impact

  • Customer reported
  • Found internally

Customer reported error on .net10, during AOT compilation for wasm, when using an obfuscator tool. This issue would cause crash when AOT compiling with llvm enabled. The only workaround would be to completely disable AOT on wasm or disable LLVM on iOS, both with significant performance impact.

Regression

  • Yes
  • No

Testing

Customer provided repro sample. Added runtime test as part of this fix.

Risk

Low. The fix simply defers linking of finally clauses after the initial iteration on the IL, when we have all necessary information available.

When emitting a leave instruction, we need to find all finally blocks so
that we call all those handlers beforehand. LLVM chooses to link the
finally block with the leave targets so it does it and this point. It
does it however in a wrong way, by linking the bblock containing the
last instruction to the leave target. This is incorrect because a
finally block can have multiple endfinally opcodes and the last opcode
doesn't necessarily need to be an endfinally in the first place. This
invalid CFG generation could trigger asserts in later optimization
passes.

As a fix, whenever we compile a leave and obtain all the protecting
finally handlers, we store them in a per-finally handler list. Then,
once the code gen is finished, we iterate over all instructions of
bblocks in those finally blocks and, whenever we encounter an
endfinally, we link that bblock to the leave target. This fixes the
invalid linking of bblocks as well as properly handling the scenario of
having multiple endfinally blocks.

Fixes #132936
@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
Successfully started running 4 pipeline(s).
12 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

@dotnet-policy-service

Copy link
Copy Markdown
Contributor

Tagging subscribers to this area: @steveisok, @vitek-karas
See info in area-owners.md if you want to be subscribed.

@BrzVlad BrzVlad added the Servicing-consider Issue for next servicing release review label Sep 4, 2026
@BrzVlad BrzVlad added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Sep 8, 2026
@akoeplinger
akoeplinger merged commit a61de42 into release/11.0 Sep 9, 2026
151 of 154 checks passed
@akoeplinger
akoeplinger deleted the backport/pr-133011-to-release/11.0 branch September 9, 2026 13:04
@dotnet-milestone-bot dotnet-milestone-bot Bot added this to the 11.0-rc2 milestone Sep 9, 2026
@github-actions github-actions Bot locked and limited conversation to collaborators Oct 10, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area-Codegen-JIT-mono Servicing-approved Approved for servicing release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants