[cDAC][wasm] Decode R2R variable locations and expose function identity - #133890

…ish (#134689)

## Summary

Pass `--strip-debug-info` to crossgen2 for CoreCLR browser-wasm
ReadyToRun publish. This drops the R2R `DebugInfo` section (native-to-IL
offset maps and variable locations) from shipped images. Opt out with
`PublishReadyToRunStripDebugInfo=false` to keep the data for debugging
R2R code (e.g. the cDAC work in #133086 / #133890).

Also makes crossgen2 argument changes invalidate per-app R2R images.
`_CreateR2RImages` only tracks file inputs, so toggling
`PublishReadyToRunStripDebugInfo` (or any
`PublishReadyToRunCrossgen2ExtraArgs` change) previously left stale
images in `obj/R2R`. The arguments are now written to
`obj/wasm-r2r-args.stamp` (only when different) and added to
`_ReadyToRunCompilerInputs`, mirroring the existing P/Invoke manifest
input.

> [!IMPORTANT]
> Stacked on #134618, which rewrites the same targets file. Retarget to
`main` after it merges.

## Size impact

Per-assembly R2R images compiled directly with crossgen2 using the SDK's
browser-wasm arguments (`--obj-format:wasm --opt-cross-module:*
--codegenopt:JitWasm*NyiToR2RUnsupported=1`), with and without
`--strip-debug-info`. Total for System.Private.CoreLib,
System.Text.Json, System.Linq, and System.Collections:

| Compiler | Raw saved | gzip -9 saved | brotli -q 11 saved |
| --- | --- | --- | --- |
| Current (#134618 base) | 859,712 B (2.4%) | 624,690 B (7.1%) | 565,366
B (9.4%) |
| With #133086 variable info | 2,105,520 B (5.6%) | 1,332,733 B (13.9%)
| 1,121,574 B (17.0%) |

<details>
<summary>Per-assembly brotli sizes (bytes, keep → strip)</summary>

| Assembly | Current | With #133086 |
| --- | --- | --- |
| System.Private.CoreLib | 4,822,231 → 4,347,541 | 5,331,799 → 4,403,849
|
| System.Text.Json | 823,314 → 761,533 | 887,982 → 754,444 |
| System.Linq | 219,177 → 200,471 | 238,853 → 200,441 |
| System.Collections | 119,635 → 109,446 | 130,742 → 109,068 |

The #133086 compiler is based on an older commit, so compare keep vs.
strip within a column rather than across columns.
</details>

## Validation

- MSBuild evaluation: `--strip-debug-info` is present by default, absent
with `PublishReadyToRunStripDebugInfo=false`, and absent when
`PublishReadyToRun` is off.
- Incremental harness: `_CreateR2RImages` runs on first build, skips
when unchanged, reruns on opt-out, skips when repeated, and reruns when
switching back.
- Not yet run: an end-to-end browser-wasm publish loading stripped
images in a browser (Wasm.Build.Tests in CI will cover this).

Runtime-pack framework R2R images (used only by the dev-loop build) are
unchanged; publish recompiles the whole closure through these targets.
`--strip-inlining-info` is intentionally not included: it removes
`CrossModuleInlineInfo`, and cross-module inlining is load-bearing on
wasm, so it needs separate validation.

> [!NOTE]
> This pull request was created with assistance from GitHub Copilot.

---------

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

## Summary

Fix cDAC live resolution of WebAssembly ReadyToRun virtual IPs by
matching the runtime's existing lookup model:

- expose `ExecutionManager::s_pVirtualIPRangeList` and
`VirtualIPRangeSection` through the data descriptor;
- resolve encoded virtual IPs through that intrusive list using cycle
detection and a 65,536-node per-lookup reader resource budget, with no
map fallback when an encoded VIP is absent;
- mask the WebAssembly funclet flag from `RUNTIME_FUNCTION.BeginAddress`
for ordering and address arithmetic while preserving funclet identity;
- keep the virtual code base (`MinVirtualIP`) separate from the
loaded-image base used for unwind, debug, GC, exception, and thunk RVA
reads;
- handle the actual WASM descriptor shape, where hot/cold metadata and
delay-load thunk metadata are absent;
- classify WASM filter funclets by mapping the executable filter entry
to its containing runtime function.

## Root cause

The model added in #130988 was already false when that PR merged. On
`TARGET_WASM`, ReadyToRun modules are not added to `RangeSectionMap`;
`ReadyToRunInfo::RegisterVirtualIPRange` registers them in
`ExecutionManager::s_pVirtualIPRangeList`, and native `FindCodeRange`
checks that list first.

The prior unit test synthesized a `RangeSectionMap` entry with an
address that did not satisfy native `IsVirtualIP`, so it validated a
mock-only model rather than the live runtime layout. This is a
test-model gap, not a reviewer fault. The prior review explicitly noted
that the WebAssembly specifics had not been run locally and should be
added to cDAC CI:
#130988 (review).

## Blast radius and scope

This affects ReadyToRun code on all CoreCLR WebAssembly hosts, including
browser and WASI. Interpreter code is unaffected.

The list lookup, descriptor feature gating, funclet masking, and
image-base separation are inseparable: exposing the list alone would
still throw while reading absent WASM fields, or could return the wrong
method or read RVA data from the synthetic virtual address space.

This PR is independent of #133086 and intentionally excludes variable
producer/decoder work. #133890 depends on this PR for correct shared
code lookup and function identity.

On WASM, `FilterOffset` is the executable filter entry and can follow a
synthetic funclet prolog. cDAC now mirrors the corrected native
classification in #133932 by resolving that entry to its containing
runtime function before comparing funclet starts. The PRs remain
independent; #133917 does not depend on changing the producer offset.

## Validation

- `./build.sh clr+libs+host`
- `PATH="/opt/homebrew/bin:$PATH" ./build.sh -os browser -c Debug
-subset clr+libs`
- cDAC UnitTests: **3162 passed**
- cDAC DataGeneratorTests: **46 passed**
- cDAC UsageTests: **4 passed**
- generated contract documentation check: **up to date**
- focused ExecutionManager / RuntimeFunction / WasmR2R tests: **221
passed**

The durable tests cover:

- captured/live-shaped VIP `0x80010109`, exact `MethodDesc`, module, and
runtime-function index;
- the actual WASM descriptor shape: 8-byte `RUNTIME_FUNCTION` records
with no `EndAddress`, and absent hot/cold and delay-load thunk fields;
- start/end boundaries and adjacent ranges;
- encoded VIP absent from the list with no `RangeSectionMap` fallback;
- self-cycle, two-node cycle, inverted range, null module, and
overlapping ambiguity;
- unrelated partially registered nodes not blocking initialized ranges,
while an uninitialized candidate fails closed;
- valid 1,024/1,025-node lists, exact 65,536-node budget success, and
budget+1 fail-closed behavior even when the head matches, with a read
counter proving the extra node is never dereferenced;
- root/funclet resolution with a flagged funclet entry that breaks raw
ordering;
- exact loaded-image debug, unwind, GC, and exception-clause reads while
entrypoint lookup uses `MinVirtualIP`;
- filter-funclet classification where `FilterOffset` follows the flagged
funclet start but resolves to the same containing runtime function;
- missing list capability and unchanged ordinary architecture behavior.

Mutation proofs were applied, confirmed in source, run red, restored,
and rerun green:

1. Removing the VIP-list branch fails the captured `0x80010109` test at
the exact code-block assertion.
2. Using raw `BeginAddress` fails the funclet identity test.
3. Using `startVIP` as the loaded-image base fails the GC/unwind test
with a read at `0x80010081` instead of the loaded image.
4. Raising the reader budget from 65,536 to 65,537 makes the budget+1
test fail at its read-boundary assertion (highest node index 65,536
instead of 65,535); restoring the budget returns the suite to green.
5. Replacing WASM filter-entry containing-function resolution with raw
`FilterOffset == funcletStartOffset` comparison makes the filter
regression fail with expected `true` and actual `false`.

The finite list cutoff is an intentional diagnostic-reader resource
policy, not a native registration limit or a claim that an over-budget
list is corrupt.

> [!NOTE]
> This pull request description was generated with GitHub Copilot.

---------

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

…rtual IPs (#134756)

> [!IMPORTANT]
> Stacked on #134754 (targets its branch). Only the commits above
#134754's head belong to this PR; retarget to `main` once #134754
merges.

## Problem

On `FEATURE_PORTABLE_ENTRYPOINTS` targets (WebAssembly), a method's
entry point slot holds a `PortableEntryPoint` address. Native maps it
before handing it to diagnostics
(`GetInterpreterCodeFromEntryPointIfPresent` /
`GetDiagnosticCodeStartFromEntryPoint` in `precode.cpp`), but the cDAC
returned the raw address. SOS values such as
`DacpMethodDescData.NativeCodeAddr` and rejit `NativeCodeAddr`, plus the
DBI/`ClrDataMethodInstance` paths, therefore reported an address that
doesn't resolve through `ExecutionManager` for both interpreted and R2R
methods.

## Change

Adds `IExecutionManager.GetDiagnosticCodeStartFromEntryPoint`, which
mirrors the native `GetDiagnosticCodeStartFromEntryPoint`:

- **Without portable entrypoints:** delegates to
`PrecodeStubs.GetInterpreterCodeFromInterpreterPrecodeIfPresent`.
Behavior is unchanged.
- **With portable entrypoints:**
1. Returns the address unchanged if it lies in a code range. This is the
native `FindCodeRange` check and includes Wasm R2R virtual-IP ranges
from #133917.
  2. Maps interpreted methods to `MethodDesc::m_interpreterCode`.
3. Maps native R2R methods from the function-table index in
`PortableEntryPoint._pActualCode` to the synthetic virtual IP, stepping
back past funclet entries. This matches
`ExecutionManager::GetWasmVirtualIPFromFunctionTableIndex`. As in native
code, it applies only to the method's own (temporary) entry point, and
only when the entry point doesn't prefer the interpreter.

The mapping lives in ExecutionManager rather than PrecodeStubs because
ExecutionManager owns the virtual-IP ranges and R2R lookup.
ExecutionManager already depends on PrecodeStubs, so this adds no
contract cycle.

Function-table-index resolution moves into
`ExecutionManagerHelpers.WasmFunctionTableIndexLookup`, which now bounds
the list walk and detects cycles, like the virtual-IP list walk. The
stack walk's `WasmR2RInfo` becomes a thin wrapper over it.

The Legacy SOS/DBI callers (`SOSDacImpl`, `ClrDataMethodInstance`,
`DacDbiImpl`) now call the new API. `DacDbiImpl.EnumerateAsyncLocals`
also maps its code address before querying async debug info. The native
DAC's `EnumerateAsyncLocals` gets the matching
`GetInterpreterCodeFromEntryPointIfPresent` mapping (as
`GetMethodVarInfo` already does), so the debug-build cDAC/DAC
cross-check stays consistent.

### Data descriptors

- `PortableEntryPoint.ActualCode` and `PortableEntryPoint.Flags` (only
under `FEATURE_PORTABLE_ENTRYPOINTS`).
- `MethodDesc.InterpreterCode` (only under `FEATURE_INTERPRETER`).
- The contract relies on `kPrefersInterpreterEntryPoint` and
`INTERPRETER_CODE_POISON`; the native side now has `[cDAC]` comments
marking that dependency.

### Interaction with #133890

#133890 adds `TryGetFunctionIdentity` and `TryIsFunclet` to
`WasmR2RInfo`. Whichever PR lands second should add those two methods to
`WasmFunctionTableIndexLookup` and have `WasmR2RInfo` forward to them.
The `FunctionTableIndexRange*` descriptor meanings here already use
#133890's exact wording, so that JSON should merge cleanly.

## Validation

- cDAC: `./build.sh -s tools.cdac+tools.cdactests -c Debug -test`
passes: 3196 unit tests (17 new), usage tests (contract cycles and
generated docs up to date), and generator tests.
- New ExecutionManager tests cover:
- interpreted, R2R, funclet, poison, prefers-interpreter,
not-own-entry-point and unknown-index cases;
- an end-to-end check that the resolved virtual IP maps back to the
MethodDesc through `GetCodeBlockHandle`;
- readable `PortableEntryPoint`-shaped bytes inside a registered code
range staying unchanged. This test fails if the range check is removed.
  - a cyclic function-table range list;
  - the non-portable delegation path.
- CoreCLR `clr.runtime` builds for osx-arm64 Debug (with
`FEATURE_INTERPRETER`) and browser-wasm Debug. The generated wasm
descriptor has `PortableEntryPoint {ActualCode@0, MethodDesc@4,
Flags@12}`.
- A new `DacDbiImplTests` test covers `EnumerateAsyncLocals` mapping for
both the code-address and MethodDesc paths. It fails without the fix.
- cDAC dump tests (osx-arm64, local runtime): 260 passed, 0 failed. The
746 skips are net10.0 configurations plus by-design skips (Windows-only
COM debuggees, and dump types a debuggee doesn't produce).
- CoreCLR `clr.runtime` Release (osx-arm64) builds with the
`dacdbiimpl.cpp` change.
- Not run: any check against a live wasm target.

Fixes #134753

> [!NOTE]
> This PR description was generated with GitHub Copilot.

---------

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

…rtual IPs (#134827)

This replaces #134756, which was merged into #134754's branch by mistake
and reverted there. The change is otherwise identical (cherry-picked
onto `main`).

## Problem

On `FEATURE_PORTABLE_ENTRYPOINTS` targets (WebAssembly), a method's
entry point slot holds a `PortableEntryPoint` address. Native maps it
before handing it to diagnostics
(`GetInterpreterCodeFromEntryPointIfPresent` /
`GetDiagnosticCodeStartFromEntryPoint` in `precode.cpp`), but the cDAC
returned the raw address. SOS values such as
`DacpMethodDescData.NativeCodeAddr` and rejit `NativeCodeAddr`, plus the
DBI/`ClrDataMethodInstance` paths, therefore reported an address that
doesn't resolve through `ExecutionManager` for both interpreted and R2R
methods.

## Change

Adds `IExecutionManager.GetDiagnosticCodeStartFromEntryPoint`, which
mirrors the native `GetDiagnosticCodeStartFromEntryPoint`:

- **Without portable entrypoints:** delegates to
`PrecodeStubs.GetInterpreterCodeFromInterpreterPrecodeIfPresent`.
Behavior is unchanged.
- **With portable entrypoints:**
1. Returns the address unchanged if it lies in a code range. This is the
native `FindCodeRange` check and includes Wasm R2R virtual-IP ranges
from #133917.
  2. Maps interpreted methods to `MethodDesc::m_interpreterCode`.
3. Maps native R2R methods from the function-table index in
`PortableEntryPoint._pActualCode` to the synthetic virtual IP, stepping
back past funclet entries. This matches
`ExecutionManager::GetWasmVirtualIPFromFunctionTableIndex`. As in native
code, it applies only to the method's own (temporary) entry point, and
only when the entry point doesn't prefer the interpreter.

The mapping lives in ExecutionManager rather than PrecodeStubs because
ExecutionManager owns the virtual-IP ranges and R2R lookup.
ExecutionManager already depends on PrecodeStubs, so this adds no
contract cycle.

Function-table-index resolution moves into
`ExecutionManagerHelpers.WasmFunctionTableIndexLookup`, which now bounds
the list walk and detects cycles, like the virtual-IP list walk. The
stack walk's `WasmR2RInfo` becomes a thin wrapper over it.

The Legacy SOS/DBI callers (`SOSDacImpl`, `ClrDataMethodInstance`,
`DacDbiImpl`) now call the new API. `DacDbiImpl.EnumerateAsyncLocals`
also maps its code address before querying async debug info. The native
DAC's `EnumerateAsyncLocals` gets the matching
`GetInterpreterCodeFromEntryPointIfPresent` mapping (as
`GetMethodVarInfo` already does), so the debug-build cDAC/DAC
cross-check stays consistent.

### Data descriptors

- `PortableEntryPoint.ActualCode` and `PortableEntryPoint.Flags` (only
under `FEATURE_PORTABLE_ENTRYPOINTS`).
- `MethodDesc.InterpreterCode` (only under `FEATURE_INTERPRETER`).
- The contract relies on `kPrefersInterpreterEntryPoint` and
`INTERPRETER_CODE_POISON`; the native side now has `[cDAC]` comments
marking that dependency.

### Interaction with #133890

#133890 adds `TryGetFunctionIdentity` and `TryIsFunclet` to
`WasmR2RInfo`. Whichever PR lands second should add those two methods to
`WasmFunctionTableIndexLookup` and have `WasmR2RInfo` forward to them.
The `FunctionTableIndexRange*` descriptor meanings here already use
#133890's exact wording, so that JSON should merge cleanly.

## Validation

- cDAC: `./build.sh -s tools.cdac+tools.cdactests -c Debug -test`
passes: 3196 unit tests (17 new), usage tests (contract cycles and
generated docs up to date), and generator tests.
- New ExecutionManager tests cover:
- interpreted, R2R, funclet, poison, prefers-interpreter,
not-own-entry-point and unknown-index cases;
- an end-to-end check that the resolved virtual IP maps back to the
MethodDesc through `GetCodeBlockHandle`;
- readable `PortableEntryPoint`-shaped bytes inside a registered code
range staying unchanged. This test fails if the range check is removed.
  - a cyclic function-table range list;
  - the non-portable delegation path.
- CoreCLR `clr.runtime` builds for osx-arm64 Debug (with
`FEATURE_INTERPRETER`) and browser-wasm Debug. The generated wasm
descriptor has `PortableEntryPoint {ActualCode@0, MethodDesc@4,
Flags@12}`.
- A new `DacDbiImplTests` test covers `EnumerateAsyncLocals` mapping for
both the code-address and MethodDesc paths. It fails without the fix.
- cDAC dump tests (osx-arm64, local runtime): 260 passed, 0 failed. The
746 skips are net10.0 configurations plus by-design skips (Windows-only
COM debuggees, and dump types a debuggee doesn't produce).
- CoreCLR `clr.runtime` Release (osx-arm64) builds with the
`dacdbiimpl.cpp` change.
- Re-validated after cherry-picking onto `main`: `./build.sh clr -c
Debug` (osx-arm64) builds, and `./build.sh -s tools.cdac+tools.cdactests
-c Debug -test` passes (3196 unit tests, 46 generator tests, 4 usage
tests; 0 failed).
- Not run: any check against a live wasm target.

Resolves #134753

> [!NOTE]
> This PR description was generated with GitHub Copilot.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

## Summary

Fixes a GC hole during exception dispatch in Wasm R2R code. It shows up
in CI as a rare `SanityCheck()` assert in nested EH tests on the
browser-wasm R2R leg, for example `Test_throwinfinallynestedintry_30`.

## Root cause

Wasm R2R code has no interruptible ranges, and it reports every GC ref
on the frame as an untracked (pinned) slot. A method and its funclets
share those frame slots.

When an exception is thrown from a funclet, that funclet's frame is
`ExecutionAborted`. `GcInfoDecoder::EnumerateLiveSlots` finds no
interruptible range covering the offset and returns without reporting
anything, including the untracked slots. The parent frames (the caller
of an out-of-line finally, and the main method body) are skipped as
already reported by the funclet.

So during dispatch nothing reports the method's untracked slots. A GC in
that window can free an object still held in one of them. In the repro
it's a boxed `Int32`. The next time the slot is reported, it points at
freed memory and hits `SanityCheck()`.

Other targets avoid this in the JIT.
`CodeGenInterface::setFramePointerRequiredEH` forces every method with
EH to be fully interruptible, because `EnumGcRefs` only reports slots in
aborted frames that are fully interruptible. Wasm is explicitly excluded
there, and Wasm R2R code can't be fully interruptible.

## Fix

Add a `HAS_INTERRUPTIBLE_RANGES` trait to each `GcInfoEncoding`, `false`
only for `Wasm32GcInfoEncoding`.

- `EnumerateLiveSlots` skips the interruptible-range handling for that
encoding and reports only untracked slots outside safe points, including
for aborted frames.
- The count of interruptible ranges is no longer serialized for that
encoding. The encoder, the runtime decoder, the cDAC decoder and R2RDump
all skip it, and `DefineInterruptibleRange` asserts it's never used for
that encoding.
- There's no R2R version bump: Wasm hasn't shipped, so Wasm-specific
format changes don't need one.

The gate is on the encoding rather than `TARGET_WASM`: on Wasm the
interpreter's GC info goes through the same decoder, and interpreter
code does define an interruptible range. Native targets are unchanged.

The cDAC `GCInfoDecoder` mirrors the change through the same trait
(default `true`), and `docs/design/datacontracts/GCInfo.md` documents
it. `main` has no Wasm32 GC info traits in the cDAC yet; #133890 adds
them.

I fixed this in the decoder rather than having the JIT declare Wasm
methods interruptible over their whole range. That claim isn't true for
Wasm, and other checks rely on it (GC stress, the safe-point asserts).

## Size

On browser-wasm `System.Private.CoreLib.wasm` (CI crossgen options),
omitting the count saves 1,088 bytes (0.003%). A GC info blob only
shrinks when the 2 saved bits cross a byte boundary (11,606 of 58,253
methods), and identical blobs are shared (5,331 distinct unwind entries
across 60,323 methods and funclets).

## Validation

I ran the CI Helix payload for `Methodical_d1` from build 1613981
locally, with crossgen2 built from this branch and a browser-wasm
`corerun` built with and without the fix. For the final format I
recompiled CoreLib and the test assemblies with this branch's crossgen2.

| | Without fix | With fix |
|---|---|---|
| `Test_throwinfinallynestedintry_30`, `DOTNET_GCStress=0x1` | same
`SanityCheck()` assert as CI, every run | pass |
| `throwincascadedexcept_d`, `throwincascadedexceptnofin_d`,
`DOTNET_GCStress=0x1` | assert, then timeout | pass |
| `Methodical_d1` merged runner, no stress | 128 passed | 128 passed,
same results |

- Native osx-arm64 and browser-wasm checked builds pass.
- R2RDump and the cDAC unit tests pass (3179/3179).
- The final format gives the same no-stress results as a control that
still writes and reads the count.
- All 84 `Methodical_d1` assemblies, R2R-compiled with the checked Wasm
JIT, never hit the new encoder assert.
- In every full run, the same 18 out-of-process tests fail because my
local runner doesn't handle out-of-process tests.
- The final revert of the version bump only restores `readytorun.h` and
the two `ModuleHeaders` files to `main`; it wasn't rebuilt.

With this fix, the full `Methodical_d1` suite under
`DOTNET_GCStress=0x1` was clean in 3 of 4 runs. The 4th hit a
`RawGetMethodTable()` assert in `throw_SEH`. That's a separate,
pre-existing hole, #134777: `CallDescrWorkerInternal` leaves the call's
arguments unreported while `DoPrestub` runs. It reproduces identically
with and without this change and is fixed in #134779. With both fixes,
the full suite under stress passed 4 of 4 runs (126 passed), in a run
before the count was removed from the format.

I also checked native (osx-arm64, release 11.0 rc1 runtime, FullOpts
JIT) with a small app. An object is held only in an address-exposed
local, a `finally` throws, and the same method catches it with a filter
that forces a GC. The object stayed alive 20/20 times, and JitDisasm
shows the method as `; fully interruptible`, as
`setFramePointerRequiredEH` requires.

CI doesn't run GC stress on the Wasm R2R leg, which is why this showed
up as a ~0.5% flake rather than a hard failure.

Resolves #134768

> [!NOTE]
> This PR description was drafted with GitHub Copilot.

---------

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

… section (#135059)

Native `ReadyToRunInfo::GetDebugInfo`
(`src/coreclr/vm/readytoruninfo.cpp`) returns `NULL` immediately when
`m_pSectionDebugInfo == NULL`. The cDAC mirror,
`ReadyToRunJitManager.GetDebugInfo`, dereferenced
`ReadyToRunInfo.DebugInfoSection` without that check and built a
`NativeArray` from whatever was at address 0.

This now matters because #134690 makes Browser/WASI ReadyToRun publishes
pass `--strip-debug-info` by default, including CoreLib and the
framework. iOS, tvOS, and MacCatalyst already default to it. On wasm,
linear address 0 is readable, so cDAC decoded garbage. A live run
against a stripped browser image threw `BadImageFormatException: offset
out of bounds` (`NativeReader.DecodeUnsigned` ← `NativeArray..ctor` ←
`ReadyToRunJitManager.GetDebugInfo` ← `DebugInfo_1.GetMethodVarInfo`)
instead of reporting that there was no debug info. On native targets,
the same path fails with a read exception.

## Changes

- `ReadyToRunJitManager.GetDebugInfo` returns `TargetPointer.Null` (with
`hasFlagByte = false`) when `DebugInfoSection` is null, matching native.
- `docs/design/datacontracts/ExecutionManager.md`: the R2R
`GetDebugInfo` description now includes the null-section early return.
- No caller changes were needed. `DebugInfo_1.HasDebugInfo`,
`GetMethodNativeMap`, `GetMethodVarInfo`, and `GetAsyncSuspensionPoints`
already treat a null debug-info pointer as "no debug info". The two
map/var methods still compute `codeOffset`.

## Tests

New test
`ExecutionManagerTests.GetDebugInfo_R2R_NoDebugInfoSection_ReturnsNull`
runs as a `[Theory]` over `StdArchAllVersions` (4 arch cases). It builds
an R2R module whose `DebugInfoSection` is null and makes the low 4 KB of
the address space readable as zeros, the way wasm linear memory is, so
the unfixed code decodes instead of hitting a read fault. It asserts
that:
- `IExecutionManager.GetDebugInfo` returns `TargetPointer.Null` and
`hasFlagByte == false`
- `IDebugInfo.HasDebugInfo` is `false`
- `GetMethodVarInfo` and `GetMethodNativeMap` return empty sequences
with `codeOffset == 4`

Results:
- `./build.sh -s tools.cdactests -test`: passed. UnitTests 3236/3236,
DataGeneratorTests 46/46, UsageTests 4/4 (no stale generated docs).
- `./.dotnet/dotnet test src/native/managed/cdac/tests/UnitTests
--filter "FullyQualifiedName~GetDebugInfo_R2R_NoDebugInfoSection"`:
passed, 4/4.
- Mutation check: I removed the null check and reran the same filtered
command. It failed 4/4 with `System.BadImageFormatException : offset out
of bounds` at `NativeReader.DecodeUnsigned` ← `NativeArray..ctor` ←
`ReadyToRunJitManager.GetDebugInfo`, the same failure as the live wasm
run. With the fix restored, it passes 4/4.

This PR has a single concern. It leaves wasm stack-walk and
variable-location work to #133890, #135044, and #135055.

> [!NOTE]
> This PR description was generated with GitHub Copilot.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

…35044)

Fixes four cDAC failures found by walking stacks on a live CoreCLR
browser-wasm target (nightly `12.0.0-alpha.1.26480.103`) through
`IStackWalk`. On `main`, the walk fails on its first step, or never
ends, and no MethodDesc can be named.

## Changes

**MethodDesc validation rejects every MethodDesc (#135035).** With
`FEATURE_PORTABLE_ENTRYPOINTS`, the runtime has no precode stubs and
doesn't describe `PrecodeMachineDescriptor`, so constructing
`PrecodeStubs` threw. `MethodValidation` swallowed the exception and
reported every MethodDesc as invalid.
- New `PrecodeStubs` version `c2` (`PrecodeStubs_2`) for portable entry
points. `GetMethodDescFromStubAddress` reads
`PortableEntryPoint.MethodDesc`, matching native
`MethodDesc::GetMethodDescFromPrecode`. The runtime advertises `c2`
under `FEATURE_PORTABLE_ENTRYPOINTS`, and `PrecodeStubs_1` is unchanged.

**Stack walks require the Debugger contract (#135034).** WASM didn't
advertise `Debugger`, but `StackWalk_1` calls it for every
native-context frame.
- WASM now advertises the existing `Debugger` `c1` contract. The
in-process debugger isn't built there, so `g_pDebugger` stays null and
`CLRJitAttachState` stays 0. `Debugger_1` already reports that as "not
initialized": no debugger data, no hijacks.
- The mistyped `int g_pDebugger` linker stub is replaced with correctly
typed definitions.

**Walk never ends on an R2R InlinedCallFrame (#135036).**
`WasmFrameHandler` now handles the `INLINED_PINVOKE_FROM_R2R` marker as
native `InlinedCallFrame::UpdateRegDisplay_Impl` does. SP comes from
`CallSiteSP`, IP is the R2R virtual IP of the shadow frame there, and FP
is that frame's base. The frame pointer doesn't account for funclets
yet; that comes with #133890. If an active InlinedCallFrame's context
still isn't managed code (no virtual IP could be recovered), the walk
fails with `StackWalkState.Error`, as native `NextRaw` returns
`SWA_FAILED`, rather than repeating.

**Interpreter-only walk repeats forever (#135037).** This now matches
native `StackFrameIterator`:
- An active InlinedCallFrame for an interpreted P/Invoke
(`InlinedCallFrame::IsInInterpreter`) moves straight to the
InterpreterFrame that owns it, without touching the context.
- A walk that starts in interpreted code moves the Frame cursor to the
`Next` of the owning InterpreterFrame named in the first-argument
register, as native `Init`/`ResetRegDisp` do. If the register is null or
doesn't name an InterpreterFrame, the walk throws, where native asserts.

The `StackWalk.md`, `PrecodeStubs.md` (new Version 2 section) and
`Debugger.md` specs are updated, and the generated usage tables are
regenerated.

WASM isn't a shipping cDAC scenario for .NET 11, so readers built from
this PR don't support WASM runtimes built before it: those don't
advertise `Debugger` and still advertise `PrecodeStubs` `c1` with
portable entry points.

Follow-up: moving the ExecutionManager portable-entry-point special
cases (`NonVirtualEntry2MethodDesc`,
`GetDiagnosticCodeStartFromEntryPoint`) next to `PrecodeStubs_2`. I've
left that out of this PR to avoid colliding with #133890's
ExecutionManager changes.

## Validation

- `./dotnet.sh test
src/native/managed/cdac/tests/UnitTests/Microsoft.Diagnostics.DataContractReader.Tests.csproj`:
**passed**, 3245/3245.
- `pwsh src/native/managed/cdac/tools/CdacUsageGraph/generate-docs.ps1
-Check`: **passed**, docs up to date.
- `./build.sh -os browser -c Debug -subset clr.runtime`: **passed**. The
generated WASM contract descriptor advertises `Debugger` `c1` with its
globals and `PrecodeStubs` `c2`.
- `./build.sh -os browser -subset clr+libs+packs -c Release
/p:BuildCrossgen2HostPackForWorkloadTesting=true`: **passed**. These are
the packs used for the live run below.
- New tests:
  - portable entry point lookup through `c2`;
  - the R2R InlinedCallFrame virtual IP;
- a WASM walk ending, with the `Debugger` contract advertised and a null
`g_pDebugger`;
- an interpreted P/Invoke chain walked once from both kinds of starting
point.

The tests from the original fixes each failed with the corresponding fix
removed. I didn't repeat that check after the review changes. The throw
for a missing owning InterpreterFrame has no dedicated test.
- Live browser-wasm runs at `289085e0e06` (before the last review round
removed the older-runtime fallbacks) through Blazor-Playground/nesm,
with nesm's workarounds and its frame guard turned off. Five configs, 5
walks each: R2R paused at a breakpoint (seeded from the frame chain and
from a leaf `$sp`), R2R paused in a `[JSImport]` call, and
interpreter-only paused in a tight loop and in a `[JSImport]` call.
- Against nightly `12.0.0-alpha.1.26480.103`, which advertises no
`Debugger` contract and `PrecodeStubs` `c1`, so the since-removed
fallback paths ran: **all pass**.
- Against Release packs built from this branch, which advertise
`Debugger` `c1` and `PrecodeStubs` `c2`: **all pass**. Frame names,
states and kinds match the nightly run exactly, and nesm's own
`Debugger` and `PrecodeStubs` workarounds are never called.
- In every run, walks complete with no errors and every frame is named.
The R2R names match a separate static ReadyToRun lookup.
- Live re-run at the current head `b996b7187da` with the same branch
packs (the runtime code is unchanged since `289085e0e06`), nesm
workarounds and frame guard off: R2R paused at a breakpoint (all seeds)
and interpreter-only paused in a `[JSImport]` call **pass**, including
the interpreted-code seed that now requires the owning InterpreterFrame.
Against the nightly, the reader fails with `ContractMissingException`
(`Debugger`) unless nesm's workarounds are on, as expected now that
older WASM runtimes aren't supported.

`TestPlaceholderTarget.TryGetThreadContext` now returns `false` (no OS
context, as on WASM) instead of throwing, so tests can exercise the
walk's fallback to the Frame chain.

Resolves #135034
Resolves #135035
Resolves #135036
Resolves #135037

> [!NOTE]
> This PR description was generated with assistance from GitHub Copilot.

---------

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Adapted from #133890: add IWasmR2RInfo.TryIsFunclet and
WasmUnwinder.TryGetLogicalFramePointer, mirroring native
GetWasmFramePointerFromStackPointer, and set WasmContext.FramePointer
to the establishing method's frame base after each unwind.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>