[wasm] Emit terminal end for EH funclets ending in a no-return call

[lewing]

Summary

When crossgen2 compiles managed methods to WebAssembly (wasm32) R2R, it emits a malformed wasm function body for certain exception-handling (EH) funclets: the required terminal end opcode (0x0b) is dropped. The resulting module fails validation — both V8 and wasm-tools validate reject it with function body must end with end opcode. A wasm function body is structurally required to end in end regardless of whether the last instruction is reachable, so dropping it produces invalid wasm.

The defect is in the shared TARGET_WASM codegen path (no OS-specific branching), so it reproduces identically for both --targetos:browser and --targetos:wasi, and the fix benefits both.

Repro / observed

Compiling System.Data.Common.dll to wasm R2R produces two malformed EH funclets, both property setters:

method	funclet
System.Data.DataColumn.set_Expression	4
System.Data.DataTable.set_Locale	3

Both are EH funclets (they have an exnref local — try_table/catch_ref EH) whose last block ends in a no-return tail (call_indirect (no-return) + unreachable), after which the terminal 0x0b is missing. This is not SIMD-related: the two funclets contain zero 0xfd-prefixed opcodes, and the composite is byte-identical whether SIMD is forced on or bailed (--codegenopt:JitWasmSimdNyiToR2RUnsupported=0 vs =1). It reproduces identically on browser and WASI (same funclet, same byte offset), confirming it is OS-agnostic.

Root cause

The wasm end-emission guard block->IsLast() || bbIsFuncletBeg(block->Next()) uses the global block order (bbNext), in which a funclet's last block can be followed by an interspersed root throw-helper block (fgIsThrowHlpBlk, no handler index) that is not a funclet begin. Codegen iterates per funclet (genCodeForFunclet over funcInfo->Blocks()), so the guard fails to recognize the funclet boundary and the terminal end is never emitted.

This same unsound predicate was duplicated across four wasm end-emission sites:

• the BBJ_THROW and BBJ_ALWAYS arms of genEmitEndBlock (codegenlinear.cpp),
• the retless BBJ_CALLFINALLY path in genCallFinally (codegenwasm.cpp, added by Wasm R2R: emit trailing end after retless BBJ_CALLFINALLY #129449), and
• the end/return discriminator in genFuncletEpilog (codegenwasm.cpp).

The copy-paste drift across these sites is what let this gap — and the incompleteness of the prior fix #129335 — arise.

Fix

Consolidate the predicate into a single wasm helper CodeGen::genIsLastBlockOfCurrentFunc that also compares against the current func/funclet's authoritative last block (funCurrentFunc()->GetLastBlock()), and route all four end-emission sites through it:

bool CodeGen::genIsLastBlockOfCurrentFunc(BasicBlock* block)
{
    return block->IsLast() || m_compiler->bbIsFuncletBeg(block->Next()) ||
           (block == m_compiler->funCurrentFunc()->GetLastBlock(m_compiler));
}

Correct across every funclet kind, by construction. FuncInfoDsc::GetLastBlock resolves to fgLastBBInMainFunction() for FUNC_ROOT, ehDsc->BBFilterLast() for FUNC_FILTER, and ehDsc->ebdHndLast for FUNC_HANDLER (which covers catch/finally/fault handlers alike). Crucially, it is the exact upper bound of the per-funclet codegen iteration range — FuncInfoDsc::Blocks() is defined as BasicBlockRangeList(GetStartBlock(comp), GetLastBlock(comp)) — so the new term recognizes precisely the last block codegen will process for the current func/funclet, for every kind, not just the two BBJ_THROW cases the repro exercises.

The added term is an additive OR, so each block still emits at most one terminal end (no double-end regression on the BBJ_RETURN / funclet-epilog paths), and because it is authoritative it cannot false-positive on mid-funclet blocks. Routing all four sites through one predicate removes the drift that caused this class of bug.

This is not a mirror of the non-wasm DOES_NOT_RETURN else-clause (which emits an INS_BREAKPOINT for GC liveness) — on wasm the correct behavior is to still emit the function body's terminal end.

Validation

Recrossgenned standalone System.Data.Common → wasm R2R:

• Both funclets now emit their terminal end.
• wasm-tools validate: passes (was failing at func 597 pre-fix).
• No double-end regression — validation rules out both a missing end ("control frames remain") and an extra end across all functions in the module.
• The change is a pure predicate consolidation: the emitted module is byte-identical across rebuilds.
• Confirmed on both --targetos:browser and --targetos:wasi: unfixed crossgen2 fails validation at the same funclet (func 597, offset 0xdb1ae) on both targets; the fixed build passes wasm-tools validate on both.
• Independently confirmed against a second, separately-built standalone System.Data.Common fixture (same func 597).

Related sibling defect (separate root cause, tracked separately)

The same wasm crossgen surfaces a second, independent EH-funclet codegen defect this PR does not address, tracked as #131252: CodeGen::findTargetDepth (codegenwasm.cpp) asserts in DEBUG when a branch target isn't found in the control-flow stack, but release falls through to return ~0;, shipping 0xFFFFFFFF as a branch depth (e.g. V8: invalid branch depth: 4294967295). Observed on System.Threading.Tasks.Parallel.Invoke_0 funclet 1. Distinct root cause (branch-target resolution, not end-emission) and not fixable by the same predicate; both share the pattern of an EH-funclet codegen gap caught only by a checked-only assert that is compiled out in release.

Related issues

• Wasm / R2R: malformed wasm (missing function-body end opcode) for try / throwing-finally pattern in b51875 #129335 — incomplete predecessor (same defect class, does not cover the EH-funclet-with-no-return-tail shape).
• Wasm R2R: emit trailing end after retless BBJ_CALLFINALLY #129449 — added the genCallFinally site that shares this predicate.
• [wasm] crossgen2 ships an invalid branch depth (~0) for EH funclets whose branch target isn't on the wasm control-flow stack #131252 — sibling wasm EH-funclet defect (invalid branch depth), separate root cause.

Note

This PR was created with the help of GitHub Copilot.

[azure-pipelines]

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

[Copilot]

Pull request overview

This PR fixes WebAssembly R2R codegen for CoreCLR by ensuring wasm function bodies always end with the required terminal end opcode, even when generating EH funclets whose last block ends in a no-return tail call and the global bbNext order doesn’t reflect the per-funclet boundary.

Changes:

• Introduce a shared helper (CodeGen::genIsLastBlockOfCurrentFunc) to reliably detect the last block of the currently generated wasm function/funclet.
• Route wasm end-emission decisions in genFuncletEpilog and retless genCallFinally through the new helper.
• Update wasm-specific end-emission checks in genEmitEndBlock (in codegenlinear.cpp) to use the consolidated predicate.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
src/coreclr/jit/codegenwasm.cpp	Adds genIsLastBlockOfCurrentFunc and uses it to decide end emission for funclet epilogs and retless BBJ_CALLFINALLY.
src/coreclr/jit/codegenlinear.cpp	Replaces wasm-specific “last block” checks with the consolidated helper when deciding to emit function terminators.
src/coreclr/jit/codegen.h	Declares the new wasm-only helper on CodeGen.

[azure-pipelines]

Azure Pipelines:
Successfully started running 6 pipeline(s).
10 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]

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

[AndyAyersMS]

a funclet's last block can be followed by an interspersed root throw-helper block

If what's stated here is correct, this is the actual bug: root method blocks should not be interspersed with funclet blocks. Seems odd that this fix works. Maybe it's an unreachable throw helper block?

[lewing]

a funclet's last block can be followed by an interspersed root throw-helper block

If what's stated here is correct, this is the actual bug: root method blocks should not be interspersed with funclet blocks. Seems odd that this fix works. Maybe it's an unreachable throw helper block?

I'll do a deeper pass and try to get the full trace, it is trickier when the code doesn't validate. The code does validate and run after the change.

[AndyAyersMS]

a funclet's last block can be followed by an interspersed root throw-helper block

If what's stated here is correct, this is the actual bug: root method blocks should not be interspersed with funclet blocks. Seems odd that this fix works. Maybe it's an unreachable throw helper block?

I'll do a deeper pass and try to get the full trace, it is trickier when the code doesn't validate. The code does validate and run after the change.

The "trick" we're relying on for layout is a specialized reverse post-order (RPO) traversal of the flow graph. In particular, all funclet and main method blocks should end up adjacent to one another with no interleaving. I thought I had added an assert checking that but looks like I didn't.

There is a bunch of special casing in VisitWasmSuccs to handle throw helpers, which are disconnected blocks at the time we run layout. We have to anticipate where flow might come from. Suspect perhaps this is where the bug arises.

[AndyAyersMS]

Is this vs main or picking up some of the in-progress PRs (in particular async?)

Async adds in some new flow cases that makes layout more complicated (we can branch from method entry into the middle of various things like loops and trys).

[lewing]

Superseded by #131279, which fixes the root cause in wasm block layout rather than the symptom here.

This PR hardened the terminal-end emission (the effect). #131279 fixes the cause: FgWasm::VisitWasmSuccs attaches a throw helper to a try side-entry via the purely-lexical bbInTryRegions enclosing-try match added in #130945, without checking that the helper and the side-entry share the same function region (funclet). That pulls a main-method throw helper into a handler funclet's RPO, dropping the funclet's terminal end. #131279 gates that attach on same-funclet ownership, so the invalid layout is never produced. Validated on the same repro (standalone System.Data.Common R2R wasm) with this end-emission change absent.

Closing in favor of #131279.

Note

This comment was authored with the assistance of GitHub Copilot.