[PR #4288] [CLOSED] fix(native): match the arm64e.v1 dwarfdump UUID row #6163

Closed
opened 2026-10-31 01:12:20 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/4288
Author: @Henglie
Created: 10/15/2026
Status: ❌ Closed

Base: main ← Head: fix/macho-arm64e-uuid-row


📝 Commits (2)

  • a1c9235 fix(native): match the arm64e.v1 dwarfdump UUID row
  • 8fc8cc8 Merge origin/main into fix/macho-arm64e-uuid-row

📊 Changes

1 file changed (+89 additions, -0 deletions)

View changed files

➕ src/native/parsers/machoUuid.test.ts (+89 -0)

📄 Description

Summary

inspect-macho reported a false dwarfdump --uuid returned no row for selected architecture arm64e.v1 limitation when it selected an arm64e.v1 slice of a
universal Mach-O. The UUID itself was correct, so successful Evidence carried
uncertainty metadata it had not earned.

Row selection compared the dwarfdump architecture label with string equality,
while the slice tools are invoked with the CPU-family name. This makes the
comparison use the same family name the tool was asked about.

Fixes #4195.

Problem and expected behavior

lipo names an arm64e slice with its pointer-auth ABI version (arm64e.v1).
dwarfdump --uuid reports the CPU-family name for the slice it was asked about
((arm64e)), and REA already invokes it with the version stripped:
toolArchitectureName in NativeMachoInspection.ts strips a trailing .vN
for every tool except dyld_info.

Only the row comparison was left asymmetric. It filtered rows with
architecture === selectedArchitecture, so a correct (arm64e) row never
matched the arm64e.v1 selection, and the parser reported "no row" even though
the row was present and the UUID agreed with LC_UUID.

Expected: a versioned selection finds its row, and a row that is genuinely
absent is still reported as absent.

Change and scope

  • src/native/parsers/machoUuid.ts: add dwarfdumpArchitectureName, which
    strips a trailing pointer-auth ABI version (.vN), and use it on both sides
    of the row comparison in selectDwarfdumpRow.
  • Variants other than the pointer-auth ABI version are deliberately left to
    match exactly. arm64e.x1 is a distinct subtype that the tools address only
    by its exact name, and I did not assume dwarfdump collapses it to arm64e;
    a test pins that behaviour so the fix cannot silently widen into a guess.
  • No new capability, no new tool, no contract change. This is a fix inside the
    existing UUID reconciliation boundary, so no maintainer scope decision is
    required ("not applicable").

Contract and boundary impact

  • Semantic owner and earliest changed stage: UUID reconciliation, after the
    slice tool output is captured. No tool is invoked differently.
  • Contribution scope fit and linked maintainer decision: not applicable; fix
    within existing boundaries.
  • CLI and MCP/tool-catalog contract: the output shape is unchanged. The
    observable difference is that a false limitations entry is no longer
    reported for arm64e.v1 selections, and the returned UUID comes from the
    matching dwarfdump row rather than falling back to LC_UUID — the same
    value, with the unfounded uncertainty removed.
  • Provider, bridge, target-format, or platform compatibility: the parsers are
    portable; the tools involved remain macOS-only as before, and the tests need
    no macOS host.
  • Evidence, artifact, provenance, or reconstruction contract: unchanged. Both
    observations are still recorded and a disagreement is still reported.
  • Target selection, authority, upstream behavior, and cleanup details: not
    applicable; no execution, no writes.
  • Generated metadata: none.

Expected effects:

  • Read existing files or captured data.
  • Launch or attach to a process.
  • Inject instrumentation or run scripts/code.
  • Change process memory, registers, files, or configuration.
  • Contact network services.
  • Recover protected code or work around protections.
  • Documentation or usability only; no target interaction.
  • Not sure yet; investigation or maintainer guidance needed.

Evidence and regression coverage

  • Tests added: src/native/parsers/machoUuid.test.ts (new, 5 tests): the
    arm64e.v1 row now matches; an exact name still matches; arm64e.x1 stays
    unmatched; a genuinely absent row is still reported as absent; two rows of the
    same family are still reported as a conflict rather than silently reduced to
    one.
  • Base reproduction: reverting only the comparison change makes exactly two of
    the five fail — matches a dwarfdump row to an arm64e.v1 selection and
    reports a conflict between two rows of the same family — and restoring it
    makes all five pass. I ran both directions.
  • Remaining proof gaps: this was not reproduced on macOS with real lipo,
    dwarfdump and an arm64e toolchain, because none are available here; the
    regression is at the parser boundary the report identifies, and the issue's
    own reproduction shows the same (arm64e) row. The arm64e.x1 behaviour is
    asserted from the documented tool semantics already recorded in
    NativeMachoInspection.ts, not observed on hardware.

For evidence-bearing changes:

  • Observed, derived, and inferred claims remain distinguishable.
  • Artifact identity, source provenance, and failed attempts remain preserved.
  • Unsupported, incomplete, unavailable, or uncertain outcomes remain visible.

Validation performed

  • npm run test:focused -- src/native/parsers/machoUuid.test.ts — 5 passed;
    2 of the 5 fail when the fix is reverted.
  • npm run test:focused -- src/native/NativeMachoInspection.test.ts — 19
    passed, unchanged by this fix.
  • npx tsc --noEmit — no errors in the changed files.
  • npx oxlint src/native/parsers/ — 0 errors.
  • npx oxfmt <changed files> — applied.

Not run, and not claimed as passing: npm run check:fast (its deps:check
pre-step fails in this environment) and npm run test:acceptance (requires a
build). Expected to be covered by CI.

Compatibility, safety, and release

  • Breaking changes or migration steps: none.
  • Real Hopper/Ghidra, browser, or OS coverage: not required; no macOS host was
    used, which is recorded above as a proof gap.
  • Package or release metadata impact: none.
  • Security, privacy, process, or containment review: parsing captured tool
    output only; no execution, no mutation.

Author readiness

Human owner: @Henglie

  • I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
  • I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
  • I declare this PR ready for initial maintainer review.

Before merge

  • This PR addresses a concrete problem or an agreed enhancement.
  • Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff.
  • The PR has one focused outcome and the title follows type(scope): outcome.
  • Related issue is linked, or the reason for not linking one is stated above.
  • Tests cover changed observable behavior and meaningful failure paths.
  • Owning docs, contracts, and generated metadata are updated where needed.
  • User-visible CLI/MCP changes include representative output.
  • I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

🔄 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/4288 **Author:** [@Henglie](https://github.com/Henglie) **Created:** 10/15/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/macho-arm64e-uuid-row` --- ### 📝 Commits (2) - [`a1c9235`](https://github.com/morluto/rea/commit/a1c9235e76ab912678c244d3bd94019166e1686f) fix(native): match the arm64e.v1 dwarfdump UUID row - [`8fc8cc8`](https://github.com/morluto/rea/commit/8fc8cc80b1f81c13be659c6bb66f6b15a95f86f1) Merge origin/main into fix/macho-arm64e-uuid-row ### 📊 Changes **1 file changed** (+89 additions, -0 deletions) <details> <summary>View changed files</summary> ➕ `src/native/parsers/machoUuid.test.ts` (+89 -0) </details> ### 📄 Description ## Summary `inspect-macho` reported a false `dwarfdump --uuid returned no row for selected architecture arm64e.v1` limitation when it selected an `arm64e.v1` slice of a universal Mach-O. The UUID itself was correct, so successful Evidence carried uncertainty metadata it had not earned. Row selection compared the dwarfdump architecture label with string equality, while the slice tools are invoked with the CPU-family name. This makes the comparison use the same family name the tool was asked about. Fixes #4195. ## Problem and expected behavior `lipo` names an arm64e slice with its pointer-auth ABI version (`arm64e.v1`). `dwarfdump --uuid` reports the CPU-family name for the slice it was asked about (`(arm64e)`), and REA already invokes it with the version stripped: `toolArchitectureName` in `NativeMachoInspection.ts` strips a trailing `.vN` for every tool except `dyld_info`. Only the row comparison was left asymmetric. It filtered rows with `architecture === selectedArchitecture`, so a correct `(arm64e)` row never matched the `arm64e.v1` selection, and the parser reported "no row" even though the row was present and the UUID agreed with `LC_UUID`. Expected: a versioned selection finds its row, and a row that is genuinely absent is still reported as absent. ## Change and scope - `src/native/parsers/machoUuid.ts`: add `dwarfdumpArchitectureName`, which strips a trailing pointer-auth ABI version (`.vN`), and use it on both sides of the row comparison in `selectDwarfdumpRow`. - Variants other than the pointer-auth ABI version are deliberately left to match exactly. `arm64e.x1` is a distinct subtype that the tools address only by its exact name, and I did not assume `dwarfdump` collapses it to `arm64e`; a test pins that behaviour so the fix cannot silently widen into a guess. - No new capability, no new tool, no contract change. This is a fix inside the existing UUID reconciliation boundary, so no maintainer scope decision is required ("not applicable"). ## Contract and boundary impact - Semantic owner and earliest changed stage: UUID reconciliation, after the slice tool output is captured. No tool is invoked differently. - Contribution scope fit and linked maintainer decision: not applicable; fix within existing boundaries. - CLI and MCP/tool-catalog contract: the output shape is unchanged. The observable difference is that a false `limitations` entry is no longer reported for `arm64e.v1` selections, and the returned UUID comes from the matching `dwarfdump` row rather than falling back to `LC_UUID` — the same value, with the unfounded uncertainty removed. - Provider, bridge, target-format, or platform compatibility: the parsers are portable; the tools involved remain macOS-only as before, and the tests need no macOS host. - Evidence, artifact, provenance, or reconstruction contract: unchanged. Both observations are still recorded and a disagreement is still reported. - Target selection, authority, upstream behavior, and cleanup details: not applicable; no execution, no writes. - Generated metadata: none. Expected effects: - [x] Read existing files or captured data. - [ ] Launch or attach to a process. - [ ] Inject instrumentation or run scripts/code. - [ ] Change process memory, registers, files, or configuration. - [ ] Contact network services. - [ ] Recover protected code or work around protections. - [ ] Documentation or usability only; no target interaction. - [ ] Not sure yet; investigation or maintainer guidance needed. ## Evidence and regression coverage - Tests added: `src/native/parsers/machoUuid.test.ts` (new, 5 tests): the `arm64e.v1` row now matches; an exact name still matches; `arm64e.x1` stays unmatched; a genuinely absent row is still reported as absent; two rows of the same family are still reported as a conflict rather than silently reduced to one. - Base reproduction: reverting only the comparison change makes exactly two of the five fail — `matches a dwarfdump row to an arm64e.v1 selection` and `reports a conflict between two rows of the same family` — and restoring it makes all five pass. I ran both directions. - Remaining proof gaps: this was not reproduced on macOS with real `lipo`, `dwarfdump` and an arm64e toolchain, because none are available here; the regression is at the parser boundary the report identifies, and the issue's own reproduction shows the same `(arm64e)` row. The `arm64e.x1` behaviour is asserted from the documented tool semantics already recorded in `NativeMachoInspection.ts`, not observed on hardware. For evidence-bearing changes: - [x] Observed, derived, and inferred claims remain distinguishable. - [x] Artifact identity, source provenance, and failed attempts remain preserved. - [x] Unsupported, incomplete, unavailable, or uncertain outcomes remain visible. ## Validation performed - `npm run test:focused -- src/native/parsers/machoUuid.test.ts` — 5 passed; 2 of the 5 fail when the fix is reverted. - `npm run test:focused -- src/native/NativeMachoInspection.test.ts` — 19 passed, unchanged by this fix. - `npx tsc --noEmit` — no errors in the changed files. - `npx oxlint src/native/parsers/` — 0 errors. - `npx oxfmt <changed files>` — applied. Not run, and not claimed as passing: `npm run check:fast` (its `deps:check` pre-step fails in this environment) and `npm run test:acceptance` (requires a build). Expected to be covered by CI. ## Compatibility, safety, and release - Breaking changes or migration steps: none. - Real Hopper/Ghidra, browser, or OS coverage: not required; no macOS host was used, which is recorded above as a proof gap. - Package or release metadata impact: none. - Security, privacy, process, or containment review: parsing captured tool output only; no execution, no mutation. ## Author readiness Human owner: @Henglie - [x] I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work. - [x] I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps. - [x] I declare this PR ready for initial maintainer review. ## Before merge - [x] This PR addresses a concrete problem or an agreed enhancement. - [x] Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff. - [x] The PR has one focused outcome and the title follows `type(scope): outcome`. - [x] Related issue is linked, or the reason for not linking one is stated above. - [x] Tests cover changed observable behavior and meaningful failure paths. - [x] Owning docs, contracts, and generated metadata are updated where needed. - [x] User-visible CLI/MCP changes include representative output. - [x] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
bsakaguchi 2026-10-31 01:12:20 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#6163
No description provided.