Overview
This series explains why SLEIGH processor specifications are a trust boundary for Ghidra disassembly, decompilation, emulation, and security analysis. It traces how constructors and context decode bytes, how p-code models state changes, and how InSPECtor uses symbolic path and state generation with hardware comparison to test represented behavior. Results across x86-64, AArch64, ARM/Thumb, RISC-V, and MSP430 show why structural coverage, behavioral agreement, and root-cause triage are different kinds of evidence. The method supports bounded assurance, but does not prove ISA completeness, sequence behavior, unpredictable cases, or fidelity beyond what the language and test environment can express.
Learning outcomes
- SLEIGH specifications are executable claims about instruction decoding and machine-state effects.
- GenSYS reaches represented constructor paths by preserving context, overlap, attachments, and deferred constraints.
- Targeted architectural states and hardware comparison test semantic fidelity beyond structural coverage.
- InSPECtor supports bounded assurance, not proof of ISA completeness or universal correctness.
Keywords
Preview every chapter · Unlock full text, audio, and video from chapter 4
PlansFAQ
What does a SLEIGH specification determine?
It determines how supported machine-code bytes are decoded and how the selected instruction changes modeled architectural state. Those claims feed Ghidra disassembly, decompilation, and p-code-based emulation.
How does InSPECtor test SLEIGH specifications?
InSPECtor follows SLEIGH constructor paths, solves their constraints for concrete encodings and edge-case states, and compares a SLEIGH-derived emulator with hardware. Manual triage then separates root causes from other explanations.
Does high constructor coverage prove a SLEIGH specification is correct?
No. Constructor coverage measures reachability of represented decoding structure, not semantic fidelity, ISA completeness, or every machine state. Hardware agreement is still scoped to the tested case and environment.
What can a mismatch between SLEIGH emulation and hardware mean?
It can indicate a decoding or semantic defect, but it may also reflect unsupported behavior, configuration mismatch, unpredictability, unmodeled features, or a language limit. Triage determines the appropriate response.