use-ghidra

Use ghidra-cli to start a bridge on a project, then run a GhidraScript such as Decompile.java via `ghidra script run`. The script accepts seeds by address, name, regex, string reference, or tag and writes an indexed C file with callers and callees.

Thin universal Mach-O files with `lipo -thin arm64` before import, or use analyzeHeadless with BinaryLoader, a base address, and a processor language ID for headerless bytes. Set GHIDRA_HEADLESS_MAXMEM on the bridge's starting command to control heap size.

Only one process can open a Ghidra project at a time, so headless runs beside a resident bridge abort with LockException until `ghidra stop`. Crashes leave `<name>.lock` and `<name>.lock~` files under $GHIDRA_PROJECT_DIR that must be removed by hand.

This happens when no analysis has run after import, even though `program list` may show analyzed: true. Run `ghidra analyze --project <name>` in the background, then verify the function count exceeds the size-1 import stubs.

Yes, a Headers.java GhidraScript parses C headers with the CParser under preprocessor macros captured from clang, applying prototypes to named functions. Include paths must be directories, and shims are needed for constructs like __has_include and namespaced attributes.

Jobs run one at a time and queue, and `script java` or `script python` modes are unsupported through the bridge. Decompiles past the 300-second socket read require GHIDRA_CLI_READ_TIMEOUT=0, and one file failing to compile fails the whole script bundle.