morluto/rea

Fork 0

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

[GH-ISSUE #8183] [Design] Recover function references when the provider lacks a general name inventory #6467

New issue

Open

opened 2026-11-01 21:11:22 +00:00 by bsakaguchi · 6 comments

bsakaguchi commented

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

Owner

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

Before submitting

I searched the open and closed issues and pull requests for a related discussion.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This discussion does not include credentials, private samples, or sensitive target data.

Decision needed

When an analyst knows a selector denotes a function, can REA provide an actionable route to its references on providers without a general name inventory, without claiming that the name is unique among all symbols?

Context and evidence

In a real REA 6.8.0 stdio MCP session on macOS arm64, using Kuna 1.986 and a self-built Mach-O, find_xrefs_to_name({name:"_audit_base64_character"}) returned capability_unavailable because Kuna does not declare list_names. Its user-facing remediation was only “Choose another analysis or target.”

In the same session, procedure_address({procedure:"_audit_base64_character"}) returned 0x100000378; xrefs({address:"0x100000378"}) then returned 0x1000003b0. Kuna's limitations state that its reference walk can omit edges, so this is one observed reference, not a complete runtime caller set. The fixture's source calls that function from main. No target code was executed.

The existing general find_xrefs_to_name contract resolves names across the provider's name inventory; Kuna lacks that inventory. Its behavior therefore follows the present capability declaration. The unresolved question is whether an agent who already knows the name is a procedure can find and use the narrower, working path without a generic dead-end error. This is not evidence that a missing name is absent among all symbols.

Expected interaction with targets

Read the selected local binary and run the caller-selected provider; no target execution or mutation.

Boundary details (optional)

Keep function-selector resolution separate from exact-name lookup over all symbols. A function can share a spelling with data or other functions; preserve ambiguity and scope rather than silently falling back to the first match. Existing #5908 describes why the general workflow must not choose the first ambiguous address. Kuna's Mach-O function inventory also has known non-function rows (#8168).

Options and tradeoffs

Compare more specific, conditional recovery guidance using existing procedure_address then xrefs when the caller knows it is a function, an explicit selector-kind in the existing workflow, or leaving the current contract unchanged. Avoid a Kuna-only duplicate xref tool and do not reinterpret an unavailable name inventory as proof of uniqueness or absence. Any changed composition must update capability projection, provenance and per-provider tests.

Verification available so far

I have a prototype or observed results

Success criteria and open questions

Exercise function, data-symbol, missing and ambiguous-name cases across supported providers; preserve partial reference coverage, caller-selected scope, ordered errors and CLI/MCP parity. A real agent-selection trace is still needed to measure whether clearer guidance changes behavior.

References

Existing name-ambiguity issue: https://github.com/morluto/rea/issues/5908

Named global and provider comparison on Kuna 1.989

On REA main 9ebbe67e and a source-owned, unexecuted arm64 Mach-O with global _observed_global at 0x100004000, Ghidra 12.1.4 find_xrefs_to_name resolved the global and returned pointer slot 0x100004008 among its sources in both MCP profiles. Kuna 1.989 returned capability_unavailable for the same find_xrefs_to_name call because list_names is not declared; the recovery remained the generic choice of another analysis or target. Direct Kuna xrefs with this name reported no inventory entry and recommended inspecting the target for an address. Using the independently established address returned an empty list because the separately reported stored-pointer rows are omitted by REA (#8510). Thus an address-only handoff addresses name resolution but does not by itself recover this pointer on Kuna. The Ghidra name workflow follows the existing general contract and is an available alternative for this fixture.

The target SHA-256 167f7b743182b707705cc06a5318222c82d69b4dd4f19c32213e078f717d4aec remained unchanged. This is one named data case in compact and full MCP, not a claim that every data name fails in Kuna or that either provider's reference inventory is complete. Compared with the older #8396 reproduction, current main's direct Kuna missing-name error identifies an inventory miss and supplies address-oriented recovery for this case.

Missing-name MCP control

On #8753 head e64b3c54b13e6b68a22e482ce1662527a885dfae, the same owned unexecuted Mach-O used in the preceding global-name control was queried with _not_present_92 through real stdio MCP in compact and full profiles. Ghidra 12.1.4 find_xrefs_to_name returned {status: "unresolved", reason: "name_not_found"} rather than the CLI resolver's missing-name error; the result preserves the caller's name. Kuna 1.989 returned capability_unavailable because list_names is not declared, with generic recovery. Direct Kuna xrefs for the same name reported an inventory miss and address-oriented guidance. The fixture digest stayed 167f7b743182b707705cc06a5318222c82d69b4dd4f19c32213e078f717d4aec and was not executed. This confirms separate adapter and provider outcomes for one missing name; it does not establish global symbol absence or agent behavior.

Originally created by @morluto on GitHub (Oct 30, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8183 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related discussion. - [x] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here. - [x] This discussion does not include credentials, private samples, or sensitive target data. ### Decision needed When an analyst knows a selector denotes a function, can REA provide an actionable route to its references on providers without a general name inventory, without claiming that the name is unique among all symbols? ### Context and evidence In a real REA 6.8.0 stdio MCP session on macOS arm64, using Kuna 1.986 and a self-built Mach-O, `find_xrefs_to_name({name:"_audit_base64_character"})` returned `capability_unavailable` because Kuna does not declare `list_names`. Its user-facing remediation was only “Choose another analysis or target.” In the same session, `procedure_address({procedure:"_audit_base64_character"})` returned `0x100000378`; `xrefs({address:"0x100000378"})` then returned `0x1000003b0`. Kuna's limitations state that its reference walk can omit edges, so this is one observed reference, not a complete runtime caller set. The fixture's source calls that function from `main`. No target code was executed. The existing general `find_xrefs_to_name` contract resolves names across the provider's name inventory; Kuna lacks that inventory. Its behavior therefore follows the present capability declaration. The unresolved question is whether an agent who already knows the name is a procedure can find and use the narrower, working path without a generic dead-end error. This is not evidence that a missing name is absent among all symbols. ### Expected interaction with targets Read the selected local binary and run the caller-selected provider; no target execution or mutation. ### Boundary details (optional) Keep function-selector resolution separate from exact-name lookup over all symbols. A function can share a spelling with data or other functions; preserve ambiguity and scope rather than silently falling back to the first match. Existing #5908 describes why the general workflow must not choose the first ambiguous address. Kuna's Mach-O function inventory also has known non-function rows (#8168). ### Options and tradeoffs Compare more specific, conditional recovery guidance using existing `procedure_address` then `xrefs` when the caller knows it is a function, an explicit selector-kind in the existing workflow, or leaving the current contract unchanged. Avoid a Kuna-only duplicate xref tool and do not reinterpret an unavailable name inventory as proof of uniqueness or absence. Any changed composition must update capability projection, provenance and per-provider tests. ### Verification available so far I have a prototype or observed results ### Success criteria and open questions Exercise function, data-symbol, missing and ambiguous-name cases across supported providers; preserve partial reference coverage, caller-selected scope, ordered errors and CLI/MCP parity. A real agent-selection trace is still needed to measure whether clearer guidance changes behavior. ### References Existing name-ambiguity issue: https://github.com/morluto/rea/issues/5908 ### Named global and provider comparison on Kuna 1.989 On REA main `9ebbe67e` and a source-owned, unexecuted arm64 Mach-O with global `_observed_global` at `0x100004000`, Ghidra 12.1.4 `find_xrefs_to_name` resolved the global and returned pointer slot `0x100004008` among its sources in both MCP profiles. Kuna 1.989 returned `capability_unavailable` for the same `find_xrefs_to_name` call because `list_names` is not declared; the recovery remained the generic choice of another analysis or target. Direct Kuna `xrefs` with this name reported no inventory entry and recommended inspecting the target for an address. Using the independently established address returned an empty list because the separately reported stored-pointer rows are omitted by REA (#8510). Thus an address-only handoff addresses name resolution but does not by itself recover this pointer on Kuna. The Ghidra name workflow follows the existing general contract and is an available alternative for this fixture. The target SHA-256 `167f7b743182b707705cc06a5318222c82d69b4dd4f19c32213e078f717d4aec` remained unchanged. This is one named data case in compact and full MCP, not a claim that every data name fails in Kuna or that either provider's reference inventory is complete. Compared with the older #8396 reproduction, current main's direct Kuna missing-name error identifies an inventory miss and supplies address-oriented recovery for this case. ### Missing-name MCP control On #8753 head `e64b3c54b13e6b68a22e482ce1662527a885dfae`, the same owned unexecuted Mach-O used in the preceding global-name control was queried with `_not_present_92` through real stdio MCP in compact and full profiles. Ghidra 12.1.4 `find_xrefs_to_name` returned `{status: "unresolved", reason: "name_not_found"}` rather than the CLI resolver's missing-name error; the result preserves the caller's name. Kuna 1.989 returned `capability_unavailable` because `list_names` is not declared, with generic recovery. Direct Kuna `xrefs` for the same name reported an inventory miss and address-oriented guidance. The fixture digest stayed `167f7b743182b707705cc06a5318222c82d69b4dd4f19c32213e078f717d4aec` and was not executed. This confirms separate adapter and provider outcomes for one missing name; it does not establish global symbol absence or agent behavior.

bsakaguchi added the

enhancement

triage

labels

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

bsakaguchi commented

2026-11-01 21:11:22 +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:23 +00:00

Author

Owner

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

Ambiguous C++ overload and exact-name controls

On REA b43c329df779708e43ae297f498a844e45d9c923, I built an unexecuted arm64 Mach-O with audit_over(int) and audit_over(long), plus a caller that invokes both. llvm-nm and disassembly independently identify the two entries and calls. Real REA/Ghidra 12.1.4 and REA/Kuna 1.986 stdio MCP both returned two search_procedures("audit_over") rows, then rejected procedure_address("audit_over") as ambiguous with both exact addresses. xrefs on the selected addresses returned their respective call sites (0x100000428 and 0x100000434); Ghidra additionally returned other reference rows. Kuna retained its limitation that its walk can omit references, so these are observed sites, not a completeness claim.

The general find_xrefs_to_name("audit_over") rejected ambiguity on Ghidra and returned capability unavailable on Kuna. A function-scoped recovery must therefore preserve both candidates and require address selection, rather than silently using one. The exact Mach-O symbol spellings __Z10audit_overi and __Z10audit_overl resolved to their respective addresses in Ghidra but were not found by REA/Kuna; direct Kuna functions --json --filter audit_over returned the same short name for both and only sub_... aliases. This is one observed symbolized C++ case, not proof that every raw symbol is unavailable or that the provider inventories are equivalent.

The target SHA-256 bce7eb96e644a202eaa0fb1e709f0e82d2ea6389c52244ae87433c0cf8039d74 was unchanged after these probes. No binary was executed. Missing-function and global-data selectors were also refused by procedure_address; that refusal does not establish absence of a data symbol.

@morluto commented on GitHub (Oct 31, 2026): ### Ambiguous C++ overload and exact-name controls On REA `b43c329df779708e43ae297f498a844e45d9c923`, I built an unexecuted arm64 Mach-O with `audit_over(int)` and `audit_over(long)`, plus a caller that invokes both. `llvm-nm` and disassembly independently identify the two entries and calls. Real REA/Ghidra 12.1.4 and REA/Kuna 1.986 stdio MCP both returned two `search_procedures("audit_over")` rows, then rejected `procedure_address("audit_over")` as ambiguous with both exact addresses. `xrefs` on the selected addresses returned their respective call sites (`0x100000428` and `0x100000434`); Ghidra additionally returned other reference rows. Kuna retained its limitation that its walk can omit references, so these are observed sites, not a completeness claim. The general `find_xrefs_to_name("audit_over")` rejected ambiguity on Ghidra and returned capability unavailable on Kuna. A function-scoped recovery must therefore preserve both candidates and require address selection, rather than silently using one. The exact Mach-O symbol spellings `__Z10audit_overi` and `__Z10audit_overl` resolved to their respective addresses in Ghidra but were not found by REA/Kuna; direct Kuna `functions --json --filter audit_over` returned the same short name for both and only `sub_...` aliases. This is one observed symbolized C++ case, not proof that every raw symbol is unavailable or that the provider inventories are equivalent. The target SHA-256 `bce7eb96e644a202eaa0fb1e709f0e82d2ea6389c52244ae87433c0cf8039d74` was unchanged after these probes. No binary was executed. Missing-function and global-data selectors were also refused by `procedure_address`; that refusal does not establish absence of a data symbol.

bsakaguchi commented

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

Author

Owner

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

Existing Mach-O export-to-address recovery

The overloaded fixture above has an existing route that does not require Ghidra. On REA b43c329df779708e43ae297f498a844e45d9c923, rea inspect-macho returned the exact __Z10audit_overi and __Z10audit_overl exports at 0x1000003f8 and 0x100000408. In a real REA/Kuna 1.986 MCP session on the same target, inspect_macho({detail:"complete"}) returned the same normalized facts, and passing each returned address to xrefs found its respective call site. The same procedure on the exported _audit_global address returned two address-only references; the export row alone does not establish a function or reference kind.

The Mach-O result identifies the selected arm64 image and target digest and explicitly marks the merged nm/dyld_info export inventory non-exhaustive. Kuna's reference results separately warn that references can be omitted. This is an analyst-directed join of exact exported names and addresses for this one symbolized fixture, not an automatic, complete, all-symbol or cross-image lookup. CLI and MCP normalized inspection output matched; their Evidence IDs differ because the CLI recorded an explicit input path while the MCP call used the open target. Target SHA-256 stayed unchanged; it was not executed.

This narrows the design question: guide users toward existing exact exported-symbol evidence when it applies, while retaining symbol scope, slice and reference limitations; do not silently equate arbitrary function and data names or treat a missing export as absence.

@morluto commented on GitHub (Oct 31, 2026): ### Existing Mach-O export-to-address recovery The overloaded fixture above has an existing route that does not require Ghidra. On REA `b43c329df779708e43ae297f498a844e45d9c923`, `rea inspect-macho` returned the exact `__Z10audit_overi` and `__Z10audit_overl` exports at `0x1000003f8` and `0x100000408`. In a real REA/Kuna 1.986 MCP session on the same target, `inspect_macho({detail:"complete"})` returned the same normalized facts, and passing each returned address to `xrefs` found its respective call site. The same procedure on the exported `_audit_global` address returned two address-only references; the export row alone does not establish a function or reference kind. The Mach-O result identifies the selected arm64 image and target digest and explicitly marks the merged `nm`/`dyld_info` export inventory non-exhaustive. Kuna's reference results separately warn that references can be omitted. This is an analyst-directed join of exact exported names and addresses for this one symbolized fixture, not an automatic, complete, all-symbol or cross-image lookup. CLI and MCP normalized inspection output matched; their Evidence IDs differ because the CLI recorded an explicit input path while the MCP call used the open target. Target SHA-256 stayed unchanged; it was not executed. This narrows the design question: guide users toward existing exact exported-symbol evidence when it applies, while retaining symbol scope, slice and reference limitations; do not silently equate arbitrary function and data names or treat a missing export as absence.

bsakaguchi commented

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

Author

Owner

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

ELF exported-symbol handoff and PLT controls

I compiled an unexecuted x86-64 ELF shared object containing exported C++ overloads and a caller. On REA b43c329df779708e43ae297f498a844e45d9c923, inspect_native_exports returned _Z10audit_overi and _Z10audit_overl with ELF values 0x1430 and 0x1440, type function, and complete dynamic-export coverage for this fixture. It separately identified the exported global as type object; its documented scope excludes non-exported symbols.

In real Kuna 1.986 MCP, the two implementation entries were at those ELF values, but exact mangled procedure_address selectors failed and xrefs on the implementations returned empty. Independent LLVM disassembly shows the caller invokes local PLT stubs at 0x14a0 and 0x14b0, rather than directly calling those bodies. Both providers reached the matching stub in trace_call_path; both returned not_reached for the body in the call-only graph. That result does not prove the body is unreachable or establish dynamic binding. Kuna stub pseudocode described an indirect jump-as-call; its call graph excludes jump edges.

Ghidra 12.1.4 instead mapped the implementation to 0x101430 and stub to 0x1014a0. procedure_info identified the stub as a thunk with target 0x101430, and outgoing references included a computed jump there. address_to_file_offset(0x101430) returned 1072, corroborated by the ELF load segment and independent LLVM inspection. Supplying the unrebased export value 0x1430 to Ghidra xrefs succeeded with an empty list, while a separate file-offset query reported no initialized file-backed memory there. A mapped interior address also returned empty xrefs, whereas the mapped implementation had references. Thus an export value must be joined to the selected provider's coordinate context, not forwarded blindly.

The fixture's R_X86_64_JUMP_SLOT rows name the corresponding exports. That is static relocation evidence, not proof of a runtime binding; interposition and loading remain unknown. The target SHA-256 fddfbee55ec830b6d8c79d25655be208473857878f0670a8151f42947b122f07 remained unchanged. This one shared object and host do not establish general ELF or provider coverage.

@morluto commented on GitHub (Oct 31, 2026): ### ELF exported-symbol handoff and PLT controls I compiled an unexecuted x86-64 ELF shared object containing exported C++ overloads and a caller. On REA `b43c329df779708e43ae297f498a844e45d9c923`, `inspect_native_exports` returned `_Z10audit_overi` and `_Z10audit_overl` with ELF values `0x1430` and `0x1440`, type `function`, and complete dynamic-export coverage for this fixture. It separately identified the exported global as type `object`; its documented scope excludes non-exported symbols. In real Kuna 1.986 MCP, the two implementation entries were at those ELF values, but exact mangled `procedure_address` selectors failed and `xrefs` on the implementations returned empty. Independent LLVM disassembly shows the caller invokes local PLT stubs at `0x14a0` and `0x14b0`, rather than directly calling those bodies. Both providers reached the matching stub in `trace_call_path`; both returned `not_reached` for the body in the **call-only** graph. That result does not prove the body is unreachable or establish dynamic binding. Kuna stub pseudocode described an indirect `jump-as-call`; its call graph excludes jump edges. Ghidra 12.1.4 instead mapped the implementation to `0x101430` and stub to `0x1014a0`. `procedure_info` identified the stub as a thunk with target `0x101430`, and outgoing references included a computed jump there. `address_to_file_offset(0x101430)` returned `1072`, corroborated by the ELF load segment and independent LLVM inspection. Supplying the unrebased export value `0x1430` to Ghidra `xrefs` succeeded with an empty list, while a separate file-offset query reported no initialized file-backed memory there. A mapped interior address also returned empty xrefs, whereas the mapped implementation had references. Thus an export value must be joined to the selected provider's coordinate context, not forwarded blindly. The fixture's `R_X86_64_JUMP_SLOT` rows name the corresponding exports. That is static relocation evidence, not proof of a runtime binding; interposition and loading remain unknown. The target SHA-256 `fddfbee55ec830b6d8c79d25655be208473857878f0670a8151f42947b122f07` remained unchanged. This one shared object and host do not establish general ELF or provider coverage.

bsakaguchi commented

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

Author

Owner

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

Ghidra file-offset mapping control

On the same ELF shared object, a real Ghidra 12.1.4 MCP inspect_native_load_image({detail:"complete"}) reported image base 0x100000 and a .text mapping from source file offset 1072 to analysis address 0x101430. Its independent verification status was unsupported for ELF, so these are Ghidra's load observations, not independently verified mapping claims. The selected artifact SHA-256 matched the export observation.

Using the source file offset 1072 established from the independently inspected ELF program headers, procedure_pseudo_code({procedure:"file-offset:0x430"}) returned the same audit_over(int) body as the exact analysis address 0x101430 and exact mangled selector. Its Evidence explicitly recorded file_offset: 1072, mapped_address: "0x101430", and procedure_address: "0x101430". A bare 0x430 also succeeded by the documented address-then-offset fallback; a bare ELF symbol value 0x1430 failed after being interpreted as a file offset, with guidance to inspect mappings. These are one image's observations, not a fixed-base mapping rule.

I also ran the suggested CLI inspect-native-load-image <path> --provider ghidra --json with the configured JDK: it succeeded, although command help emphasizes --format json. The target hash remained unchanged and it was not executed. This supports explicit file-offset selection when the caller has independently established that offset; whether REA should provide an integrated ELF-symbol-value conversion remains the design question. Related selector ambiguity: #8178.

@morluto commented on GitHub (Oct 31, 2026): ### Ghidra file-offset mapping control On the same ELF shared object, a real Ghidra 12.1.4 MCP `inspect_native_load_image({detail:"complete"})` reported image base `0x100000` and a `.text` mapping from source file offset `1072` to analysis address `0x101430`. Its independent verification status was `unsupported` for ELF, so these are Ghidra's load observations, not independently verified mapping claims. The selected artifact SHA-256 matched the export observation. Using the source file offset `1072` established from the independently inspected ELF program headers, `procedure_pseudo_code({procedure:"file-offset:0x430"})` returned the same `audit_over(int)` body as the exact analysis address `0x101430` and exact mangled selector. Its Evidence explicitly recorded `file_offset: 1072`, `mapped_address: "0x101430"`, and `procedure_address: "0x101430"`. A bare `0x430` also succeeded by the documented address-then-offset fallback; a bare ELF symbol value `0x1430` failed after being interpreted as a file offset, with guidance to inspect mappings. These are one image's observations, not a fixed-base mapping rule. I also ran the suggested CLI `inspect-native-load-image <path> --provider ghidra --json` with the configured JDK: it succeeded, although command help emphasizes `--format json`. The target hash remained unchanged and it was not executed. This supports explicit file-offset selection when the caller has independently established that offset; whether REA should provide an integrated ELF-symbol-value conversion remains the design question. Related selector ambiguity: #8178.

bsakaguchi commented

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

Author

Owner

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

Further real-provider controls on current main 6e9ee97a69cb16c7150d8b550e705cba055ee4f0 clarify the existing alternatives:

On one unexecuted arm64 Mach-O, Kuna 1.986 MCP xrefs({address:"_evaluate"}) succeeded and returned the same address-only result as xrefs({address:"0x100000430"}). An inventory data name global_count also succeeded and matched xrefs({address:"0x100004000"}); the Evidence locations record the resolved addresses. Both named queries also succeeded through rea xrefs. Kuna's explicit reference-discovery limitation remained present.
This is not general name-inventory resolution: on a second fixture, a known exported data name _audit_global was absent from Kuna's inventory and named xrefs failed; the exact exported address worked. A shared overloaded function name was refused with both candidate addresses, not silently picked. The associated misleading failure/recovery wording is tracked separately in #8396.
Ghidra on the second fixture rejected names at MCP xrefs address parsing, but find_xrefs_to_name resolved its exact data symbol and returned references. CLI rea xrefs resolved that Ghidra data name; the ambiguous overload was refused. Thus the provider-specific named xrefs route is useful when a Kuna inventory name is already known, but cannot be presented as a provider-independent or globally exhaustive exact-name lookup.

All successful MCP replies used the fetched compact output schemas, and each target's SHA-256 remained unchanged. One macOS host and two fixtures were tested; no autonomous agent-selection outcome is claimed. This suggests any recovery guidance should mention its conditional inventory/provider scope and keep the general find_xrefs_to_name contract distinct.

@morluto commented on GitHub (Oct 31, 2026): Further real-provider controls on current main `6e9ee97a69cb16c7150d8b550e705cba055ee4f0` clarify the existing alternatives: - On one unexecuted arm64 Mach-O, Kuna 1.986 MCP `xrefs({address:"_evaluate"})` succeeded and returned the same address-only result as `xrefs({address:"0x100000430"})`. An inventory data name `global_count` also succeeded and matched `xrefs({address:"0x100004000"})`; the Evidence locations record the resolved addresses. Both named queries also succeeded through `rea xrefs`. Kuna's explicit reference-discovery limitation remained present. - This is **not** general name-inventory resolution: on a second fixture, a known exported data name `_audit_global` was absent from Kuna's inventory and named `xrefs` failed; the exact exported address worked. A shared overloaded function name was refused with both candidate addresses, not silently picked. The associated misleading failure/recovery wording is tracked separately in #8396. - Ghidra on the second fixture rejected names at MCP `xrefs` address parsing, but `find_xrefs_to_name` resolved its exact data symbol and returned references. CLI `rea xrefs` resolved that Ghidra data name; the ambiguous overload was refused. Thus the provider-specific named `xrefs` route is useful when a Kuna inventory name is already known, but cannot be presented as a provider-independent or globally exhaustive exact-name lookup. All successful MCP replies used the fetched compact output schemas, and each target's SHA-256 remained unchanged. One macOS host and two fixtures were tested; no autonomous agent-selection outcome is claimed. This suggests any recovery guidance should mention its conditional inventory/provider scope and keep the general `find_xrefs_to_name` contract distinct.

bsakaguchi referenced this issue

2026-11-01 21:47:38 +00:00

[PR #6759] [MERGED] fix(cli): advertise required CLI selector choices #7407

bsakaguchi added

enhancement

and removed

enhancement

labels

2026-11-03 09:20:05 +00:00