decomp2dbg: your decompiler symbols, usable as gdb symbols

The gap between the decompiler and the debugger

The problem statement in the README is about workflow rather than tooling. Reverse engineering involves both static analysis in a decompiler and dynamic analysis in a debugger, yet we often use these analyses without sharing knowledge between the two. In the case of reversing static binaries, context switching between the assembly in the debugger and the symbols you have already recovered in the decompilation can be inefficient. decomp2dbg aims to shorten that gap by introducing a generic API for decompiler to debugger symbol syncing. The effect it describes is giving the reverser the power of their debugger, with the symbols and decompilation lines they recovered in their decompiler. There is a recorded talk at CactusCon 2023 that shows it in practice, featuring debugging a remote arm32 binary from an x64 machine with Ghidra symbols, and the BinSync Discord is where the maintainers answer questions about it.

Four decompilers and one debugger family

The supported platform list is short and specific, which is the kind of detail that saves an afternoon. On the decompiler side the project supports IDA Pro from version 9.0, Binary Ninja from 2.4, Ghidra from version 12, and angr-management from 9.0, and recorded walkthroughs with GEF exist for the first three of them. On the debugger side the support is narrower, since the list is gdb and then the three ways people run it, with GEF, with pwndbg, and vanilla. That combination matters more than it looks, because the plugin installs itself as a gdb script and is sourced from the .gdbinit, so a debugger that does not read gdb scripts is out of scope. The README also links to the BinSync project infrastructure and the decompilers documentation, which is where the per decompiler setup instructions live.

One pip install and a prompt for paths

Installation goes through pip and then a built-in installer:

pip3 install decomp2dbg && decomp2dbg --install 

That opens a prompt where you enter the path to your decompiler and your debugger. There are three conditions in the README that are easy to miss. Ghidra has to be launched in PyGhidra mode, and the plugin enabled, which is the d2d_client.py file. If you installed the decompiler side through the Binja Plugin Manager you still need to install the debugger side. And decomp2dbg must be installed into the same Python environment as both your decompiler and your debugger, which is the kind of constraint that turns into an hour of confusion if your tooling lives in different virtual environments. You also may need to allow inbound connections on port 3662, or whatever port you use, and if you run it with GEF or pwndbg the d2d.py file has to be sourced after them in your ~/.gdbinit so it does not fight with their own initialisation.

The manual path when the installer cannot help

The README says to skip the manual route if the built-in script worked, and names the case where it typically cannot, a non WSL Windows install for the decompiler. The manual steps are a clone, an install and two copies. First the repository:

git clone https://github.com/mahaloz/decomp2dbg.git

Then the package into the environment:

pip install .

Then the decompiler side, where you copy the server file into the decompiler's plugin folder, and the path shown is IDA's plugins directory:

cp ./decomp2dbg/d2d_server.py /path/to/ida/plugins/

Finally the debugger side, which places the client script in your home directory and adds a source line to your .gdbinit so it loads on every gdb start:

cp ./decomp2dbg/d2d_client.py ~/.d2d.py && echo "source ~/.d2d.py" >> ~/.gdbinit

The two sided structure is the reason the install has a decompiler half and a debugger half, and it is also why the decompiler and the debugger have to agree on a Python environment.

Starting the server and connecting from gdb

The workflow is server first, client second. You start the decompilation server inside your decompiler, and the README suggests waiting for the decompiler to finish its normal analysis before doing so, using the hotkey Ctrl-Shift-D or the decomp2dbg: configure tab in the associated plugins tab. The decompiler then reports that the server is up, and the two lines in the README are the sign that it worked:

[+] Starting XMLRPC server: localhost:3662
[+] Registered decompilation server!

In the debugger you then run the connect command, optionally naming a host and a port when the decompiler is on a virtual machine or another machine:

decompiler connect ida --host 10.211.55.2 --port 3662

The first connection can take up to 30 seconds to register, depending on the amount of globals in the binary, and the confirmation line is the one you want to see. Every subcommand takes a --help flag, so the full command set is discoverable from the debugger itself.

What the debugger can do once it is connected

Three things change for the reverser, and the README shows each with a gdb command. First, on each breakpoint event you see the decompilation printed, with the line you are on associated with the break address. Second, functions and global variables from the decompilation are mapped into gdb as normal source level symbols, which means ordinary commands work natively, such as breaking on a recovered function name or printing a recovered global. Third, variables that live on the stack, in registers, or as function arguments are imported as convenience variables, so you can print them with the usual syntax and dereference a stack variable with the x command to see the value behind the address it stores. There is an honest caveat about the convenience variables, since a stack variable is only mapped for as long as you are in the same function, and once you leave it may be unmapped or remapped to another value, and the same caveat applies to function arguments, where the README notes the mileage may vary.

Shared libraries, one connection at a time, and the roadmap

The advanced section covers the case that breaks the tool, when you want the decompilation and symbols for a section of memory that is not the main binary, such as a shared library. The current state is blunt, since d2d supports only one decompiler connected at a time, so any other decompiler you have connected has to be disconnected first. You then set the base and end address of the library manually:

decompiler connect ida --base-addr-start 0x00007ffff7452000 --base-addr-end 0x00007ffff766d000

The README suggests finding that base address with something like the vmmap command from GEF, and notes that decompilation is only printed when you are inside that address range. The feature list at the end of the README is the honest summary of where the project is. Checked are the auto-updating decompilation context view, auto-syncing of function names, breakable and inspectable symbols, and auto-syncing of stack variable names. Unchecked are auto-syncing structs, online DWARF creation, function type syncing, lldb support and windbg support. On the packaging side, the project is a setuptools package requiring Python 3.10 or later, depending on sortedcontainers, pyelftools and declib with the Ghidra extra, and it registers a console script called decomp2dbg. The licence is BSD-2-Clause, the releases are v4.0.1 in February 2026, v4.0.2 in April and v4.0.3 in July, and the last push was on 2026-07-14 with the repository not archived.

Editorial conclusion

decomp2dbg fits a reverser who already has a decompiler open next to a debugger and finds the context switching between them to be the slow part, since it turns recovered function names, globals and stack variables into things gdb understands natively. It is the wrong choice if you work purely in lldb or windbg, since the README leaves those unchecked, and it is a poor fit if you need to debug a shared library while a second decompiler is connected, because only one decompiler can be connected at a time. Before you adopt it, install the package into the same Python environment as your decompiler and your debugger, confirm that port 3662 is reachable from the debugger side, and check the readme for the shared library section if your target is not the main binary.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-2-Clause
3. mahaloz/decomp2dbg on GitHub
4. README
5. Releases