Skip to content

Unsupported Path Fallback

Jump to bottom
김성주 edited this page May 1, 2026 · 1 revision

Unsupported Paths and Fallbacks

Real binaries routinely exercise corners of semantics, loaders, or analyses that are still evolving. This page describes how to recognize degraded or fallback behavior and how to escalate evidence without guessing.

Symptoms that suggest partial support

You might see:

  • Unexpected control-flow shapes versus disasm at the same address.
  • Sparse typing or generic placeholders where richer recovery was expected.
  • JSON payloads that include engine routing or fallback annotations—consult docs/CLI.md for the fields available on your version.

Always correlate three views: info / list → disasm --function → decomp.

Practical checklist

  1. Confirm CLI flags: Prefer documented subcommands and explicit --addr scopes.
  2. Try JSON: Capture structured metadata alongside pseudocode (decomp --json).
  3. Narrow scope: Single-function decomp before --all sweeps.
  4. Cross-check lifting: Inspect raw lifted regions with disasm when pseudocode seems inconsistent with assembly shape.

Comparison workflows

When evaluating whether Fission differs from another engine:

  • Prefer the canonical benchmark runner under benchmark/full_benchmark/ over manual copy/paste from GUI tools—see Comparing with Ghidra.
  • Treat Ghidra as a reference surface, not an oracle—parity gaps may be documented explicitly.

Reporting upstream issues

Effective bug reports include:

  • Binary identity (hash), OS/load configuration, exact CLI invocation.
  • Minimal address or reproducer corpus entry if possible.
  • Expected vs observed behavior with disassembly context.

Follow contributor routing in AGENTS.md: fixes belong in the semantic owner crate, not only in printers or UX layers.

Related wiki pages

Related repository docs

Clone this wiki locally