morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #8188] [Bug] Swift Ghidra verifier passes assembly source directly to swiftc #6471

New issue

Closed

opened 2026-11-01 21:11:23 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-11-01 21:11:23 +00:00

Owner

Originally created by @morluto on GitHub (Oct 30, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8188

Originally assigned to: @kaoru0822-kitauji on GitHub.

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Tests or verification

Observed behavior

npm run verify:ghidra:swift exits before connecting to REA or running its Ghidra checks because Apple Swift 6.3.2 rejects unresolved-string-jump.s as a direct swiftc input: error: unexpected input file: .../unresolved-string-jump.s.

Reproduction

On macOS arm64 with Ghidra 12.1.4, JDK 21 and Apple Swift 6.3.2, run npm run verify:ghidra:swift with JAVA_HOME and GHIDRA_INSTALL_DIR set. The build completes, then fixture preparation fails. The verifier had already compiled decoder-safeguards.S into an object with xcrun clang, but passed the other assembly source directly to swiftc.

Expected behavior

The verifier should prepare both assembly inputs in a form accepted by the supported host compiler before linking, then run the real provider checks. It should retain the intended unresolved-jump fixture and its coverage.

Impact and scope

This blocks this optional verifier on the observed toolchain; it is not evidence that a REA Swift analysis or Ghidra provider call fails. Other Swift versions and hosts are unverified.

REA version

d48e472fa plus unrelated Kuna 1.986 baseline changes from #8187.

Runtime and platform

macOS arm64; Apple Swift 6.3.2 (swift-driver 1.148.6); Node 24.22.1; Ghidra 12.1.4; JDK 21.

Target and artifact context

Repository-owned Swift and assembly fixtures; compiled artifacts were not executed.

Interface

Verifier fixture preparation.

Earliest failure stage

Fixture build, before MCP connection.

Relevant output or evidence

swiftc -O -target arm64-apple-macosx13.0 .../string-literals.swift .../decoder-safeguards.o .../unresolved-string-jump.s -o ... returned exit 1 with unexpected input file. Independently compiling both assembly files to objects using xcrun clang -target arm64-apple-macosx13.0 -c, then linking those objects with the Swift source, succeeded. That manual link did not run the verifier or validate its Ghidra checks.

Typed outcome or recovery expected

A real verifier run should either reach and complete its checks on the supported toolchain or report a specific, actionable missing-toolchain constraint. Repeat the full lane after adjusting fixture preparation.

Analysis or suspected cause

The verifier passes unresolvedJumpSource directly to swiftc; the earlier literalAssembly is already compiled separately. Compiling the former to an object appears viable on the tested host, but the full fix and regression validation remain to be established.

Originally created by @morluto on GitHub (Oct 30, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8188 Originally assigned to: @kaoru0822-kitauji on GitHub. ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Tests or verification ### Observed behavior `npm run verify:ghidra:swift` exits before connecting to REA or running its Ghidra checks because Apple Swift 6.3.2 rejects `unresolved-string-jump.s` as a direct `swiftc` input: `error: unexpected input file: .../unresolved-string-jump.s`. ### Reproduction On macOS arm64 with Ghidra 12.1.4, JDK 21 and Apple Swift 6.3.2, run `npm run verify:ghidra:swift` with `JAVA_HOME` and `GHIDRA_INSTALL_DIR` set. The build completes, then fixture preparation fails. The verifier had already compiled `decoder-safeguards.S` into an object with `xcrun clang`, but passed the other assembly source directly to `swiftc`. ### Expected behavior The verifier should prepare both assembly inputs in a form accepted by the supported host compiler before linking, then run the real provider checks. It should retain the intended unresolved-jump fixture and its coverage. ### Impact and scope This blocks this optional verifier on the observed toolchain; it is not evidence that a REA Swift analysis or Ghidra provider call fails. Other Swift versions and hosts are unverified. ### REA version `d48e472fa` plus unrelated Kuna 1.986 baseline changes from #8187. ### Runtime and platform macOS arm64; Apple Swift 6.3.2 (swift-driver 1.148.6); Node 24.22.1; Ghidra 12.1.4; JDK 21. ### Target and artifact context Repository-owned Swift and assembly fixtures; compiled artifacts were not executed. ### Interface Verifier fixture preparation. ### Earliest failure stage Fixture build, before MCP connection. ### Relevant output or evidence `swiftc -O -target arm64-apple-macosx13.0 .../string-literals.swift .../decoder-safeguards.o .../unresolved-string-jump.s -o ...` returned exit 1 with `unexpected input file`. Independently compiling both assembly files to objects using `xcrun clang -target arm64-apple-macosx13.0 -c`, then linking those objects with the Swift source, succeeded. That manual link did not run the verifier or validate its Ghidra checks. ### Typed outcome or recovery expected A real verifier run should either reach and complete its checks on the supported toolchain or report a specific, actionable missing-toolchain constraint. Repeat the full lane after adjusting fixture preparation. ### Analysis or suspected cause The verifier passes `unresolvedJumpSource` directly to `swiftc`; the earlier `literalAssembly` is already compiled separately. Compiling the former to an object appears viable on the tested host, but the full fix and regression validation remain to be established.

bsakaguchi

2026-11-01 21:11:23 +00:00

closed this issue
added the
bug

triage
labels

bsakaguchi commented

2026-11-01 21:11:24 +00:00

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 for visibility on the Ghidra, Kuna, and REA tool-design investigation.

@morluto commented on GitHub (Oct 31, 2026): Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 for visibility on the Ghidra, Kuna, and REA tool-design investigation.

bsakaguchi commented

2026-11-01 21:11:24 +00:00

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

Post-merge real-provider control on current REA main 60149282, with the #8325 assembly fix: npm run verify:ghidra:swift completed successfully on macOS arm64 with Apple Swift 6.3.2, Ghidra 12.1.4 and explicit JDK 21 JAVA_HOME. The report was ok: true: debug and copied-without-dSYM fixtures each reported 14 Swift entries, including 12 structs and 2 metadata accessors; the literal checks included small, large, Unicode, empty/control, returned, and unresolved-jump cases. The verifier's final process-lineage observation was verified with no descendants.

This replaces the earlier compile-only recovery evidence with one complete host lane. It does not establish behavior on other Swift or Ghidra versions, platforms, arbitrary binaries, or CI scheduling. The report does not expose a separate cleanup status field; I am not inferring one from the empty descendant list.

@morluto commented on GitHub (Oct 31, 2026): Post-merge real-provider control on current REA main `60149282`, with the #8325 assembly fix: `npm run verify:ghidra:swift` completed successfully on macOS arm64 with Apple Swift 6.3.2, Ghidra 12.1.4 and explicit JDK 21 `JAVA_HOME`. The report was `ok: true`: debug and copied-without-dSYM fixtures each reported 14 Swift entries, including 12 structs and 2 metadata accessors; the literal checks included small, large, Unicode, empty/control, returned, and unresolved-jump cases. The verifier's final process-lineage observation was verified with no descendants. This replaces the earlier compile-only recovery evidence with one complete host lane. It does not establish behavior on other Swift or Ghidra versions, platforms, arbitrary binaries, or CI scheduling. The report does not expose a separate cleanup status field; I am not inferring one from the empty descendant list.

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#6471

No description provided.

Rows
Columns