Decompiler Options

Producing decompilation results for a single function can be computationally intensive. This option specifies the number of functions whose decompilation results can be cached simultaneously. When navigating to a function that has been recently cached, as when navigating back and forth between a few functions, a new decompilation is not triggered.

This option limits the number of bytes that can be produced by the Decompiler process as output when decompiling a single function. A payload includes the actual characters to be displayed in the window, additional token markup, symbol information, and other details of the underlying syntax tree. The limit is specified in megabytes of data. If the limit is exceeded for a single function, decompilation is aborted for that function, and an error message "Decompiler results exceeded payload limit ..." is displayed.

This option sets an upper limit on the number of seconds the Decompiler spends attempting to analyze one function before aborting. It is currently not enforced for a Decompiler window. Instead it applies to the DecompilerSwitchAnalyzer, the analyzeHeadless command, scripts, and other plug-ins that make use of the Decompiler service.

This option sets a maximum number of machine instructions that the Decompiler will attempt to analyze for a single function, as a safeguard against analyzing a long sequence of zeroes or other constant data. The Decompiler will quickly throw an exception if it traces control flow into more than the indicated number of instructions.

This option sets the maximum number of entries (addresses) that the Decompiler can recover from analyzing a single jumptable. This serves as a sanity check that the recovered dimensions of a jumptable are reasonable and places an upper limit on the sheer number of addresses the Decompiler is willing to trace from a single indirect jump.

When deciding if an individual stack location has become dead, the Decompiler must consider aliases, pointers onto the stack that could be used to modify the location within a called function. One strong heuristic the Decompiler uses is: if the user has explicitly created a variable on the stack between the base location referenced by the pointer and the individual stack location, then the Decompiler can assume that the pointer is not an alias of the stack location. The alias is blocked by the explicit variable. However, if the user's explicit variable is labeling something that isn't really an explicit variable, like a field within a larger structure, for instance, the Decompiler may incorrectly consider the stack location as dead and start removing live code.

In order to support the exploratory labeling of stack locations, the user can use this setting to specify what data-types should be considered blocking. The four options are:

Selecting None is the equivalent of turning off the heuristic. Selecting anything except All Data-types allows users to safely label small variables without knowing immediately if the stack location is part of a larger structure or array.

When toggled on, the Decompiler eliminates code that it considers unreachable. This usually happens when, due to constant propagation and other analysis, the Decompiler decides that a boolean value controlling a conditional branch can only take one possible value and removes the branch corresponding to the other value. Toggling this to off lets the user see the dead code, which is typically demarcated by the control-flow structure:

When toggled on, the Decompiler treats instructions whose semantics have been formally marked unimplemented as if they do nothing (no operation). Crucially, control flow falls through to the next instruction. In this case, the Decompiler inserts the warning "Control flow ignored unimplemented instructions" as a comment in the function header, but the exact point at which instruction was ignored may not be clear. If this option is toggled off, the Decompiler inserts the built-in function halt_unimplemented() at the point of the unimplemented instruction, and control flow does not fall through.

When toggled on, the Decompiler infers a data-type for constants it determines are likely pointers. In the basic heuristic, each constant is considered as an address, and if that address starts a known data or function element in the program, the constant is assumed to be a pointer. The constants are treated like any other source of data-type information, and the inferred data-types are freely propagated by the Decompiler to other parts of the function.

This option determines how the Decompiler treats floating-point NaN (Not a Number) operations. Many processors automatically perform NaN checks on the operands of floating-point instructions, and unless specifically configured, these show up in Decompiler output as NAN() functional tokens. Common floating-point source code operations, like <, >, and == can generate NAN tokens as a side effect, even if the original source code was not designed to handle NaN values, and the tokens can clutter the output.

The user can optionally configure some or all of the NaN operations to be ignored, meaning that inputs to the NaN operation are assumed to be valid floating-point values and the NAN function is removed, replacing it with the value: false. The possible settings are:

The Decompiler considers a NaN operation to be associated with a floating-point comparison if they both can be considered boolean clauses of the same if condition.

When toggled on, the Decompiler attempts to pinpoint variables that control the iteration over specific loops in the function body. When these loop variables are discovered, the loop is rendered using a standard for loop header that contains an initializer statement, condition, and iterating statement.

When toggled off, the loop is displayed using while syntax, with any initializer and iterating statements mixed in with the loop body or preceding basic blocks.

When toggled on, the Decompiler treats any values in memory marked read-only as constant. If a read-only memory location is explicitly referenced by the function being decompiled, it is considered to be unchanging, and the initial value present in the Program is pulled into the data flow of the function as a constant. Due to Constant Propagation and other transformations, read-only memory can have a large effect on Decompiler output.

Typically, as part of the import process, Ghidra marks memory blocks as read-only if they are tagged as such by a section header or other meta-data in the original binary. Users can actively set whether specific memory regions are considered read-only through the Memory Manager, and individual data elements can be marked as constant via the Mutability setting (see Data Mutability).

This toggles whether the Decompiler attempts to simplify double precision arithmetic operations, where a single logical operation is split into two parts, calculating the high and low pieces of the result in separate instructions. Decompiler support for this kind of transform is currently limited, and only certain constructions are simplified.

When this option is active, the Decompiler simplifies code sequences containing predicated instructions. A predicated instruction is executed conditionally based on a boolean value, the predicate, and a sequence of instructions can share the same predicate. The Decompiler merges the resulting if/else blocks that share the same predicate so that the condition is only printed once.

When this option is active, the Decompiler attempts to identify places in the code where multiple fields of a structure data-type are being moved simultaneously with a single operation. Then it splits the operation into multiple pieces so that the logical fields can be seen individually. When this option isn't active, the Decompiler creates an artificial token to represent the combined fields being written to or read from.

	      struct1._20_4_ = 0xff00ff00;  // Auto-generated name for assigning multiple fields at once
	        ...
	      struct1.a = 0xff00;           // The same assignment, after splitting
	      struct1.b = 0xff00;
	    

When this option is active, the Decompiler attempts to identify places in the code where multiple elements of an array are being moved simultaneously with a single operation. Then it splits the operation into multiple pieces so each element of the array can be seen individually. When this option isn't active, the Decompiler creates an artificial token to represent the combined elements being written to or read from.

	      text._20_2_ = 0x4241;        // Auto-generated name for assigning multiple elements at once
	        ...
	      text[20] = 'A';              // The same assignment, after splitting
	      test[21] = 'B';
	    

This options affects when the Decompiler's splitting actions are applied. See the discussion above about Splitting Structure Accesses and Splitting Array Accesses. If this option is on, a split is performed whenever combined elements or combined fields are copied. In particular, either the read access, or the write access, or both, can be through a pointer. If this option is off, splitting is limited to copies between structures or arrays at fixed locations, either at a global address, or on the local stack.

When toggled on, the Decompiler employs in-place assignment operators, such as += and <<=, in its output syntax.

Assign the background color for the Decompiler window.

Choose how braces are placed after function declarations, or other kinds of code blocks in Decompiler output. Formatting can be controlled for:

The different formatting options primarily control how the opening brace is displayed relative to the line containing the declaration or keyword starting the block. The formatting options are:

The "Same line" option is consistent with K & R code formatting style. The "Next line" option is consistent with the Allman formatting style.

Assign the color to any characters emitted by the Decompiler that do not fall into one of token types listed below. This includes delimiter characters like commas and parentheses as well as various operator characters.

Assign colors to the different types of language tokens emitted by the Decompiler. These include:

Assign the background color used to highlight the token currently under the cursor in a Decompiler window.

Assign the background color used to highlight characters matching the current Find pattern (see Find...).

Set the number of characters that comment lines are indented within Decompiler output. This applies only to comments within the body of the function being displayed. Comments at the head of the function are not indented.

Set the language syntax used to delimit comments emitted as part of Decompiler output. For C and Java, the choices are /* C style comments */ and // C++ style comments.

Set whether the syntax for type casts is emitted in Decompiler output. If this is toggled on, type cast syntax is never displayed, even when rules of the language require it. So individual statements may no longer be formally accurate.

Set whether a specific type of comment should be incorporated into Decompiler output. Each type has its own toggle and can be individually included or excluded from Decompiler output.

A comment's type indicates how it is placed within a Listing window, not how it is placed in a Decompiler window. All comments within the body of the function are displayed in the same way by the decompiler, regardless of their type (see the discussion in Comments).

Toggle whether the Decompiler emits comments at the head (before the beginning) of a function. The header is built from Plate comments placed at the entry point of the function (see the discussion in Comments). The inclusion of other Plate comments is controlled by the Display PLATE comments toggle, described above.

Toggle whether line numbers are displayed in any Decompiler window. If toggled on, each Decompiler window reserves space to display a numbers down the left side of the window, labeling each line of output produced by the Decompiler. Line numbers are associated with the window itself and are not formally part of the Decompiler's output.

Control how the Decompiler displays namespace information associated with function and variable symbols. The possible settings are:

The Minimally setting, which is the default, will only emit the portion of the namespace path necessary to distinguish the symbol from other symbols with the same base name used by the function, or if a portion of the path is completely outside the function's scope.

The Never setting never displays any of the namespace path under any circumstances and may produce output that is ambiguous and doesn't formally parse.

Toggle whether Decompiler generated WARNING comments are displayed as part of the output. The Decompiler generates these comments, independent of those laid down by users, to indicate unusual conditions or possible errors (see Warning Comments).

Set the typeface used to render characters in any Decompiler window. Indentation is generally clearer using a monospaced (fixed-width) font, but any font available to Ghidra can be used. The size of the font can also be controlled from this option.

Set how integer constants are formatted in the Decompiler output. The possible settings are:

For Best Fit, a representation is selected based on how close it is to either a round decimal value (10, 100, 1000, etc.) or a round hexadecimal value (0x10, 0x100, 0x1000, etc.)

Set the maximum number of characters in a line of code emitted by the Decompiler before a line break is forced. The Decompiler will not split an individual token across lines. So line breaks frequently will come before the maximum number of characters is reached, and technically a single token can extend the line beyond the maximum.

Set the amount of indenting used to print statements within a nested scope in the Decompiler output. Each level of nesting (function bodies, loop bodies, if/else bodies, etc.) adds this number characters.

Set how null pointers are displayed in Decompiler output. If this is toggled on, the Decompiler will print a constant pointer value of zero (a null pointer) using the special token NULL. Otherwise the pointer value is represented with the '0' character, which is then cast to a pointer.

Set whether the calling convention is printed as part of the function declaration in Decompiler output. If this option is turned on, the name of the calling convention is printed just prior to the return value data-type within the function declaration. All functions in Ghidra have an associated calling convention (or prototype model) that is used during Decompiler analysis (see the discussion in Prototype Model).

Sets the calling convention (prototype model) used when decompiling a function where the convention is not known; i.e., marked as unknown. Many architectures have multiple calling conventions, __stdcall, __thiscall, etc. (see the discussion in Prototype Model).