[PR #1382] [MERGED] fix(ghidra): keep the cross-format branch callee multi-block #2842

New issue

Closed

opened 2026-10-17 21:10:55 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-17 21:10:55 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/1382
Author: @BaaRai
Created: 10/9/2026
Status: ✅ Merged
Merged: 10/10/2026
Merged by: @morluto

Base: main ← Head: fix/cross-branch-multiblock-callee

📝 Commits (3)

e10c934 fix(ghidra): keep the cross-format branch callee multi-block
40f632a ci: re-run the suite after the main-branch shard flake
e17290c ci: re-run the suite on the corrected main checkpoint

📊 Changes

1 file changed (+8 additions, -3 deletions)

View changed files

📝 tests/conformance/ghidra/cross-format.c (+8 -3)

📄 Description

Summary

The cross-format oracle walks the entry's callees for one function whose recovered control flow has more than one basic block, and rea_cross_branch provided it through a symmetric if/else of tail calls. Clang 21 folds that shape into cmp; cneg; b — a single basic block — so findCrossBranchAddress failed with cross-arm64-elf did not recover the multi-block callee against a correct Ghidra analysis. The branch now runs a loop whose trip count depends on the fixture's volatile global, which no compiler can eliminate, keeping the callee multi-block at every optimization level.

Problem and expected behavior

Smallest trigger: npm run verify:ghidra:cross-format with clang 21 (reproduced on Kali rolling: clang 21.1.8, ld.lld 21.1.8, gcc 16.2 host compiler, Ghidra 12.1.4, JDK 21, node 24.19). The lane fails on the first cross target:

Error: cross-arm64-elf did not recover the multi-block callee
    at findCrossBranchAddress (scripts/verify-real-ghidra-function.mjs:523)

Violated invariant: the oracle needs a fixture function that is multi-block after compilation, but symmetric tail-call if/else codegen is a toolchain decision. Disassembly of the clang 21 AArch64 build of the previous source:

rea_cross_branch:
  cmp   w0, #0xa
  cneg  w0, w0, le
  b     rea_cross_leaf

One basic block, so Ghidra correctly reports basicblock_count of one and the verifier rejects it. This is the same class as the -O0 dense-switch lowering fixed for the host lane in #1374, and the dedicated switch lane already avoids it by construction.

Change and scope

tests/conformance/ghidra/cross-format.c: rea_cross_branch now computes an adjusted value and decrements it by rea_cross_global (volatile) inside a while loop before the tail call. The loop is a real backedge at runtime-unknown trip count, so it survives every optimization level; on clang 21 AArch64 the function now compiles to a compare, a conditional select, and a b.lt-guarded loop with a backward branch and the volatile load. No symbols, call structure, entry chain, string evidence, or dense-switch shape change; PE and Mach-O builds of the same source are unaffected beyond the same guaranteed block structure.

Not included: no verifier, bridge, provider, or contract changes — the oracle itself is correct; only the fixture's compiler-independence was missing.

Contract and boundary impact

Semantic owner and earliest changed stage: conformance fixture source only.
CLI and MCP/tool-catalog contract: none.
Provider, bridge, target-format, or platform compatibility: none; fixture behavior is identical on GCC and older Clang.
Evidence, artifact, provenance, or reconstruction contract: not applicable.
Process execution, authorization, cleanup, or containment impact: not applicable.
Generated metadata, package, or installation impact: not applicable.

Evidence and regression coverage

Tests added or updated: the fixture source is the regression; the cross-format and AArch64 oracles assert the multi-block property directly.
Base reproduction and other evidence: executed runs on Kali rolling with GHIDRA_INSTALL_DIR at Ghidra 12.1.4 and JDK 21:
- Base 08ec2bf8: verify:ghidra:cross-format fails at cross-arm64-elf did not recover the multi-block callee; the clang 21 disassembly above shows the single-block fold.
- This change: verify:ghidra:cross-format completes with exit 0 and ok: true across all seven fixtures (debug, stripped, type-layout, jump-table, cross-arm64-elf, cross-x86_64-pe, cross-x86_64-mach-o) with cleanup: complete, and verify:ghidra:aarch64-jump-table (which compiles the same source for its aarch64-jump-table target) still completes with exit 0 across all seven of its fixtures, confirming no regression from the fixture change.
User-visible CLI/MCP output: not applicable.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/1382 **Author:** [@BaaRai](https://github.com/BaaRai) **Created:** 10/9/2026 **Status:** ✅ Merged **Merged:** 10/10/2026 **Merged by:** [@morluto](https://github.com/morluto) **Base:** `main` ← **Head:** `fix/cross-branch-multiblock-callee` --- ### 📝 Commits (3) - [`e10c934`](https://github.com/morluto/rea/commit/e10c934d5a756c1a4c7b547ebd02c403ddfde7b8) fix(ghidra): keep the cross-format branch callee multi-block - [`40f632a`](https://github.com/morluto/rea/commit/40f632a155bff2defdea09e467229c703bc0b0e9) ci: re-run the suite after the main-branch shard flake - [`e17290c`](https://github.com/morluto/rea/commit/e17290cd2a17931d7a2af70f74b76b94276bd788) ci: re-run the suite on the corrected main checkpoint ### 📊 Changes **1 file changed** (+8 additions, -3 deletions) <details> <summary>View changed files</summary> 📝 `tests/conformance/ghidra/cross-format.c` (+8 -3) </details> ### 📄 Description ## Summary The cross-format oracle walks the entry's callees for one function whose recovered control flow has more than one basic block, and `rea_cross_branch` provided it through a symmetric if/else of tail calls. Clang 21 folds that shape into `cmp; cneg; b` — a single basic block — so `findCrossBranchAddress` failed with `cross-arm64-elf did not recover the multi-block callee` against a correct Ghidra analysis. The branch now runs a loop whose trip count depends on the fixture's volatile global, which no compiler can eliminate, keeping the callee multi-block at every optimization level. ## Problem and expected behavior Smallest trigger: `npm run verify:ghidra:cross-format` with clang 21 (reproduced on Kali rolling: clang 21.1.8, ld.lld 21.1.8, gcc 16.2 host compiler, Ghidra 12.1.4, JDK 21, node 24.19). The lane fails on the first cross target: ``` Error: cross-arm64-elf did not recover the multi-block callee at findCrossBranchAddress (scripts/verify-real-ghidra-function.mjs:523) ``` Violated invariant: the oracle needs a fixture function that is multi-block after compilation, but symmetric tail-call if/else codegen is a toolchain decision. Disassembly of the clang 21 AArch64 build of the previous source: ``` rea_cross_branch: cmp w0, #0xa cneg w0, w0, le b rea_cross_leaf ``` One basic block, so Ghidra correctly reports `basicblock_count` of one and the verifier rejects it. This is the same class as the `-O0` dense-switch lowering fixed for the host lane in #1374, and the dedicated switch lane already avoids it by construction. ## Change and scope `tests/conformance/ghidra/cross-format.c`: `rea_cross_branch` now computes an adjusted value and decrements it by `rea_cross_global` (volatile) inside a `while` loop before the tail call. The loop is a real backedge at runtime-unknown trip count, so it survives every optimization level; on clang 21 AArch64 the function now compiles to a compare, a conditional select, and a `b.lt`-guarded loop with a backward branch and the volatile load. No symbols, call structure, entry chain, string evidence, or dense-switch shape change; PE and Mach-O builds of the same source are unaffected beyond the same guaranteed block structure. Not included: no verifier, bridge, provider, or contract changes — the oracle itself is correct; only the fixture's compiler-independence was missing. ## Contract and boundary impact - Semantic owner and earliest changed stage: conformance fixture source only. - CLI and MCP/tool-catalog contract: none. - Provider, bridge, target-format, or platform compatibility: none; fixture behavior is identical on GCC and older Clang. - Evidence, artifact, provenance, or reconstruction contract: not applicable. - Process execution, authorization, cleanup, or containment impact: not applicable. - Generated metadata, package, or installation impact: not applicable. ## Evidence and regression coverage - Tests added or updated: the fixture source is the regression; the cross-format and AArch64 oracles assert the multi-block property directly. - Base reproduction and other evidence: executed runs on Kali rolling with `GHIDRA_INSTALL_DIR` at Ghidra 12.1.4 and JDK 21: - Base 08ec2bf8: `verify:ghidra:cross-format` fails at `cross-arm64-elf did not recover the multi-block callee`; the clang 21 disassembly above shows the single-block fold. - This change: `verify:ghidra:cross-format` completes with exit 0 and `ok: true` across all seven fixtures (debug, stripped, type-layout, jump-table, cross-arm64-elf, cross-x86_64-pe, cross-x86_64-mach-o) with `cleanup: complete`, and `verify:ghidra:aarch64-jump-table` (which compiles the same source for its `aarch64-jump-table` target) still completes with exit 0 across all seven of its fixtures, confirming no regression from the fixture change. - User-visible CLI/MCP output: not applicable. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-17 21:10:55 +00:00