REA/Kuna stored-pointer xref bug report with multi-format relocation fixtures

What they did

The author built a set of small, unexecuted static fixtures to isolate a producer-boundary bug in REA's Kuna integration. Starting from a macOS arm64 Mach-O built with clang (-O0 -g0) containing a noinline audit_target and a volatile function pointer, they compared three sources: direct Kuna 1.988 `kuna xrefs --to <addr> --json`, REA #8509 head `7f344af1a` via MCP (`xrefs`, `trace_feature`), and independent controls (`nm -nm`, `dyld_info -fixups`, REA/Ghidra 12.1.4). Direct Kuna reported `data_refs_count: 1` with a chained-fixups pointer from 0x100004000 to 0x1000003c0, while REA normalized xrefs to `[]` and trace_feature returned the function with no references, no truncation, and no residual unknowns. They then extended the controls across formats: an x86-64 ELF shared object with an R_X86_64_RELATIVE slot, a PE DLL with a DIR64 base relocation (noting REA refuses Kuna for PE), an ELF with a symbol-based R_X86_64_64 relocation and preemption caveats, a PLT/JUMP_SLOT alias case, and an indirect-call handoff through a stored slot. They also ran an unmerged producer prototype that recovered pointer addresses and an exploratory trace source-retention change that linked xrefs Evidence into exported bundles. All targets were read-only, never executed, and hashes were recorded.

How it went

Produced a thorough, well-evidenced bug report with reproduction steps, exact addresses, hashes, and cross-provider controls. The root cause was traced by source inspection to `xrefsDocument` in `KunaReferenceFiles.ts` lacking `data_refs`/`data_refs_coverage` fields and `parseKunaIncomingReferences` counting only instruction rows. Prototype experiments showed pointer recovery is feasible but incomplete: traces still lacked typed pointer kinds and source links, and the ELF control returned nothing. No fix shipped in #8509; the report explicitly frames prototype results as observations, not fixes.

Worth knowing

All findings are from one host, one toolchain, and generated fixtures, so they are not completeness or prevalence claims. Addresses are build-specific. The PE case is an upstream-format control, not an REA/Kuna regression. ELF default-visible globals can be preempted, so static pointer rows are not proof of runtime targets. Stored pointers do not prove runtime calls. The prototype and trace-retention changes are unmerged and do not add typed pointer kinds inline.

Wiring

Fixtures were compiled with clang (Mach-O arm64, -O0 -g0) and LLVM tooling for ELF/PE. Direct provider calls used Kuna 1.988 CLI with `--json`. REA was run at commit 7f344af1a over MCP on Node 24.22.1, exercising both full and compact schema profiles, calling `xrefs` and `trace_feature`. Controls used `nm -nm`, `dyld_info -fixups`, LLVM `readobj`/disassembly, and REA/Ghidra 12.1.4 with JDK 21 for rebased `inspect_native_instruction` and DATA reference checks. Source inspection targeted `KunaReferenceFiles.ts`. All analysis was static and read-only; targets were never executed and SHA-256 digests were recorded before and after.

Try it yourself

Investigate whether REA's Kuna provider drops relocation-backed stored-pointer references. Build a small unexecuted Mach-O arm64 fixture with a noinline function and a volatile function pointer, then compare direct `kuna xrefs --to <addr> --json` (checking data_refs_count and data_refs_coverage) against REA MCP `xrefs` and `trace_feature` for the same address. Cross-check with `dyld_info -fixups` and REA/Ghidra. Inspect `xrefsDocument` in `KunaReferenceFiles.ts` and `parseKunaIncomingReferences` to see whether data_refs fields are parsed and projected. Repeat with an x86-64 ELF R_X86_64_RELATIVE fixture and a PE DIR64 control. Report exact addresses, hashes, and whether omission is disclosed in Evidence.