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
- Confirm CLI flags: Prefer documented subcommands and explicit
--addr scopes.
- Try JSON: Capture structured metadata alongside pseudocode (
decomp --json).
- Narrow scope: Single-function
decomp before --all sweeps.
- 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