rz-ghidra: Ghidra's decompiler inside Rizin

A C++ port of the decompiler, not a Ghidra dependency

rz-ghidra is an integration of the Ghidra decompiler and Sleigh Disassembler for Rizin, and the sentence that explains its design is the second one in the README.

It is solely based on the decompiler part of Ghidra, which is written entirely in C++, so Ghidra itself is not required at all and the plugin can be built self-contained.

That is the whole architectural decision. Ghidra's decompiler is written in C++ and its processor specifications are compiled into a language called Sleigh, so a C++ port can carry both the decompiler and the disassembler across without dragging in the Java parts of Ghidra, the analysis framework, or the GUI. What you end up installing is a Rizin plugin and a directory of Sleigh language files, rather than a second large application.

The lineage is also stated. The project was presented, initially for radare2, at r2con 2019 as part of the Cutter talk, and a link to the recorded session is given with a timestamp pointing at the relevant part. So this began as a way to get Ghidra's decompiler into the radare2 family of tools, and it was later carried over to Rizin.

The repository layout matches the description. There is a ghidra/ directory for the ported sources, src/ for the plugin itself, cutter-plugin/ for the Cutter side, third-party/ for vendored dependencies, a test/ directory, scripts/, and a rz_ghidra.pc.in pkg-config template. The primary language is C++, the licence is LGPL-3.0, and the last push to the dev branch was on 2026-10-12 with release v0.9.0 published on 2026-06-21.

The pdg command family, and the seven config variables

The plugin registers a command family called pdg, and the usage block lists what each one does.

Usage: pdg   # Native Ghidra decompiler plugin
| pdg           # Decompile current function with the Ghidra decompiler
| pdgd          # Dump the debug XML Dump
| pdgx          # Dump the XML of the current decompiled function
| pdgj          # Dump the current decompiled function as JSON
| pdgo          # Decompile current function side by side with offsets
| pdgs          # Display loaded Sleigh Languages
| pdg*          # Decompiled code is returned to rizin as comment

The set is small and each variant answers a different need. pdg is the plain decompilation. pdgo puts the decompiled code side by side with offsets, which is the one to use when you are reading output against a hex dump. pdgj dumps the decompiled function as JSON, which is the machine-readable form for scripting. pdgx dumps the XML of the current function and pdgd dumps a debug XML dump, which is a separate and more verbose artefact. pdgs lists the loaded Sleigh languages, so you can check which architectures the decompiler has actually loaded. And pdg* returns the decompiled code to Rizin as a comment, so the result lands in the disassembly view where you keep working.

That last one is the one that changes how you work. Instead of copying a decompilation out of a side panel, the code comes back into the buffer you are annotating, which means the comment travels with the function when you rename it or move it.

The configuration variables are set with the e command, and there are seven of them:

    ghidra.cmt.cpp: C++ comment style
 ghidra.cmt.indent: Comment indent
     ghidra.indent: Indent increment
       ghidra.lang: Custom Sleigh ID to override auto-detection (e.g. x86:LE:32:default)
    ghidra.linelen: Max line length
   ghidra.nl.brace: Newline before opening '{'
    ghidra.nl.else: Newline before else
 ghidra.sleighhome: SLEIGHHOME

The C++ comment style, the indent increment and the two newline options are formatting controls for the generated C, and the max line length matters for readability in a terminal. ghidra.lang overrides the automatic architecture detection with an explicit Sleigh ID, which is the escape hatch when the decompiler picks the wrong architecture for a mixed binary.

Sleigh files, and why the install step is not optional

One variable does more work than the rest, and the README explains it in its own paragraph.

ghidra.sleighhome must point to a directory containing the *.sla, *.lspec and similar files for the architectures that should be supported by the decompiler. The README also notes this is set up automatically when using the rz-pm package manager or installing as described.

Sleigh is Ghidra's processor specification language, and the compiled artifacts of those specifications are what actually teach the decompiler how to read a particular instruction set. A decompiler without them can only handle a default architecture, which is why the language override exists and why pdgs is a useful first command to run.

The build instructions make the consequence explicit. The install step is necessary for the plugin to work because it includes installing the necessary Sleigh files. So a build that stops at make leaves you with a plugin that loads and then does nothing useful, and the fix is to run make install rather than to debug the plugin.

The build itself is a standard CMake project, and the plugin needs the submodule fetched first:

git submodule init
git submodule update

then configure and build:

mkdir build && cd build
cmake -DCMAKE_INSTALL_PREFIX=~/.local ..
make
make install

Two notes accompany the commands. The CMAKE_INSTALL_PREFIX has to be a location Rizin can load the plugin from, and if you are using Rizin from git you also need to set CMAKE_PREFIX_PATH to the Rizin installation directory. Both of those are the kind of detail that costs an hour when it is missing and takes a minute when it is known.

The Cutter plugin, and the version compatibility rules

There is a second build target for Cutter, and it has a stricter prerequisite.

To build the Cutter plugin you must have Cutter installed from source under some prefix, which can be specified optionally with -DCMAKE_PREFIX_PATH, and then you pass -DBUILD_CUTTER_PLUGIN=ON to cmake:

/my/path/rz-ghidra> mkdir build && cd build
/my/path/rz-ghidra/build> cmake -DBUILD_CUTTER_PLUGIN=ON -DCMAKE_PREFIX_PATH=/path/to/cutter/prefix -DCMAKE_INSTALL_PREFIX=~/.local ..
/my/path/rz-ghidra/build> make && make install

By default the Cutter plugin is installed in an automatically chosen path in the current user's home directory, and that path can be overridden with -DCUTTER_INSTALL_PLUGDIR.

The versioning section is the part to read before anything else, because it explains a class of failure that looks like a build problem and is not.

Rizin has a quickly evolving C API, so it is necessary to be explicit about which versions of rz-ghidra are compatible with which versions of Rizin. When using both from git, the rz-ghidra branch dev follows along the Rizin branch dev, and the branch stable follows along the Rizin branch stable.

For releases, rz-ghidra is generally released simultaneously with Rizin and often uses the same version numbers, but the README says not to depend on those numbers. Instead, along with every Rizin release a tag like rz-0.1.2 is created on rz-ghidra, which points to an rz-ghidra release and indicates that it is compatible with the specified Rizin version. Those tags exist so distribution maintainers can look up how to set up dependencies.

So the rule is to pick the release by the Rizin version you have, not by the version number on the plugin.

LGPLv3, and why the licence note is in the README

The licence section is short but it makes a point the README flags explicitly: this plugin is available under the LGPLv3, which is more strict than Ghidra's license.

That is a genuinely interesting legal detail for a port. Ghidra's own licence is the Apache License 2.0, which is permissive, so a port of the decompiler could in principle have been distributed under the original terms. The author chose LGPLv3 for the plugin instead, and the README points out that this is a stricter licence than the one the code came from. Whether that choice is required by the Ghidra terms or is a deliberate choice by the author, the effect for a user is the same: this plugin is LGPLv3, and the COPYING file and the LICENSES/ directory at the top level are the ones to read.

The rest of the notice is the standard LGPLv3 text, with the redistribution and modification rights, the warranty disclaimer, and the pointer to the GNU Lesser General Public License for details.

Two other entries in the top level directory list are worth noticing. There is a .reuse/ directory, which is the directory for REUSE, the software licensing metadata specification, and a .builds/ directory, which suggests the project uses a build service alongside its GitHub Actions configuration. Both are small signals, and both point at a project that takes the boring parts of distribution seriously, which is what you want from something that has to be packaged into other people's distributions and shipped alongside Rizin itself.

Editorial conclusion

Adopt rz-ghidra if you want Ghidra decompilation quality without leaving Rizin, because the pdg command family gives you decompiled output, XML and JSON dumps inside the same session you do the rest of your analysis in. Do not adopt it expecting the whole Ghidra suite, because only the decompiler and the Sleigh disassembler are ported and the rest of Ghidra is not there. Before you build, read the versioning section and pick a release tag that matches your Rizin version, since the C API moves quickly and a mismatched plugin will not load, and note that the plugin is LGPLv3, which the README flags as more strict than Ghidra's own licence.

Frequently asked questions

Official sources

1. Issues
2. License: LGPL-3.0
3. README
4. Releases
5. rizinorg/rz-ghidra on GitHub