gc(windows): RtlVirtualUnwind native-root stack walker — PERRY_RS4GC works on x86-64 Windows (#7354) - #7355
Merged
Merged
Conversation
…works on x86-64 Windows (#7354) The COFF `.pgcmap` section and its PE lookup existed (#7351) but Windows had no stack walker — `_Unwind_*` does not exist there — so RS4GC was refused for every COFF target. This adds the missing walker and enables the platform: - `gc/roots/stack_maps.rs`: `#[cfg(windows, x86_64)] mod unwind` steps a hand-declared `CONTEXT` (layout pinned by compile-time offset asserts) outward with RtlLookupFunctionEntry + RtlVirtualUnwind. SP-relative roots read the frame's real Rsp — no CFA derivation. Fail-closed: only Win64 nonvolatile base registers are trusted, every slot is bounded by GetCurrentThreadStackLimits, a frame without unwind info or a non-outward step ends the walk. - exception.rs: the unguarded `eh_walker` calls (Itanium-only module) broke the whole Windows build of perry-runtime; now `#[cfg(not(windows))]`. - gc_map.rs: the COFF refusal narrows to non-x86-64 (ARM64 Windows still has no walker and must stay refused); `windows_is_refused_until_it_has_a_walker` replaced by `x86_64_windows_is_no_longer_refused` + the ARM64 pin. - linker.rs/inprocess.rs: WinEH funclet pads (windows-msvc `try` lowering) crash LLVM's rewrite-statepoints-for-gc outright (0xC0000005, opt 22.1.3, 8-line repro), so RS4GC now refuses funclet modules BEFORE the pass runs, and a failed opt pipeline writes its input IR to disk for reproduction. - gc-native-roots.yml: windows-latest arm (PE section asserts via llvm-readobj, probe 09 pinned as the funclet refusal, and a `--require-locations` walker-liveness telemetry gate). Verified on a real Windows host (opt+clang 22.1.3 one-dir pair, Node 26.5.1 SRI-matched): 9/9 runnable probes byte-match the oracle under PERRY_GC_FORCE_EVACUATE=1 PERRY_GC_VERIFY_EVACUATION=1 with 5.9k-90k objects copied per probe; telemetry shows the walker ran (probe 04: frames_visited=5626, records_matched=5449, locations_visited=22).
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (9)
📝 WalkthroughWalkthroughThe compiler now enables native GC maps for Windows x86-64. The runtime walks Win64 frames with ChangesWindows native GC roots
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant GC
participant native_stack_maps_visit
participant RtlVirtualUnwind
participant StackMapIndex
GC->>native_stack_maps_visit: Request native root enumeration
native_stack_maps_visit->>RtlVirtualUnwind: Capture and unwind current frame
RtlVirtualUnwind-->>native_stack_maps_visit: Return frame registers and stack pointer
native_stack_maps_visit->>StackMapIndex: Match instruction pointer to records
StackMapIndex-->>native_stack_maps_visit: Return root locations
native_stack_maps_visit-->>GC: Visit validated root slots and telemetry
Possibly related issues
Possibly related PRs
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
proggeramlug
added a commit
that referenced
this pull request
Aug 4, 2026
`cargo fmt --all -- --check` exits 1 on main HEAD (7428437). One file: `crates/perry-codegen/src/linker.rs`, where `rs4gc_funclet_refusal`'s needle array crossed the width that makes rustfmt break it vertically. `lint` is a REQUIRED context. A required check that is red on main does not block anything -- it means every subsequent merge is a bypass, which is the hazard CLAUDE.md lists and that this repo has already paid for once (lint sat red across three nightlies on 16 oversized files, and every merge in that window went in unchecked). No behavior change: whitespace only. Claude-Session: https://claude.ai/code/session_01EaD6yNwoinzdW1JbYNkMMF Co-authored-by: Ralph Küpper <ralph@skelpo.com>
proggeramlug
added a commit
that referenced
this pull request
Aug 4, 2026
…tform matrix (#7367) The plan still said statepoints were aarch64-only (#7321), that the matrix "therefore runs on macos-14", that `statepoints-refuse-x86` pinned the refusal, and it spelled the knob `PERRY_STATEPOINTS` four times. None of that is true now, and this document is what the adoption decision gets made from. What actually changed: - x86-64 is unblocked. `_Unwind_GetGR(ctx, 7)` does segfault and cannot be fixed as stated -- libgcc tracks only the columns CFI restores and RSP is derived, not tracked. #7349 stopped asking for it and derives the SP-relative base from `_Unwind_GetCFA`, with a per-arch return-address adjustment (x86-64 `call` pushes one, aarch64 `bl` does not). x86-64 Linux is a first-class arm. - Windows works via RtlVirtualUnwind (#7355), the one walker with no Itanium unwinder beneath it. - aarch64+ELF is now covered too (#7360) -- the only shape where LLVM spells 32-bit stack-map fields `.word`. - One mechanism, not two: PERRY_STATEPOINTS and the plain-map bridge are deleted, so the kill-policy line about "a mode that still exists" no longer applies to this pair. - The gate proves something now. Until today the Unix arms reported 7 frames and ZERO locations -- they would have passed with a walker that visited nothing. #7359's deep-collect probe took them to 221 locations. - watchOS/visionOS are not blocked by Perry: they build on stable without `dyn-eval`, and fail three crates away in psm's Mach-O guard. So the remaining adoption gate is `llvm-inprocess` becoming a default cargo feature, plus sequencing step 2 (root density) -- adopting today would regress binary size on root-dense code. Claude-Session: https://claude.ai/code/session_01EaD6yNwoinzdW1JbYNkMMF Co-authored-by: Ralph Küpper <ralph@skelpo.com>
proggeramlug
added a commit
that referenced
this pull request
Aug 4, 2026
…#7369) * fix(lint): split index_set.rs, over the 2000-line cap since #7342 (#7366) `scripts/check_file_size.sh` exits 1 on main HEAD: `crates/perry-codegen/src/expr/index_set.rs` is 2035 lines against a 2000 cap. It crossed in #7342. That script runs inside the `lint` job, which is a REQUIRED context -- so this is the second independent way `lint` was red on main today (the first was rustfmt on linker.rs, #7361). A required check that is red on main blocks nothing; it means every merge is a bypass. The split follows the recipe in the script's own failure message: extract a topical group into a sibling module. `lower_inline_dyn_typed_array_set` and its `emit_inline_ta_int_store` helper are the guarded inline typed-array store for a type-erased receiver -- one coherent unit, moved verbatim to `index_set_typed_array.rs`. index_set.rs drops to 1749 lines, leaving real headroom rather than landing one line under the cap. Mechanical move: the two functions are byte-identical, only the imports they need travelled with them and `lower_inline_dyn_typed_array_set` became `pub(super)` so its one caller can still reach it. cargo test -p perry-codegen --lib: 609 passed. Claude-Session: https://claude.ai/code/session_01EaD6yNwoinzdW1JbYNkMMF Co-authored-by: Ralph Küpper <ralph@skelpo.com> * docs(plan): both statepoint adoption gates are closed; record the platform matrix (#7367) The plan still said statepoints were aarch64-only (#7321), that the matrix "therefore runs on macos-14", that `statepoints-refuse-x86` pinned the refusal, and it spelled the knob `PERRY_STATEPOINTS` four times. None of that is true now, and this document is what the adoption decision gets made from. What actually changed: - x86-64 is unblocked. `_Unwind_GetGR(ctx, 7)` does segfault and cannot be fixed as stated -- libgcc tracks only the columns CFI restores and RSP is derived, not tracked. #7349 stopped asking for it and derives the SP-relative base from `_Unwind_GetCFA`, with a per-arch return-address adjustment (x86-64 `call` pushes one, aarch64 `bl` does not). x86-64 Linux is a first-class arm. - Windows works via RtlVirtualUnwind (#7355), the one walker with no Itanium unwinder beneath it. - aarch64+ELF is now covered too (#7360) -- the only shape where LLVM spells 32-bit stack-map fields `.word`. - One mechanism, not two: PERRY_STATEPOINTS and the plain-map bridge are deleted, so the kill-policy line about "a mode that still exists" no longer applies to this pair. - The gate proves something now. Until today the Unix arms reported 7 frames and ZERO locations -- they would have passed with a walker that visited nothing. #7359's deep-collect probe took them to 221 locations. - watchOS/visionOS are not blocked by Perry: they build on stable without `dyn-eval`, and fail three crates away in psm's Mach-O guard. So the remaining adoption gate is `llvm-inprocess` becoming a default cargo feature, plus sequencing step 2 (root density) -- adopting today would regress binary size on root-dense code. Claude-Session: https://claude.ai/code/session_01EaD6yNwoinzdW1JbYNkMMF Co-authored-by: Ralph Küpper <ralph@skelpo.com> * gc: admit two provably-leaf helpers, and measure that it buys nothing js_gc_register_global_root was the most frequent non-leaf callee in the probe suite (148 call sites) and is provably GC-leaf: its whole body is runtime_write_barrier_root_heap_word -- which js_write_barrier_root_heap_word, already CannotCollect, wraps in one line -- plus a TLS Vec::push. The "malloc count threshold" trigger does not apply to that push: the counter is MALLOC_STATE.objects.len(), a registry of Perry GC objects, and the #[global_allocator] is plain mimalloc/System with no GC hook. js_typed_feedback_maybe_dump_trace joins its already-admitted family siblings. Measured A/B on the same tree, and the result is a null: probe safepoints roots total bytes __text 06_string_retention 105 -> 100 27=27 0 -4 B 09_try_catch_roots 343 -> 339 259=259 0 -4 B 11_collect_at_depth 120 -> 117 36=36 0 -4 B Root counts are IDENTICAL. The 40 safepoints removed across the suite were all rootless, and a rootless safepoint costs essentially nothing -- which is what docs/engine-plan.md already says: "the axis is not 'statepoints are bigger', it is 'roots are bigger'". Recording it as evidence: the safepoint-count lever is not the binary-size lever, so sequencing step 2 must attack live-root SETS. Two tests come with it. One pins the wrapper's classification to the barrier it wraps. The other pins js_nanbox_string OUT of the allowlist: at 120 call sites it is the obvious next candidate and reads as pure bit manipulation, but its null guard calls js_string_from_bytes to allocate an empty string. Probe suite 11/11 byte-identical under forced evacuation + verification. Claude-Session: https://claude.ai/code/session_01EaD6yNwoinzdW1JbYNkMMF --------- Co-authored-by: Ralph Küpper <ralph@skelpo.com>
proggeramlug
added a commit
that referenced
this pull request
Aug 4, 2026
…7368) * fix(codegen): statepoint report counted zero safepoints since #7348 #7348 deleted the explicit bridge and with it the only callers of note_statepoint and note_skipped -- they lived in the bridge, which counted safepoints as it emitted them. The methods survived with no callers, so statepoints, relocations, max_live_roots, skipped_non_safepoints, live_roots_histogram and both by-callee maps went structurally zero in production. A real compile printed "0 statepoints emitted" while its binary carried 120. Counting at IR-emission time cannot work any more, and that is the lesson: Perry no longer decides which calls become safepoints -- RewriteStatepointsForGC does, inside LLVM. The only honest source is the compact-map rewrite, which already parses the assembly LLVM emitted and computed these exact numbers before dropping them into log::debug!. The report reads from there now: 120 safepoints across 6 function(s) in 1 module(s) 36 live roots recorded, 0.30 per safepoint An absent measurement no longer renders as a measured zero: gc_map.modules == 0 means "never reported", the text report says UNAVAILABLE rather than printing zeros, and JSON carries gc_map separately from totals so a consumer can tell them apart. schema_version -> 2. The CI gate now asserts the counts, not just the label. --only-backend rs4gc passed throughout the regression -- the label was right, the numbers were fiction. It now also requires records > 0 and roots > 0; verified against a synthetic report with the #7348 shape, where the label check still reports 9 functions green while the count checks exit 1. Second round of dead counters here (#7362 removed four that never had a writer at all). The new test documents why the first invariant missed this one: every_rendered_counter_has_a_writer called the mutators itself, so "has a writer" passed while "is written" was false. Claude-Session: https://claude.ai/code/session_01EaD6yNwoinzdW1JbYNkMMF * gc: admit two provably-leaf helpers, and measure that it buys nothing (#7369) * fix(lint): split index_set.rs, over the 2000-line cap since #7342 (#7366) `scripts/check_file_size.sh` exits 1 on main HEAD: `crates/perry-codegen/src/expr/index_set.rs` is 2035 lines against a 2000 cap. It crossed in #7342. That script runs inside the `lint` job, which is a REQUIRED context -- so this is the second independent way `lint` was red on main today (the first was rustfmt on linker.rs, #7361). A required check that is red on main blocks nothing; it means every merge is a bypass. The split follows the recipe in the script's own failure message: extract a topical group into a sibling module. `lower_inline_dyn_typed_array_set` and its `emit_inline_ta_int_store` helper are the guarded inline typed-array store for a type-erased receiver -- one coherent unit, moved verbatim to `index_set_typed_array.rs`. index_set.rs drops to 1749 lines, leaving real headroom rather than landing one line under the cap. Mechanical move: the two functions are byte-identical, only the imports they need travelled with them and `lower_inline_dyn_typed_array_set` became `pub(super)` so its one caller can still reach it. cargo test -p perry-codegen --lib: 609 passed. Claude-Session: https://claude.ai/code/session_01EaD6yNwoinzdW1JbYNkMMF Co-authored-by: Ralph Küpper <ralph@skelpo.com> * docs(plan): both statepoint adoption gates are closed; record the platform matrix (#7367) The plan still said statepoints were aarch64-only (#7321), that the matrix "therefore runs on macos-14", that `statepoints-refuse-x86` pinned the refusal, and it spelled the knob `PERRY_STATEPOINTS` four times. None of that is true now, and this document is what the adoption decision gets made from. What actually changed: - x86-64 is unblocked. `_Unwind_GetGR(ctx, 7)` does segfault and cannot be fixed as stated -- libgcc tracks only the columns CFI restores and RSP is derived, not tracked. #7349 stopped asking for it and derives the SP-relative base from `_Unwind_GetCFA`, with a per-arch return-address adjustment (x86-64 `call` pushes one, aarch64 `bl` does not). x86-64 Linux is a first-class arm. - Windows works via RtlVirtualUnwind (#7355), the one walker with no Itanium unwinder beneath it. - aarch64+ELF is now covered too (#7360) -- the only shape where LLVM spells 32-bit stack-map fields `.word`. - One mechanism, not two: PERRY_STATEPOINTS and the plain-map bridge are deleted, so the kill-policy line about "a mode that still exists" no longer applies to this pair. - The gate proves something now. Until today the Unix arms reported 7 frames and ZERO locations -- they would have passed with a walker that visited nothing. #7359's deep-collect probe took them to 221 locations. - watchOS/visionOS are not blocked by Perry: they build on stable without `dyn-eval`, and fail three crates away in psm's Mach-O guard. So the remaining adoption gate is `llvm-inprocess` becoming a default cargo feature, plus sequencing step 2 (root density) -- adopting today would regress binary size on root-dense code. Claude-Session: https://claude.ai/code/session_01EaD6yNwoinzdW1JbYNkMMF Co-authored-by: Ralph Küpper <ralph@skelpo.com> * gc: admit two provably-leaf helpers, and measure that it buys nothing js_gc_register_global_root was the most frequent non-leaf callee in the probe suite (148 call sites) and is provably GC-leaf: its whole body is runtime_write_barrier_root_heap_word -- which js_write_barrier_root_heap_word, already CannotCollect, wraps in one line -- plus a TLS Vec::push. The "malloc count threshold" trigger does not apply to that push: the counter is MALLOC_STATE.objects.len(), a registry of Perry GC objects, and the #[global_allocator] is plain mimalloc/System with no GC hook. js_typed_feedback_maybe_dump_trace joins its already-admitted family siblings. Measured A/B on the same tree, and the result is a null: probe safepoints roots total bytes __text 06_string_retention 105 -> 100 27=27 0 -4 B 09_try_catch_roots 343 -> 339 259=259 0 -4 B 11_collect_at_depth 120 -> 117 36=36 0 -4 B Root counts are IDENTICAL. The 40 safepoints removed across the suite were all rootless, and a rootless safepoint costs essentially nothing -- which is what docs/engine-plan.md already says: "the axis is not 'statepoints are bigger', it is 'roots are bigger'". Recording it as evidence: the safepoint-count lever is not the binary-size lever, so sequencing step 2 must attack live-root SETS. Two tests come with it. One pins the wrapper's classification to the barrier it wraps. The other pins js_nanbox_string OUT of the allowlist: at 120 call sites it is the obvious next candidate and reads as pure bit manipulation, but its null guard calls js_string_from_bytes to allocate an empty string. Probe suite 11/11 byte-identical under forced evacuation + verification. Claude-Session: https://claude.ai/code/session_01EaD6yNwoinzdW1JbYNkMMF --------- Co-authored-by: Ralph Küpper <ralph@skelpo.com> * fix(ci): report assertion pinned to a probe Windows cannot compile Three review fixes on #7368. The report assertion ran on 09_try_catch_roots, which contains four `try` blocks. RS4GC cannot rewrite WinEH funclet pads, so linker.rs's rs4gc_funclet_refusal rejects that probe on windows-msvc -- the probe loop above tolerates it by grepping the compile log for "funclet", but this step did not. A gate pinned to a probe that cannot compile on one arm fails for a reason unrelated to its subject. The portable assertion now uses 11_collect_at_depth (no `try`, compiles on all four arms); 09_try_catch_roots keeps its own non-Windows step so the try-specific coverage that justified deleting the bridge is not lost. The gc_map doc claimed records/roots would be ABSENT when unmeasured. They are plain u64 fields on a plain derive and always serialise; `modules` is the sentinel. Fixed to describe what the code actually does -- the same class of comment-vs-code drift this PR exists to clean up. The "map never reported" guard fired for any --require-*/--print, including fields that live in `totals` and are counted at IR-emission time whether or not the rewrite ran. Now scoped to map-backed fields: --require-positive textual_calls is answered from its measured value (verified exit 0) while --require-positive records still fails on an unreported map (exit 1). Claude-Session: https://claude.ai/code/session_01EaD6yNwoinzdW1JbYNkMMF --------- Co-authored-by: Ralph Küpper <ralph@skelpo.com>
proggeramlug
added a commit
that referenced
this pull request
Aug 4, 2026
…fork (#7371) Three corrections, one of which is a number the plan explicitly warns against quoting and was carrying anyway. 1. THE SIZE FIGURE. Only +18.95% appears on main -- a synthetic worst case with three heap values live across an allocation in EVERY one of 2000 functions. The dependency-scale measurement is +1.86% (zod, 81 native modules, 29 MB binary), an order of magnitude lower. The correction was written when the synthetic was retracted but never reached main: #7345 squash-merged as 24 insertions, the first commit only, so the follow-up correction commit was dropped. That is the same failure mode this document records for #7321 -- a wrong explanation outliving its own disproof -- so the real number now leads and the worst case is explicitly marked do-not-quote. 2. SEQUENCING STEP 2 said root density was a PREREQUISITE for adoption, reasoning from that retracted figure. Adoption shipped in #7370 without it. Still worth doing, and still the same lever #7296 proved worth 9.9x, but it gates nothing. 3. THE ADOPTION FORK IS CLOSED. Every gate shut: llvm-inprocess default (#7353), x86-64 (#7349), Windows (#7355), bridge deleted (#7348), and the 479-test suite with no env matching the shadow baseline exactly. The target-aware shape is recorded because it is the part that generalises: native roots where the runtime can walk, shadow stack where it cannot. Also: layer 2 now reads THE DEFAULT rather than landed opt-in, layer 3's count is 41 rather than 54 after #7363, and the 2026-08-03 status header no longer says 'not yet adopted'. Co-authored-by: Ralph Küpper <ralph@skelpo.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #7354.
What this adds
The COFF
.pgcmapsection and its PE lookup existed (#7351) but Windows had no stack walker —_Unwind_*does not exist there — socompact_and_assemblerefused every COFF target. This PR adds the walker and enables the platform, verified end-to-end on a real Windows 11 host.gc/roots/stack_maps.rs— a#[cfg(all(windows, x86_64))] mod unwindwalks native frames withRtlCaptureContext→RtlLookupFunctionEntry→RtlVirtualUnwind. Each step yields the frame'sRip/Rsp/Rbpdirectly, so SP-relative roots read the realRsp— the CFA derivation the Itanium path needs is skipped entirely, per the issue's recommendation. The hand-declaredCONTEXTlayout is pinned by compile-timeoffset_of!asserts. Fail-closed: only Win64 nonvolatile base registers are trusted (a volatile register's CONTEXT slot holds some inner frame's value — handing it out would give the collector a wild address it then writes through); every candidate slot is bounded byGetCurrentThreadStackLimits; a frame with no unwind info, a non-outward step, or an out-of-bounds/misaligned slot abandons the walk. The SP monotonicity check is also the termination guarantee.exception.rs— main's unguardedeh_walker::calls (an Itanium-only module) meant perry-runtime did not compile on Windows at all; now#[cfg(not(windows))].gc_map.rs— the COFF refusal narrows to non-x86-64 instead of being deleted: ARM64 Windows passes the arch gate and is COFF but still has no walker (different CONTEXT layout/register model), so deleting the refusal outright would re-open the silent-lost-roots hole there.windows_is_refused_until_it_has_a_walkeris replaced byx86_64_windows_is_no_longer_refusedplus the ARM64 pin.linker.rs/inprocess.rs— a measured negative: windows-msvctrylowers to WinEH funclet pads, and LLVM'srewrite-statepoints-for-gccrashes on them (0xC0000005 in opt 22.1.3; reproducible with an 8-line module — oneinvokeunwinding to acatchswitch, see below). RS4GC now refuses funclet modules before the pass runs, on both the external-optand in-process paths (where the crash would take the whole compiler down). A failed opt pipeline now also writes its input IR to disk and prints a one-command repro — the crash previously left only a symbol-less stack dump.gc-native-roots.yml—windows-latestmatrix arm: PE section asserts viallvm-readobjfrom the same pinned clang+llvm archive that suppliesopt(one directory, no version skew), probe 09 pinned as the named funclet refusal (goes red the day the pass learns funclets), and a--require-locationstelemetry liveness gate viagc_walker_trace_assert.py— this walker has no Itanium unwinder under it and no verify-mode cross-check, so non-zero telemetry is the only proof it ran.Telemetry from the real run (the "prove it ran" numbers)
Toolchain: opt+clang 22.1.3 from one release archive; Node v26.5.1 (zip sha512 matches the
external-tools.jsonSRI pin). Runtime + compiler built with-C force-frame-pointers=yes -C force-unwind-tables=yes, perry-dev profile. All runs underPERRY_RS4GC=1 PERRY_GC_FORCE_EVACUATE=1 PERRY_GC_VERIFY_EVACUATION=1 PERRY_GC_HEAP_LIMIT=8 PERRY_GC_INCREMENTAL=0 PERRY_CONSERVATIVE_STACK_SCAN=off, byte-diffed againstnode --expose-gc --experimental-strip-types:All 9 runnable probes byte-match the oracle. Probe 04's deep recursion shows the walker stepping 5,626 mapped frames and matching 5,449 records. The forced evacuation was live, not vacuous: 5,946–90,271 objects copied per probe (
copying_nursery.copied_objects), underPERRY_GC_VERIFY_EVACUATION=1.PERRY_STACKMAP_WALKER=unwindgives identical output withfallback_walks=0, confirming mode wiring. Every binary carries a non-empty.pgcmap(e.g. probe 04: VirtualSize 0x2A9) and zerollvm_st*section remnants.The measured negative: probe 09 (try/catch)
rewrite-statepoints-for-gccrashes on WinEH funclets. Minimal repro (crashes opt 22.1.3 identically to the full probe):opt -passes=rewrite-statepoints-for-gc→ Exception Code 0xC0000005. Perry now refuses this shape by name before the pass runs, and the CI arm pins the refusal.Tests
cargo test -p perry-codegen --lib: 599 passed, 0 failed on Windows (includes the new funclet-refusal and Windows-enablement tests).cargo test -p perry-runtime --lib: allgc::roots::stack_mapsandexception::tests pass. The full suite has never been runnable on Windows before this PR (the crate didn't compile); running it now surfaces pre-existing platform gaps unrelated to this work (dyn_eval SEH-throw aborts under the test harness, a setjmp smoke AV, a date/TZ assertion,child_processspawn-sync fields, glibc-assumingmalloc_trimassert, a teardown accounting off-by-2) — inventoried in Windows: perry-runtime --lib test suite has pre-existing failures now that the crate compiles there (#7355 fallout inventory) #7356 rather than folded into this PR.Summary by CodeRabbit