ci: remove the temporary x86-64 diagnostic, and correct the header it contradicts

[proggeramlug]

Follow-up to #7331, which was merged while its temporary diagnostic job was
still in the branch.

Removes the temporary job

x86-diagnose existed to read the x86-64 refusal off a runner instead of
guessing at it. It has served that purpose, and it is 45 runner-minutes per run
of pure logging, so it comes out.

Corrects what it found

The header of gc-native-roots.yml currently carries two contradictory
explanations of the same fact — the block #7324 added at the top, and the
older "Why the matrix runs on macos-14" block below it, which still says the
compact-map rewriter cannot parse an x86-64 stack map and names gc_map.rs's
aarch64 register naming as the suspect. That is CLAUDE.md's gc_incremental_enabled
hazard verbatim: a doc saying one thing eight lines above a body saying the
opposite, and a merge decision made on the wrong one.

The older explanation is the wrong one, and it is worth saying so explicitly
because it survived into an issue title (#7321) and a job name before anyone
measured it. What is actually true:

• x86-64 stack maps parse. Confirmed twice independently — by gc: refuse native roots off aarch64, and stop the ELF map forcing DT_TEXTREL #7324
  cross-compiling a probe to x86_64-unknown-linux-gnu and decoding the emitted
  map (178 root slots, all Indirect [RSP + off], DWARF register 7), and by
  gc: decode ELF stack maps, and make the compact-map refusal say why (#7321) #7331 running five clang versions (Apple 21, Homebrew 19/20/22, Ubuntu
  16/17/18) x twelve -march settings x all nine probes from both a macOS and a
  Linux host, before and after its own change. No configuration reproduced a
  parse failure.
• DWARF 7 round-trips correctly through the compact format's
  explicit-register tag, which is the path encodes_a_foreign_register_base
  already covered. The aarch64 naming costs one byte per x86-64 root; it does
  not lose one.
• The defect is one layer down, at collection time: chain_walkable admits
  only DWARF 29/31, so x86-64 falls through to the platform unwinder, which
  resolves the base with _Unwind_GetGR(ctx, 7) — not a reliable way to get the
  stack pointer. gc: refuse native roots off aarch64, and stop the ELF map forcing DT_TEXTREL #7324 refuses the target for exactly this.

The replacement header says that, and points at #7333 for the same walk being
unsound on aarch64 Linux, where it is merely the non-default path.

Also records #7331's measured result

The fragment changelog.d/7331-elf-stack-map-word-width.md was written before
the Linux numbers existed. It now carries them: aarch64-unknown-linux-gnu
could not compile one module under PERRY_STATEPOINTS=1 before #7331 and now
runs the probe matrix 8/8 against the pinned Node oracle under
PERRY_GC_FORCE_EVACUATE=1 PERRY_GC_VERIFY_EVACUATION=1, .perry_gcmap present
and .llvm_stackmaps absent per probe. Census over those eight: 478
statepoints, 0 plain stack maps, 0 parser fallbacks, 648 relocations, 605
non-safepoint calls skipped, max 3 live roots at one safepoint.
(09_try_catch_roots is excluded — the explicit bridge refuses invokes since
#7330, on every target.)

Verified

python3 -c "import yaml; yaml.safe_load(...)" parses the workflow and the job
list is native-roots-aarch64, native-roots-rs4gc-aarch64,
statepoints-refuse-x86, gc-native-roots-complete — the fan-in's needs: was
already exactly those three, so removing x86-diagnose changes no dependency.
Docs and CI only; no Rust touched.

[coderabbitai]

Warning

Review limit reached

@proggeramlug, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 14 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: b57cbe84-0d6e-431b-8ed0-fdcb54730c8f

📥 Commits

Reviewing files that changed from the base of the PR and between e98dfdb and 6be786e.

📒 Files selected for processing (2)

• .github/workflows/gc-native-roots.yml
• changelog.d/7331-elf-stack-map-word-width.md

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}