Priyanshu KumarandClaude Opus 5.5
d7d966651c
libsla-sys vendors 0verflowme/ghidra r2sleigh-sleigh-context-12: Ghidra master 918acd744d (2026-10-13) with PF0 and W2 re-ported onto GP-6554's ParserContext. The parse-depth check this tree carried is gone: GP-6554 bounds the operand path and operand index itself (LowlevelError), and context.hh is the fork's exactly. metatype.cc joins CORE (marshal.hh includes it). API moves: GP-2493 renames CPUI_EXTRACT to CPUI_ZPULL and adds CPUI_SPULL (74, CPUI_MAX 75); libsla maps them to AnalysisOp::Extract and the new SignedExtract, refused at the lift boundary as every analysis op is. sleigh-compiler's slgh_compile.cc is re-ported onto 918acd744d (main and run_xml dropped, errors collected), and largeTemporaryWarning is gone with GP-6316, which raised the temporary limit to 256 bytes and made a larger one an error. Census: 20 files, 1477 lines, every one a Sleigh temporary renumbered, one to one within each function: GP-6237 inserts the cross-build bits at bit 8 of a unique offset where they were shifted in by 4, so the compiler lays the unique space out anew. GP-5581's truncated unique reads would have moved C in manual_limits_O2 and rv_O2 and lost switch-hello-world's aarch64 table; the two previous commits read them as pieces and through the temporary's copy. Two r2s command tests named temporaries by their offset (`tmp_11f80_3`); they read the output with the offset dropped, as the census normaliser does. Co-Authored-By: Claude Opus 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_01456qmqCGpCWJkrg6JUZNNM
About
This supports calling the Ghidra SLEIGH compiler from Rust code. Processors in Ghidra are described by .slaspec files, but SLEIGH libraries operates on the compiled .sla files. Now the compiled .sla artifacts can be produced directly from Rust code.
What's New?
For latest details check out the CHANGELOG.
Usage
let mut compiler = SleighCompiler::default();
let input_file = std::path::Path::new("Ghidra/Processors/x86/data/languages/x86-64.slaspec");
let output_file = std::path::Path::new("x86-64.sla");
compiler.compile(input_file, output_file)?;
// Success! Can now use compiled x86-64.sla file
Compiler Details
The internal SLEIGH compiler is built from Ghidra master 918acd744d (2026-10-13), the commit libsla-sys vendors, whose headers it compiles against.
The SLEIGH compiler may report warnings in its response which reference command line switches. For details on any reported switches, refer to SLEIGH compiler usage.
Compatibility
In Ghidra 11.1 the .sla file format was changed to a compressed format. To interface with tooling based on versions of Ghidra older than 11.1, use version 1.0 of this crate.
cargo add sleigh-compiler@1
Uncompressed Output
The uncompressed form of the .sla file can be obtained by setting debug_output to true in the compiler options.
let mut compiler = SleighCompiler::new(SleighCompilerOptions {
// This will produce uncompressed .sla files
debug_output: true,
..Default::default()
});
let input_file = std::path::Path::new("Ghidra/Processors/x86/data/languages/x86-64.slaspec");
let output_file = std::path::Path::new("x86-64.sla");
compiler.compile(input_file, output_file)?;
Be aware that these uncompressed files are not compatible with any tooling based on Ghidra. Later versions of the tooling do not understand this format, and the Ghidra team has no plans to add such support (#6416). Earlier versions of the tooling will reject the uncompressed file because the SLA format version has been bumped from 3 to 4.
Related Work
Check out the libsla crate for interfacing with the Ghidra SLEIGH library to disassemble native instructions into pcode!