Working with the Decompiler

In the upstream baseline, select a function and open Window → Decompile. The main Decompiler follows the current program location and displays one function. Snapshot windows can keep another function visible.

Decompilation incorporates labels, data types, comments, and annotations. Renaming or retyping can cause a function to be decompiled again. This is why improving the program model is often more useful than editing exported text.

A review loop

1. Read the function’s signature, callers, and return-value use.
2. Compare a significant operation with the Listing.
3. Rename a variable or function when its role is supported by evidence.
4. Apply a more precise type only after checking size, layout, and use.
5. Re-read the output and inspect any warnings.

Decompiler warning comments deserve attention. A function can produce output while still reporting incomplete or unreliable interpretation. Large functions can also take longer to process; record timeouts instead of treating missing output as an empty function.

Preserve uncertainty

A helpful name is an annotation, not a recovered original identifier. Likewise, C-like output is a representation of compiled behavior, not the original source file. Preserve addresses and notes that connect your interpretation to the instructions.

The planned Pro cleanup workflow will be a separate extension. It is not required for this baseline workflow and has no verified installation command yet.

TODO: update screenshot with a real Opcodex Decompiler window. VERIFY its menu labels at release.

---

Source: Decompiler Window help.

Adapted from the Ghidra documentation (Apache 2.0).