morluto/rea

Fork 0

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

[PR #1870] [CLOSED] docs(installation): document building the macOS Ghidra native decompiler #4868

New issue

Closed

opened 2026-10-31 00:56:12 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:56:12 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/1870
Author: @z751638806
Created: 10/11/2026
Status: ❌ Closed

Base: main ← Head: docs/ghidra-macos-native-decompiler

📝 Commits (2)

e6cf7fc docs(installation): document building the macOS Ghidra native decompiler
cbe8c49 docs(installation): reconcile macOS decompiler instructions with main

📄 Description

Summary

A macOS Ghidra user cannot satisfy REA's native-decompiler prerequisite from the
official archive alone: the 12.1.4 release ships os/linux_x86_64 and
os/win_x86_64 only, so doctor --provider ghidra reports the component as
missing/incompatible and every native operation is unavailable. The Ghidra
section of the installation guide says the component may need a separate build
and names linux_arm_64, but gives no macOS equivalent and no recipe.

This adds a ### Ghidra native decompiler on macOS subsection with the exact
build, plus a pointer from the existing prerequisite paragraph.

No related issue found after searching mac_arm_64, native decompiler,
build the decompiler, and Decompiler/os; the closest prior work is #1192,
which added the doctor diagnostics that report this condition.

Problem and expected behavior

Smallest trigger, on a supported host:

Extract the official Ghidra 12.1.4 PUBLIC archive and install JDK 21.
Export GHIDRA_INSTALL_DIR / JAVA_HOME.
rea doctor --provider ghidra --json

Observed: the newest archive contains no Ghidra/Features/Decompiler/os/mac_*
directory at all, and REA admits the provider only when the native component for
the host exists (mac_arm_64 on Apple silicon, admitted by reading the file's
own executable header). A plain make in
Ghidra/Features/Decompiler/src/decompile/cpp does not produce it either: the
default and depend targets also compile the BFD load image
(loadimage_bfd.cc, bfd_arch.cc) and fail with
fatal error: 'bfd.h' file not found, because macOS has no libbfd. The
Makefile's Darwin branch additionally hardcodes -arch x86_64, so a naive
build on Apple silicon would not match the host architecture.

Expected: the guide tells a macOS operator what to build, where to place it, and
how to confirm the provider accepts it.

Change and scope

Documentation only:

docs/installation.md — new subsection with the ghidra_opt target
(ARCH_TYPE="-arch arm64", ADDITIONAL_FLAGS="-mmacosx-version-min=12.0"),
the cp into os/mac_arm_64/decompile, the Intel-Mac variant, why the other
targets fail (BFD), why the generated sleigh parser means no newer bison is
needed, and how doctor --provider ghidra confirms it.
The prerequisite paragraph now states that official archives ship no macOS
native and links to the new subsection.

Intentionally not included: no change to REA's runtime behavior, provider
admission rules, or diagnostics. REA's stated position that it never builds or
installs native tools is unchanged — the operator builds the component, as the
guide already proposes for Linux ARM64.

Contract and boundary impact

Semantic owner and earliest changed stage: none — authored docs only.
CLI and MCP/tool-catalog contract: none.
Provider, bridge, target-format, or platform compatibility: documents an
existing requirement for the already-supported macOS x64/arm64 Ghidra hosts;
no admitted surface changes.
Evidence, artifact, provenance, or reconstruction contract: none.
Process execution, authorization, cleanup, or containment impact: none.
Generated metadata (docs/public/product-catalog.json), package, or
installation impact: none.

Evidence and regression coverage

Tests added or updated: none (documentation only).
Base reproduction or other evidence: executed the documented commands on
macOS 15.7.9 / Apple silicon against the official Ghidra 12.1.4 PUBLIC
archive with Temurin JDK 21, then confirmed REA 6.4.0 accepts the result and
decompiles a real Mach-O. Rebuilt from a pristine copy of the C++ sources
(no object files) to confirm the published recipe is the one that works; the
resulting binary was byte-identical (same SHA-256) to the admitted one.
User-visible CLI/MCP output (if applicable): rea doctor --provider ghidra --json reports the ghidra-native_decompiler check as passing with the
observed mach-o architecture instead of incompatible, and a
rea decompile <mach-o> <symbol> --provider ghidra --json call returns
pseudocode with the usual evidence envelope.
Remaining proof gaps: Intel macOS (os/mac_x86_64) is documented from the
same Makefile path but was not exercised on Apple silicon; Linux ARM64
remains as previously documented.

Validation performed

npm ci then npm run docs:check — 6/6 tasks successful, exit 0.
npx oxfmt --check docs/installation.md — "All matched files use the correct
format."
make ghidra_opt -j… ARCH_TYPE="-arch arm64" ADDITIONAL_FLAGS="-mmacosx-version-min=12.0"
in a pristine copy of src/decompile/cpp — exit 0, output
Mach-O 64-bit executable arm64, identical SHA-256 to the admitted file.
rea doctor --provider ghidra --json — ghidra, ghidra-version (12.1.4),
ghidra-headless, ghidra-native_decompiler, and ghidra-java checks pass.

Compatibility, safety, and release

Breaking changes or migration steps: none.
Real Hopper/Ghidra, browser, or OS coverage: real Ghidra 12.1.4 headless on
macOS arm64; the documented build path was run twice (fresh archive, pristine
source copy).
Package or release metadata impact: none.
Security, privacy, process, or containment review: none — no runtime, secrets,
or containment surface touched; the guide keeps telling operators to build the
component themselves rather than having REA install native tools.

Review checklist

This PR addresses a concrete problem or an agreed enhancement.
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/1870 **Author:** [@z751638806](https://github.com/z751638806) **Created:** 10/11/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `docs/ghidra-macos-native-decompiler` --- ### 📝 Commits (2) - [`e6cf7fc`](https://github.com/morluto/rea/commit/e6cf7fc5a15f0bee9cce5484e6960d904de47d11) docs(installation): document building the macOS Ghidra native decompiler - [`cbe8c49`](https://github.com/morluto/rea/commit/cbe8c49581d499444f1189d570bd41383c7ee2ee) docs(installation): reconcile macOS decompiler instructions with main ### 📄 Description ## Summary A macOS Ghidra user cannot satisfy REA's native-decompiler prerequisite from the official archive alone: the 12.1.4 release ships `os/linux_x86_64` and `os/win_x86_64` only, so `doctor --provider ghidra` reports the component as missing/incompatible and every native operation is unavailable. The Ghidra section of the installation guide says the component may need a separate build and names `linux_arm_64`, but gives no macOS equivalent and no recipe. This adds a `### Ghidra native decompiler on macOS` subsection with the exact build, plus a pointer from the existing prerequisite paragraph. No related issue found after searching `mac_arm_64`, `native decompiler`, `build the decompiler`, and `Decompiler/os`; the closest prior work is #1192, which added the doctor diagnostics that report this condition. ## Problem and expected behavior Smallest trigger, on a supported host: 1. Extract the official Ghidra 12.1.4 `PUBLIC` archive and install JDK 21. 2. Export `GHIDRA_INSTALL_DIR` / `JAVA_HOME`. 3. `rea doctor --provider ghidra --json` Observed: the newest archive contains no `Ghidra/Features/Decompiler/os/mac_*` directory at all, and REA admits the provider only when the native component for the host exists (`mac_arm_64` on Apple silicon, admitted by reading the file's own executable header). A plain `make` in `Ghidra/Features/Decompiler/src/decompile/cpp` does not produce it either: the default and `depend` targets also compile the BFD load image (`loadimage_bfd.cc`, `bfd_arch.cc`) and fail with `fatal error: 'bfd.h' file not found`, because macOS has no libbfd. The Makefile's `Darwin` branch additionally hardcodes `-arch x86_64`, so a naive build on Apple silicon would not match the host architecture. Expected: the guide tells a macOS operator what to build, where to place it, and how to confirm the provider accepts it. ## Change and scope Documentation only: - `docs/installation.md` — new subsection with the `ghidra_opt` target (`ARCH_TYPE="-arch arm64"`, `ADDITIONAL_FLAGS="-mmacosx-version-min=12.0"`), the `cp` into `os/mac_arm_64/decompile`, the Intel-Mac variant, why the other targets fail (BFD), why the generated sleigh parser means no newer `bison` is needed, and how `doctor --provider ghidra` confirms it. - The prerequisite paragraph now states that official archives ship no macOS native and links to the new subsection. Intentionally not included: no change to REA's runtime behavior, provider admission rules, or diagnostics. REA's stated position that it never builds or installs native tools is unchanged — the operator builds the component, as the guide already proposes for Linux ARM64. ## Contract and boundary impact - Semantic owner and earliest changed stage: none — authored docs only. - CLI and MCP/tool-catalog contract: none. - Provider, bridge, target-format, or platform compatibility: documents an existing requirement for the already-supported macOS x64/arm64 Ghidra hosts; no admitted surface changes. - Evidence, artifact, provenance, or reconstruction contract: none. - Process execution, authorization, cleanup, or containment impact: none. - Generated metadata (`docs/public/product-catalog.json`), package, or installation impact: none. ## Evidence and regression coverage - Tests added or updated: none (documentation only). - Base reproduction or other evidence: executed the documented commands on macOS 15.7.9 / Apple silicon against the official Ghidra 12.1.4 `PUBLIC` archive with Temurin JDK 21, then confirmed REA 6.4.0 accepts the result and decompiles a real Mach-O. Rebuilt from a pristine copy of the C++ sources (no object files) to confirm the published recipe is the one that works; the resulting binary was byte-identical (same SHA-256) to the admitted one. - User-visible CLI/MCP output (if applicable): `rea doctor --provider ghidra --json` reports the `ghidra-native_decompiler` check as passing with the observed `mach-o` architecture instead of incompatible, and a `rea decompile <mach-o> <symbol> --provider ghidra --json` call returns pseudocode with the usual evidence envelope. - Remaining proof gaps: Intel macOS (`os/mac_x86_64`) is documented from the same Makefile path but was not exercised on Apple silicon; Linux ARM64 remains as previously documented. ## Validation performed - `npm ci` then `npm run docs:check` — 6/6 tasks successful, exit 0. - `npx oxfmt --check docs/installation.md` — "All matched files use the correct format." - `make ghidra_opt -j… ARCH_TYPE="-arch arm64" ADDITIONAL_FLAGS="-mmacosx-version-min=12.0"` in a pristine copy of `src/decompile/cpp` — exit 0, output `Mach-O 64-bit executable arm64`, identical SHA-256 to the admitted file. - `rea doctor --provider ghidra --json` — `ghidra`, `ghidra-version` (12.1.4), `ghidra-headless`, `ghidra-native_decompiler`, and `ghidra-java` checks pass. ## Compatibility, safety, and release - Breaking changes or migration steps: none. - Real Hopper/Ghidra, browser, or OS coverage: real Ghidra 12.1.4 headless on macOS arm64; the documented build path was run twice (fresh archive, pristine source copy). - Package or release metadata impact: none. - Security, privacy, process, or containment review: none — no runtime, secrets, or containment surface touched; the guide keeps telling operators to build the component themselves rather than having REA install native tools. ## Review checklist - [x] This PR addresses a concrete problem or an agreed enhancement. - [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. - [ ] 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 00:56:12 +00:00

closed this issue
added the
pull-request
label

bsakaguchi referenced this issue

2026-10-31 01:14:32 +00:00

[PR #4868] feat(objdump): add dynamic section facets for stripped binaries #6449

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

No description provided.

Rows
Columns