[PR #2865] [CLOSED] fix(ghidra): import HashMap before bridge compilation #5450

New issue

Closed

opened 2026-10-31 01:06:43 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 01:06:43 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/2865
Author: @N0zoM1z0
Created: 10/13/2026
Status: ❌ Closed

Base: main ← Head: fix/ghidra-bridge-hashmap-import

📝 Commits (1)

10caef9 fix(ghidra): import HashMap before bridge compilation

📊 Changes

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

View changed files

📝 bridge/ghidra/ReaGhidraBridge.java (+1 -0)

📄 Description

Problem and change

The Swift literal decoder merged in #2049 uses new HashMap<>() without importing java.util.HashMap. Actual Windows Ghidra compiles the complete bridge and reports cannot find symbol: class HashMap, so this breaks x64 PE operations before the bridge endpoint is ready.

Add the missing standard-library import. The diff is one line; cache behavior, target interpretation and CLI/MCP contracts are unchanged. Found while reproducing #2259; this PR does not close that PDB coverage issue.

Verification

Actual Windows JDK 21.0.12.1 compiles all nine packaged bridge sources against Ghidra 12.1.4's 195 API jars: exit0, 51.35s, 512MiB heap, two CPUs.
Actual public Windows stdio MCP opens the system where.exe copy and returns a binary overview with 197 procedures. The source SHA-256 remains ade557dd65848c5cf6565913cf6e01cf5c9a8033f0d784c4d6932394958d743e. Cold overview:202.09s; subsequent queries:52.53–65.14ms. This observes successful startup and session reuse, not a paired algorithm speedup.
Real-provider smoke scope: JS runtime pinned to 1ca5fd38b, bridge from fd65e278b plus this import (SHA-256 f9cb1d72847e45bb6661a4f6797143d37c2bf6fb11659d507620429083ce4878). Ghidra is operator-supplied; IDA was not used in this verification.
git diff --check passes. build:cached and check:fast were attempted against fd65e278b and fail in unchanged baseline files: Android direct_invokes_exhaustive/JsonValue typing and four test callback max-lines errors. No Android or lint patches are included. Full latest-runtime verification remains unavailable until those upstream gates recover.

Only compact observations are reported. No licenses, personal registration data, generated classes, provider databases or executable/PDB files are included in the PR.

_{🔄 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/2865 **Author:** [@N0zoM1z0](https://github.com/N0zoM1z0) **Created:** 10/13/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/ghidra-bridge-hashmap-import` --- ### 📝 Commits (1) - [`10caef9`](https://github.com/morluto/rea/commit/10caef99e768d75954aa51610ca1331c1009c6f4) fix(ghidra): import HashMap before bridge compilation ### 📊 Changes **1 file changed** (+1 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `bridge/ghidra/ReaGhidraBridge.java` (+1 -0) </details> ### 📄 Description ## Problem and change The Swift literal decoder merged in #2049 uses `new HashMap<>()` without importing `java.util.HashMap`. Actual Windows Ghidra compiles the complete bridge and reports `cannot find symbol: class HashMap`, so this breaks x64 PE operations before the bridge endpoint is ready. Add the missing standard-library import. The diff is one line; cache behavior, target interpretation and CLI/MCP contracts are unchanged. Found while reproducing #2259; this PR does not close that PDB coverage issue. ## Verification - Actual Windows JDK 21.0.12.1 compiles all nine packaged bridge sources against Ghidra 12.1.4's 195 API jars: exit0, 51.35s, 512MiB heap, two CPUs. - Actual public Windows stdio MCP opens the system `where.exe` copy and returns a binary overview with 197 procedures. The source SHA-256 remains `ade557dd65848c5cf6565913cf6e01cf5c9a8033f0d784c4d6932394958d743e`. Cold overview:202.09s; subsequent queries:52.53–65.14ms. This observes successful startup and session reuse, not a paired algorithm speedup. - Real-provider smoke scope: JS runtime pinned to `1ca5fd38b`, bridge from `fd65e278b` plus this import (SHA-256 `f9cb1d72847e45bb6661a4f6797143d37c2bf6fb11659d507620429083ce4878`). Ghidra is operator-supplied; IDA was not used in this verification. - `git diff --check` passes. `build:cached` and `check:fast` were attempted against `fd65e278b` and fail in unchanged baseline files: Android `direct_invokes_exhaustive`/`JsonValue` typing and four test callback max-lines errors. No Android or lint patches are included. Full latest-runtime verification remains unavailable until those upstream gates recover. Only compact observations are reported. No licenses, personal registration data, generated classes, provider databases or executable/PDB files are included in the PR. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-31 01:06:43 +00:00