Skip to content
Components of a decompilation pipeline.
Branch: master
Clone or download
Latest commit d1d8141 Jan 20, 2019

The project

Join the chat at Build Status Coverage Status GoDoc

The aim of this project is to implement a decompilation pipeline composed of independent components interacting through well-defined interfaces, as further described in the design documents of the project.


go get

Decompilation pipeline

From a high-level perspective, the components of the decompilation pipeline are conceptually grouped into three modules. Firstly, the front-end translates a source language (e.g. x86 assembly) into LLVM IR; a platform-independent low-level intermediate representation. Secondly, the middle-end structures the LLVM IR by identifying high-level control flow primitives (e.g. pre-test loops, 2-way conditionals). Lastly, the back-end translates the structured LLVM IR into a high-level target programming language (e.g. Go).

The following poster summarizes the current capabilities of the decompilation pipeline, using a composition of independent components to translate LLVM IR to Go.

Poster: Compositional Decompilation


Translate machine code (e.g. x86 assembly) to LLVM IR.

Third-party front-end components.


Perform control flow analysis on the LLVM IR to identify high-level control flow primitives (e.g. pre-test loops).


Control flow graph generation tool.

Generate control flow graphs from LLVM IR assembly (*.ll -> *.dot).


Control flow recovery tool.

Recover control flow primitives from control flow graphs (*.dot -> *.json).


Translate structured LLVM IR to a high-level target language (e.g. Go).


Go code generation tool.

Decompile LLVM IR assembly to Go source code (*.ll -> *.go).


Go post-processing tool.

Post-process Go source code to make it more idiomatic (*.go -> *.go).

Release history

Version 0.2 (2018-01-30)

Primary focus of version 0.2: project-wide compilation speed.

Developing decompilation components should be fun.

There seem to be an inverse correlation between depending on a huge C++ library and having fun developing decompilation components.

Version 0.2 of the decompilation pipeline strives to resolve this issue by leveraging an LLVM IR library written in pure Go. Prior to this release, project-wide compilation could take several hours to complete. Now, they complete in less than 1 minute -- the established hard limit for all future releases.

Version 0.1 (2015-04-21)

Initial release.

Primary focus of version 0.1: compositional decompilation.

Decompilers should be composable and open source.

A decompilation pipeline should be composed of individual components, each with a single purpose and well-defined input and output.

Version 0.1 of the decomp project explores the feasibility of composing a decompilation pipeline from independent components, and the potential of exposing those components to the end-user.

For further background, refer to the design documents at


Version 0.3 (to be released)

Primary focus of version 0.3: control flow analysis.

Decompilers should recover high-level control flow primitives.

One of the primary differences between low-level assembly and high-level source code is the use of control flow primitives.

Version 0.3 seeks to recover high-level control flow primitives using robust control flow analysis algorithms.

Version 0.4 (to be released)

Primary focus of version 0.4: fault tolerance.

Decompilers should be robust.

Decompilation components should respond well to unexpected states and incomplete analysis.

Version 0.4 focuses on stability, and seeks to stress test the decompilation pipeline using semi-real world software (see the challenge issue series).

Version 0.5 (to be released)

Primary focus of version 0.5: data flow analysis.

Version 0.6 (to be released)

Primary focus of version 0.6: type analysis.

You can’t perform that action at this time.