Changes in response to review

This commit is contained in:
caheckman 2020-09-22 16:00:21 -04:00
parent a7d5e983b7
commit fe2d508c1c
14 changed files with 1089 additions and 379 deletions

View file

@ -47,6 +47,7 @@ src/main/help/help/topics/DecompilePlugin/images/DecompWindow.png||GHIDRA||||END
src/main/help/help/topics/DecompilePlugin/images/Defuse.png||GHIDRA||||END|
src/main/help/help/topics/DecompilePlugin/images/EditFunctionSignature.png||GHIDRA||||END|
src/main/help/help/topics/DecompilePlugin/images/ForwardSlice.png||GHIDRA||||END|
src/main/help/help/topics/DecompilePlugin/images/Undefined.png||GHIDRA||||END|
src/main/help/help/topics/DecompilePlugin/images/camera-photo.png||Tango Icons - Public Domain|||Tango|END|
src/main/help/help/topics/DecompilePlugin/images/decompileFunction.gif||GHIDRA||reviewed||END|
src/main/help/help/topics/DecompilePlugin/images/page_edit.png||FAMFAMFAM Icons - CC 2.5||||END|

File diff suppressed because it is too large Load diff

View file

@ -18,8 +18,10 @@
FrontPage.css.
*/
h5 { margin-left: 10px; }
div.informalexample { margin-left: 50px; }
h5 { margin-left: 10px; margin-top: 20px; font-family:times new roman; font-size:12pt; font-style:italic; }
div.informalexample { margin-left: 50px; margin-top: 10px; }
dd { margin-bottom: 20px; }
dd p { margin-top: 5px; margin-left: 10px; }
span.term { font-family:times new roman; font-size:14pt; font-weight:bold; }
span.code { font-weight: bold; font-family: courier new; font-size: 14pt; color:#000000; }

View file

@ -26,8 +26,12 @@
processor specific form into Ghidra's IR language (see <a class="xref" href="DecompilerConcepts.html#ConceptPcode" title="P-code">&#8220;P-code&#8221;</a>),
which provides both the control-flow behavior of the instruction and the detailed
semantics describing how the processor and memory state is affected. The translation is controlled by
the underlying processor model and cannot be directly altered from the tool. Users
<span class="emphasis"><em>can</em></span> modify the model specification itself, however.
the underlying processor model and, except in limited circumstances, cannot be directly altered
from the tool. Flow Overrides (see below) can change how certain control-flow is translated,
and, depending on the processor, context registers may affect p-code (see <a class="xref" href="DecompilerAnnotations.html#AnnoteContextRegister" title="Context Registers">&#8220;Context Registers&#8221;</a>).
</p>
<p>
Outside of the tool, users <span class="emphasis"><em>can</em></span> modify the model specification itself.
See the document "SLEIGH: A Language for Rapid Processor Specification".
</p>
<p>
@ -37,7 +41,7 @@
<span class="emphasis"><em>fall through</em></span>, <span class="emphasis"><em>conditional jump</em></span>, and other
semantics until an instruction with <span class="emphasis"><em>terminator</em></span> semantics is
reached, which is usually a "return from subroutine"
instruction. Flow is not traced into subfunctions, in this situation. Instructions
instruction. Flow is not traced into called functions, in this situation. Instructions
with <span class="emphasis"><em>call</em></span> semantics are treated only as if they fall through.
</p>
<p>
@ -103,11 +107,17 @@
<a name="AnnoteFlowOverride"></a>Flow Overrides</h3></div></div></div>
<p>
Control-flow behavior for machine instructions is generally determined by the underlying
Processor model. But this flow can be overridden for individual instructions by various
Analyzers or manually by the user. The decompiler incorporates these overrides into its
analysis, and they can have a significant impact on results. Current
<span class="emphasis"><em>flow overrides</em></span> include:
Control-flow behavior for a machine instruction is generally determined by its underlying
p-code (see <a class="xref" href="DecompilerConcepts.html#ConceptControlFlow" title="P-code Control Flow">&#8220;P-code Control Flow&#8221;</a>), but this can be changed by applying a Flow Override.
A <span class="bold"><strong>Flow Override</strong></span> maintains the overall semantics of a branching instruction
but changes how the branch is interpreted. For instance, a <code class="code">JMP</code> instruction, which traditionally
represents a branch within a single function, can be overridden to represent a call to a new function.
Flow Overrides are applied by Analyzers or manually by the user.
</p>
<p>
The decompiler automatically incorporates any relevant Flow Overrides into its
analysis of a function. This can have a significant impact on results. The
types of possible Flow Overrides include:
</p>
<div class="informalexample">
<div class="variablelist"><dl class="variablelist">
@ -413,8 +423,11 @@
<dt><span class="term">Duplicate Symbols</span></dt>
<dd>
<p>
Ghidra allows duplicate symbols, including duplicate function names, in
any scope higher than a function.
Ghidra allows different functions to have the same name, even within the same
namespace, in order to model languages that support <span class="emphasis"><em>function overloading</em></span>.
In most languages, such functions would be expected to have distinct prototypes to allow
the symbols to be distinguished in context. Ghidra and the decompiler however do not check
for this, as prototypes may not be known.
</p>
</dd>
</dl></div>
@ -763,21 +776,20 @@
</p>
<p>
For annotations that specifically label a function's formal parameters or return value,
the <span class="emphasis"><em>Signature Source-Type</em></span> also affects how they're treated by the decompiler.
If the Source-Type is set to anything other than <span class="emphasis"><em>DEFAULT</em></span>, there is a forced
the <a class="link" href="DecompilerAnnotations.html#PrototypeSignatureSource" title="Signature Source">Signature Source</a> also affects how they're treated by the decompiler.
If the Signature Source is set to anything other than <span class="emphasis"><em>DEFAULT</em></span>, there is a forced
one-to-one correspondence between variable annotations and actual parameters in the decompiler's
view of the function. This is stronger than just forcing the data-type; the existence (or not) of
the variable itself is forced by the annotation in this case. If the Source-Type is forcing and
the variable itself is forced by the annotation in this case. If the Signature Source is forcing and
there are no parameter annotations, a <span class="emphasis"><em>void</em></span> prototype is forced on the function.
</p>
<p>
A forcing Source-Type, with a value other than
<span class="emphasis"><em>DEFAULT</em></span>, is set typically if debug symbols for the function are read in during
A forcing Signature Source is set typically if debug symbols for the function are read in during
Program import (<span class="emphasis"><em>IMPORTED</em></span>), or if the user manually edits the function prototype
directly (<span class="emphasis"><em>USER_DEFINED</em></span>).
</p>
<p>
If an annotation and the Signature Source-Type force a parameter to exist, specifying an
If an annotation and the Signature Source force a parameter to exist, specifying an
<span class="emphasis"><em>undefined</em></span> data-type in the annotation still directs the decompiler to fill in
the variable's data-type using type propagation. The same holds true for the return value; an
<span class="emphasis"><em>undefined</em></span> annotation fixes the size of the return value, but the decompiler
@ -867,10 +879,13 @@
Currently, the entire body of the function is included
in the scope of any stack annotation, and the decompiler will allow only a single variable to exist
at the stack address. A stack annotation can be a formal parameter to the function, but otherwise the
decompiler does not expect to see a value that exists before the start of the function. Similarly,
because the value is not expected to persist after the function executes, a write to the stack
address may not show up as an explicit assignment to the variable if the value is simply
<span class="emphasis"><em>propagated through</em></span> to another expression.
decompiler does not expect to see a value that exists before the start of the function.
</p>
<p>
The decompiler will continue to perform <span class="emphasis"><em>copy propagation</em></span> and other transforms on
stack locations associated with a variable annotation. In particular, within decompiler output,
a specific write operation to a stack address may not show up as an explicit assignment to its variable,
if the value is simply copied to another location.
</p>
</div>
<div class="sect3">
@ -1004,7 +1019,7 @@
<p>
If the boolean property <span class="bold"><strong>in-line</strong></span> is turned on for a particular function,
it directs the decompiler to inline the effects of the function into the decompilation of any of its calling functions.
The function will no longer appear as a direct subfunction call in the decompilation, but all of its data-flow
The function will no longer appear as a direct function call in the decompilation, but all of its data-flow
will be incorporated into the calling function.
</p>
<p>
@ -1018,8 +1033,8 @@
<p>
This property is similar in spirit to marking a function as <span class="emphasis"><em>in-line</em></span>.
A <span class="bold"><strong>call-fixup</strong></span> directs the decompiler to replace any call to the function with a specific
chunk of raw p-code. The decompilation of any calling function no longer shows the subfunction call, but the chunk
of p-code incorporates the subfunction's effects.
chunk of raw p-code. The decompilation of any calling function no longer shows the function call, but the chunk
of p-code incorporates the called function's effects.
</p>
<p>
Call-fixups are more flexible than just inlining a function. The call-fixup chunk can be tailored to incorporate all of,
@ -1036,6 +1051,49 @@
</p>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
<a name="PrototypeSignatureSource"></a>Signature Source</h3></div></div></div>
<p>
Ghidra records a <span class="bold"><strong>Signature Source</strong></span> for every function,
indicating the origin of its prototype information. This is
similar to the <span class="emphasis"><em>Symbol Source</em></span> attached to Ghidra's symbol annotations
(See the documentation for
<a class="ulink" href="help/topics/SymbolTablePlugin/symbol_table.htm#Set_Filter" target="_top">Filtering</a>
in the Symbol Table). The possible types are:
</p>
<div class="informalexample">
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: none; ">
<li class="listitem" style="list-style-type: none">
<span class="emphasis"><em>DEFAULT</em></span> - for basic or no information</li>
<li class="listitem" style="list-style-type: none">
<span class="emphasis"><em>ANALYSIS</em></span> - for information derived by an Analyzer</li>
<li class="listitem" style="list-style-type: none">
<span class="emphasis"><em>IMPORTED</em></span> - for information imported from an external source</li>
<li class="listitem" style="list-style-type: none">
<span class="emphasis"><em>USER_DEFINED</em></span> - for information set by the user</li>
</ul></div>
</div>
<p>
</p>
<p>
Upon import of the Program, if there are debugging symbols available, Ghidra will build
annotations of the function's parameters and set the Symbol Source type to <span class="emphasis"><em>IMPORTED</em></span>.
Otherwise, it will generally be set to <span class="emphasis"><em>DEFAULT</em></span>.
</p>
<p>
However, Ghidra adjusts the Signature Source for a function if there is any change to the
prototype. In particular, if the user adds, removes, or edits variable annotations
for the function's parameters or return value, Ghidra automatically converts the Signature
Source to be <span class="emphasis"><em>USER_DEFINED</em></span>.
</p>
<p>
If the Signature Source is set to anything other than <span class="emphasis"><em>DEFAULT</em></span>, the
function's prototype information is forcing on the decompiler. See the discussion
in <a class="xref" href="DecompilerAnnotations.html#AnnoteForcing" title="Forcing Data-types">&#8220;Forcing Data-types&#8221;</a>
</p>
</div>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
<a name="PrototypeDiscover"></a>Discovering Parameters</h3></div></div></div>
<p>
@ -1051,7 +1109,7 @@
</tr>
<tr><td align="left" valign="top">
The input parameters and return value are all forced on the decompiler as a unit based on the
<span class="emphasis"><em>Signature Source-Type</em></span>. They are all forced if the Source-Type is set to anything
<span class="emphasis"><em>Signature Source</em></span>. They are all forced if the type is set to anything
other than <span class="emphasis"><em>DEFAULT</em></span>; otherwise none of them are forced.
</td></tr>
</table></div>
@ -1165,7 +1223,7 @@
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: bullet; ">
<li class="listitem" style="list-style-type: disc">Signed or zero extension</li>
<li class="listitem" style="list-style-type: disc">Bitwise negation</li>
<li class="listitem" style="list-style-type: disc">Integer negation - Twos complement</li>
<li class="listitem" style="list-style-type: disc">Integer negation - Two's complement</li>
<li class="listitem" style="list-style-type: disc">Add or subtract 1</li>
</ul></div>
</div>
@ -1252,6 +1310,61 @@
If a register value's region starts in the middle of a function, decompilation is <span class="emphasis"><em>not</em></span>
affected at all.
</p>
<div class="sect2">
<div class="titlepage"><div><div><h3 class="title">
<a name="AnnoteContextRegister"></a>Context Registers</h3></div></div></div>
<p>
There is a special class of registers, called <span class="bold"><strong>context registers</strong></span> whose
values have a different affect on analysis and decompilation than described above.
</p>
<div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Tip">
<tr>
<td rowspan="2" align="center" valign="top" width="25"><img alt="[Tip]" src="../../shared/tip.png"></td>
<th align="left"></th>
</tr>
<tr><td align="left" valign="top">
<span class="emphasis"><em>Context registers</em></span> are inputs to the disassembly decoding process and directly affect which
machine instructions are created.
</td></tr>
</table></div>
<p>
The value in a context register is examined when Ghidra decodes machine instructions from the underlying
bytes in the Program. A specific value generally corresponds to a specific <span class="emphasis"><em>execution mode</em></span>
of the processor. The ARM processor <span class="emphasis"><em>T bit</em></span> for instance, which selects whether the
processor is executing ARM or THUMB instructions, is modeled as a context register in Ghidra.
The same set of bytes in the Program can be decoded to machine instructions in more than one way,
depending on context register values.
</p>
<p>
Bytes are typically decoded once using context register values
established at the time of disassembly. From Ghidra's more static view of execution, a context register holds
only a single value at any point in the code, but the same context register can hold different values for
different regions of code. Setting a new value on a region of the Program will affect any subsequent disassembly
of code within that region.
</p>
<p>
If a context register value is changed for a region that has already been disassembled, in order to see
the affect of the change, the machine instructions in the region need to be cleared, and disassembly needs
to be triggered again. See the documentation on the
<a class="ulink" href="help/topics/ClearPlugin/Clear.htm#Clear_Code_Bytes" target="_top">Clear Plugin</a>.
</p>
<p>
Values for a context register are set in the same way as any other register, using the
<a class="ulink" href="help/topics/RegisterPlugin/Registers.htm#SetRegisterValues" target="_top">Set Register Values ...</a> command
described above. Within the
<a class="ulink" href="help/topics/RegisterPlugin/Registers.htm#Register_Manager" target="_top">Register Manager</a> window,
context registers are generally grouped together under the (pseudo-register) heading, <span class="emphasis"><em>contextreg</em></span>.
For details about how context registers are used in processor modeling, see
the document "SLEIGH: A Language for Rapid Processor Specification".
</p>
<p>
Because context registers affect machine instructions, they also affect the underlying p-code and
have a substantial impact on decompilation. Although details vary by processor, context register
values are typically established during the initial import and analysis of a Program and aren't changed
frequently.
</p>
</div>
</div>
</div></body>

View file

@ -45,7 +45,7 @@
<span class="bold"><strong>size</strong></span> - the maximum number of bytes that can be addressed
</li>
<li class="listitem" style="list-style-type: disc">
<span class="bold"><strong>endianess</strong></span> - how groups of bytes are interpreted as integers
<span class="bold"><strong>endianness</strong></span> - how groups of bytes are interpreted as integers
</li>
</ul></div>
</div>
@ -62,7 +62,7 @@
<dt><span class="term"><span class="bold"><strong>ram</strong></span></span></dt>
<dd>
<p>
A space that models memory accessible via the processors's main data bus. Depending on
A space that models memory accessible via the processor's main data bus. Depending on
the architecture, different spaces might be substituted for <span class="emphasis"><em>ram</em></span>,
such as separate <span class="emphasis"><em>code</em></span> and <span class="emphasis"><em>data</em></span> spaces.
</p>
@ -153,7 +153,7 @@
</ul></div>
</div>
<p>
The integer data-type assumes a twos complement encoding in the endianness of the
The integer data-type assumes a two's complement encoding in the endianness of the
address space containing the varnode. Similarly, the floating point data-type assumes
an IEEE 754 standard encoding. The precision of the integer or floating point value is
determined by the varnode's size. A boolean data-type assumes the varnode has a size
@ -332,12 +332,12 @@
<tr>
<td>CALL</td>
<td><code class="code">funcname(...)</code></td>
<td>Branch to a subfunction.</td>
<td>Branch to a function, as a call.</td>
</tr>
<tr>
<td>CALLIND</td>
<td><code class="code">(*funcptr)(...)</code></td>
<td>Branch through a pointer to a subfunction.</td>
<td>Branch through a pointer to a function, as a call.</td>
</tr>
<tr>
<td>RETURN</td>
@ -435,7 +435,7 @@
<tr>
<td>INT_2COMP</td>
<td><code class="code">-</code></td>
<td>Twos complement.</td>
<td>Two's complement.</td>
</tr>
<tr>
<td>INT_NEGATE</td>
@ -666,6 +666,65 @@
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
<a name="ConceptControlFlow"></a>P-code Control Flow</h4></div></div></div>
<p>
P-code has natural <span class="bold"><strong>control-flow</strong></span>, with the subtlety that flow
happens both within and across machine instructions. Most p-code operators have
<span class="bold"><strong>fall-through</strong></span> semantics, meaning that flow moves to the
next operator in the sequence associated with the instruction, or, if the operator is the
last in the sequence, flow moves to the first operator in the p-code associated with the next instruction.
The p-code operators with <span class="bold"><strong>branching</strong></span> semantics, such as
CBRANCH and BRANCH, can jump to a target operator which is internal to the current instruction, or they can
jump to the first p-code operator corresponding to a new instruction at a different address.
</p>
<p>
Ghidra labels a machine instruction with one of the following <span class="bold"><strong>Flow Types</strong></span> that describe
its overall control-flow. The Flow Type is derived directly from the control-flow of the p-code for the instruction,
with the basic types corresponding directly with a specific branching p-code operator.
</p>
<div class="informalexample">
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: none; ">
<li class="listitem" style="list-style-type: none"><span class="bold"><strong>FALL_THROUGH</strong></span></li>
<li class="listitem" style="list-style-type: none">
<span class="bold"><strong>UNCONDITIONAL_CALL</strong></span> - CALL</li>
<li class="listitem" style="list-style-type: none">
<span class="bold"><strong>UNCONDITIONAL_JUMP</strong></span> - BRANCH</li>
<li class="listitem" style="list-style-type: none">
<span class="bold"><strong>CONDITIONAL_JUMP</strong></span> - CBRANCH</li>
<li class="listitem" style="list-style-type: none">
<span class="bold"><strong>COMPUTED_JUMP</strong></span> - BRANCHIND</li>
<li class="listitem" style="list-style-type: none">
<span class="bold"><strong>COMPUTED_CALL</strong></span> - CALLIND</li>
<li class="listitem" style="list-style-type: none">
<span class="bold"><strong>TERMINATOR</strong></span> - RETURN</li>
</ul></div>
</div>
<p>
Other Flow Types occur due to a combination of multiple p-code branching operators within the same instruction.
</p>
<div class="informalexample">
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: none; ">
<li class="listitem" style="list-style-type: none">
<span class="bold"><strong>CONDITIONAL_CALL</strong></span> - CALL with CBRANCH</li>
<li class="listitem" style="list-style-type: none">
<span class="bold"><strong>CONDITIONAL_TERMINATOR</strong></span> - RETURN with CBRANCH</li>
<li class="listitem" style="list-style-type: none">
<span class="bold"><strong>COMPUTED_CALL_TERMINATOR</strong></span> - CALLIND with RETURN</li>
<li class="listitem" style="list-style-type: none">
<span class="bold"><strong>CONDITIONAL_COMPUTED_JUMP</strong></span> - CBRANCH with BRANCHIND</li>
<li class="listitem" style="list-style-type: none">
<span class="bold"><strong>CONDITIONAL_COMPUTED_CALL</strong></span> - CBRANCH with CALLIND</li>
<li class="listitem" style="list-style-type: none">
<span class="bold"><strong>JUMP_TERMINATOR</strong></span> - BRANCH with RETURN</li>
</ul></div>
</div>
<p>
</p>
</div>
<div class="sect3">
<div class="titlepage"><div><div><h4 class="title">
<a name="ConceptInternalFunctions"></a>Internal Decompiler Functions</h4></div></div></div>
<p>
@ -676,9 +735,9 @@
of p-code operations, displaying them as if they were built-in functions for the language.
</p>
<div class="informalexample">
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: none; ">
<li class="listitem" style="list-style-type: none">
<code class="code">SUB41(x,c)</code> - Truncation operation - SUBPIECE
<div class="variablelist"><dl class="variablelist">
<dt><span class="term"><code class="code">SUB41(x,c)</code> - Truncation operation - SUBPIECE</span></dt>
<dd>
<div class="itemizedlist"><ul class="itemizedlist compact" style="list-style-type: bullet; ">
<li class="listitem" style="list-style-type: disc">The digit '4' indicates the size of the input operand 'x' in bytes.</li>
<li class="listitem" style="list-style-type: disc">The digit '1' indicates the size of the output value in bytes.</li>
@ -710,9 +769,9 @@
</ul></div>
<p>
</p>
</li>
<li class="listitem" style="list-style-type: none">
<code class="code">CONCAT31(x,y)</code> - Concatenation operator - PIECE
</dd>
<dt><span class="term"><code class="code">CONCAT31(x,y)</code> - Concatenation operator - PIECE</span></dt>
<dd>
<div class="itemizedlist"><ul class="itemizedlist compact" style="list-style-type: bullet; ">
<li class="listitem" style="list-style-type: disc">The digit '3' indicates the size of the input operand 'x' in bytes.</li>
<li class="listitem" style="list-style-type: disc">The digit '1' indicates the size of the input operand 'y' in bytes.</li>
@ -725,9 +784,9 @@
Concatenate the bytes in 'x' with the bytes in 'y'. 'x' becomes the most significant
bytes, and 'y' the least significant bytes, in the result.
</p>
</li>
<li class="listitem" style="list-style-type: none">
<code class="code">ZEXT14(x)</code> - Zero-extension operator - INT_ZEXT
</dd>
<dt><span class="term"><code class="code">ZEXT14(x)</code> - Zero-extension operator - INT_ZEXT</span></dt>
<dd>
<div class="itemizedlist"><ul class="itemizedlist compact" style="list-style-type: bullet; ">
<li class="listitem" style="list-style-type: disc">The digit '1' indicates the size of the input operand 'x' in bytes.</li>
<li class="listitem" style="list-style-type: disc">The digit '4' indicates the size of the output in bytes.</li>
@ -739,9 +798,9 @@
Extend the operand 'x' to a larger size by appending zero bytes, which become the most
significant bytes of the result.
</p>
</li>
<li class="listitem" style="list-style-type: none">
<code class="code">SEXT14(x)</code> - Sign-extension operator - INT_SEXT
</dd>
<dt><span class="term"><code class="code">SEXT14(x)</code> - Sign-extension operator - INT_SEXT</span></dt>
<dd>
<div class="itemizedlist"><ul class="itemizedlist compact" style="list-style-type: bullet; ">
<li class="listitem" style="list-style-type: disc">The digit '1' indicates the size of the input operand 'x' in bytes.</li>
<li class="listitem" style="list-style-type: disc">The digit '4' indicates the size of the output in bytes.</li>
@ -753,32 +812,32 @@
Extend the operand 'x' to a larger size by duplicating the <span class="emphasis"><em>sign</em></span>
bit of 'x' into the most significant bytes of the result.
</p>
</li>
<li class="listitem" style="list-style-type: none">
<code class="code">SBORROW4(x,y)</code> - Test for signed borrow operator - INT_SBORROW
</dd>
<dt><span class="term"><code class="code">SBORROW4(x,y)</code> - Test for signed borrow operator - INT_SBORROW</span></dt>
<dd>
<div class="itemizedlist"><ul class="itemizedlist compact" style="list-style-type: bullet; "><li class="listitem" style="list-style-type: disc">The digit '4' indicates the size of both input operands 'x' and 'y' in bytes.</li></ul></div>
<p>
Return <span class="emphasis"><em>true</em></span> if there is an arithmetic overflow when subtracting 'y' from 'x'
as signed integers.
</p>
</li>
<li class="listitem" style="list-style-type: none">
<code class="code">CARRY4(x,y)</code> - Test for unsigned overflow operator - INT_CARRY
</dd>
<dt><span class="term"><code class="code">CARRY4(x,y)</code> - Test for unsigned overflow operator - INT_CARRY</span></dt>
<dd>
<div class="itemizedlist"><ul class="itemizedlist compact" style="list-style-type: bullet; "><li class="listitem" style="list-style-type: disc">The digit '4' indicates the size of both input operands 'x' and 'y' in bytes.</li></ul></div>
<p>
Return <span class="emphasis"><em>true</em></span> if there is an arithmetic overflow when adding 'x' and 'y'
as unsigned integers.
</p>
</li>
<li class="listitem" style="list-style-type: none">
<code class="code">SCARRY4(x,y)</code> - Test for signed overflow operator - INT_SCARRY
</dd>
<dt><span class="term"><code class="code">SCARRY4(x,y)</code> - Test for signed overflow operator - INT_SCARRY</span></dt>
<dd>
<div class="itemizedlist"><ul class="itemizedlist compact" style="list-style-type: bullet; "><li class="listitem" style="list-style-type: disc">The digit '4' indicates the size of both input operands 'x' and 'y' in bytes.</li></ul></div>
<p>
Return <span class="emphasis"><em>true</em></span> if there is an arithmetic overflow when adding 'x' and 'y'
as signed integers.
</p>
</li>
</ul></div>
</dd>
</dl></div>
</div>
</div>
</div>
@ -1025,14 +1084,14 @@
<a name="ConceptPrototypeUnaffected"></a>Unaffected</h4></div></div></div>
<p>
Prototype models can specify a set of <span class="bold"><strong>unaffected</strong></span>memory locations,
Prototype models can specify a set of <span class="bold"><strong>unaffected</strong></span> memory locations,
whose value must be <span class="emphasis"><em>preserved</em></span> across the function. I.e. each location
must hold the same value at a function's exit that it held coming into the function.
These encompass a calling convention's <span class="emphasis"><em>saved registers</em></span>, where a calling function
can store values it doesn't want to change unexpectedly, but also may include other registers that are
known not to change, like the stack pointer.
The decompiler uses the information to determine which locations can be safely propagated across
a sub-function.
a called function.
</p>
</div>
<div class="sect3">

View file

@ -62,7 +62,9 @@
<div class="informalexample">
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: bullet; ">
<li class="listitem" style="list-style-type: disc">
Press the <span class="guiicon"><img src="images/decompileFunction.gif"></span> icon
Press the <span class="guiicon">
<span class="inlinemediaobject"><img src="images/decompileFunction.gif" width="16" height="16"></span>
</span> icon
in the tool bar, <span class="emphasis"><em>or</em></span>
</li>
<li class="listitem" style="list-style-type: disc">
@ -110,54 +112,66 @@
</p>
<div class="informalexample">
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: bullet; ">
<li class="listitem" style="list-style-type: disc">
<span class="bold"><strong>Recovering Expressions</strong></span>: The
decompiler does full data-flow analysis which allows it to
perform slicing on functions: complicated expressions, which have been split into
distinct operations/instructions and then mixed together with
other instructions by the compiling/optimizing process, are
reconstituted back into a single line.
</li>
<li class="listitem" style="list-style-type: disc">
<span class="bold"><strong>Recovering High-Level Scoped
Variables</strong></span>: The decompiler understands how compilers
use processor stacks and registers to implement variables with
different scopes within a function. Data-flow analysis allows it to
follow what was originally a single variable as it moves from
the stack, into a register, into a different register, etc. Thus
it can effectively recover the original programs concept of a
variable, minimizing the need to introduce artificial variables
in the output.
</li>
<li class="listitem" style="list-style-type: disc">
<span class="bold"><strong>Recovering Function Parameters</strong></span>:
The decompiler understands the parameter passing conventions of
the compiler and can reconstruct the original form of
function calls.
</li>
<li class="listitem" style="list-style-type: disc">
<span class="bold"><strong>Using Data-type, Name, and Signature
Annotations</strong></span>: The decompiler automatically pulls in
all the different data types and variable names that the user
has applied to functions, and the C output is altered to reflect
this. High-level variables are appropriately named, structure
fields and array indices are calculated and displayed with
correct syntax, constant char pointers are replaced with
appropriate quoted strings, etc.
</li>
<li class="listitem" style="list-style-type: disc">
<span class="bold"><strong>Propagating Local Data-types</strong></span>:
The decompiler infers the data-type of unlabeled variables
by propagating information from other sources throughout a function.
</li>
<li class="listitem" style="list-style-type: disc">
<span class="bold"><strong>Recovering Structure Definitions</strong></span>:
The decompiler can be used to create structures that match the usage
pattern of particular functions and variables, automatically discovering
component offsets and data-types.
</li>
</ul></div>
<div class="variablelist"><dl class="variablelist">
<dt><span class="term"><span class="bold"><strong>Recovering Expressions</strong></span></span></dt>
<dd>
<p>
The decompiler does full data-flow analysis which allows it to
perform slicing on functions: complicated expressions, which have been split into
distinct operations/instructions and then mixed together with
other instructions by the compiling/optimizing process, are
reconstituted back into a single line.
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Recovering High-Level Scoped Variables</strong></span></span></dt>
<dd>
<p>
The decompiler understands how compilers
use processor stacks and registers to implement variables with
different scopes within a function. Data-flow analysis allows it to
follow what was originally a single variable as it moves from
the stack, into a register, into a different register, etc. Thus
it can effectively recover the original program's concept of a
variable, minimizing the need to introduce artificial variables
in the output.
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Recovering Function Parameters</strong></span></span></dt>
<dd>
<p>
The decompiler understands the parameter passing conventions of
the compiler and can reconstruct the original form of
function calls.
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Using Data-type, Name, and Signature Annotations</strong></span></span></dt>
<dd>
<p>
The decompiler automatically pulls in
all the different data types and variable names that the user
has applied to functions, and the C output is altered to reflect
this. High-level variables are appropriately named, structure
fields and array indices are calculated and displayed with
correct syntax, constant char pointers are replaced with
appropriate quoted strings, etc.
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Propagating Local Data-types</strong></span></span></dt>
<dd>
<p>
The decompiler infers the data-type of unlabeled variables
by propagating information from other sources throughout a function.
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Recovering Structure Definitions</strong></span></span></dt>
<dd>
<p>
The decompiler can be used to create structures that match the usage
pattern of particular functions and variables, automatically discovering
component offsets and data-types.
</p>
</dd>
</dl></div>
</div>
<p>
</p>

View file

@ -64,7 +64,9 @@
</p>
<div class="informalexample">
<div class="variablelist"><dl class="variablelist">
<dt><span class="term"><span class="bold"><strong>Cache Size (Functions)</strong></span></span></dt>
<dt>
<a name="GeneralCacheSize"></a><span class="term"><span class="bold"><strong>Cache Size (Functions)</strong></span></span>
</dt>
<dd>
<p>
Decompilation results for a single function can be compute intensive to produce.
@ -74,7 +76,9 @@
a new decompilation is not triggered.
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Decompiler Max-Payload (MBytes)</strong></span></span></dt>
<dt>
<a name="GeneralMaxPayload"></a><span class="term"><span class="bold"><strong>Decompiler Max-Payload (MBytes)</strong></span></span>
</dt>
<dd>
<p>
This is a limit on the number of bytes that can be produced by the decompiler process as output
@ -85,7 +89,9 @@
"Decompiler results exceeded payload limit ..." is displayed.
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Decompiler Timeout (seconds)</strong></span></span></dt>
<dt>
<a name="GeneralTimeout"></a><span class="term"><span class="bold"><strong>Decompiler Timeout (seconds)</strong></span></span>
</dt>
<dd>
<p>
This option sets an upper limit on the number of seconds the decompiler spends attempting
@ -113,12 +119,14 @@
</p>
<div class="informalexample">
<div class="variablelist"><dl class="variablelist">
<dt><span class="term"><span class="bold"><strong>Alias Blocking</strong></span></span></dt>
<dt>
<a name="AnalysisAliasBlocking"></a><span class="term"><span class="bold"><strong>Alias Blocking</strong></span></span>
</dt>
<dd>
<p>
When deciding if an individual stack location has become dead, the decompiler
must consider <span class="emphasis"><em>aliases</em></span>, pointers onto the stack that could
be used to modify the location within a sub-function. One strong heuristic the decompiler
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.
@ -149,7 +157,9 @@
knowing immediately if the stack location is part of a larger structure or array.
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Eliminate unreachable code</strong></span></span></dt>
<dt>
<a name="AnalysisUnreachable"></a><span class="term"><span class="bold"><strong>Eliminate unreachable code</strong></span></span>
</dt>
<dd>
<p>
When this is toggled <span class="emphasis"><em>on</em></span>, the decompiler eliminates code that it
@ -160,7 +170,9 @@
by the control-flow structure -- <code class="code">if (false) { ... }</code>.
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Ignore unimplemented instructions</strong></span></span></dt>
<dt>
<a name="AnalysisIgnoreUnimplemented"></a><span class="term"><span class="bold"><strong>Ignore unimplemented instructions</strong></span></span>
</dt>
<dd>
<p>
When toggled <span class="emphasis"><em>on</em></span>, the decompiler treats instructions whose semantics
@ -174,7 +186,9 @@
control-flow does not fall through.
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Infer constant pointers</strong></span></span></dt>
<dt>
<a name="AnalysisInferConstants"></a><span class="term"><span class="bold"><strong>Infer constant pointers</strong></span></span>
</dt>
<dd>
<p>
When toggled <span class="emphasis"><em>on</em></span>, the decompiler infers a data-type for constants
@ -185,7 +199,9 @@
the decompiler to other parts of the function.
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Respect read-only flags</strong></span></span></dt>
<dt>
<a name="AnalysisReadOnly"></a><span class="term"><span class="bold"><strong>Respect read-only flags</strong></span></span>
</dt>
<dd>
<p>
When toggled <span class="emphasis"><em>on</em></span>, the decompiler treats any values in memory
@ -204,7 +220,9 @@
(See <a class="xref" href="DecompilerAnnotations.html#AnnoteMutability" title="Data Mutability">&#8220;Data Mutability&#8221;</a>).
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Simplify extended integer operations</strong></span></span></dt>
<dt>
<a name="AnalysisExtendedPrecision"></a><span class="term"><span class="bold"><strong>Simplify extended integer operations</strong></span></span>
</dt>
<dd>
<p>
This toggles whether the decompiler attempts to simplify double precision arithmetic operations,
@ -213,7 +231,9 @@
limited, and only certain constructions are simplified.
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Simplify predication</strong></span></span></dt>
<dt>
<a name="AnalysisPredicate"></a><span class="term"><span class="bold"><strong>Simplify predication</strong></span></span>
</dt>
<dd>
<p>
When this option is active, the decompiler simplifies code sequences containing
@ -224,7 +244,9 @@
printed once.
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Use in-place assignment operators</strong></span></span></dt>
<dt>
<a name="AnalysisInPlace"></a><span class="term"><span class="bold"><strong>Use in-place assignment operators</strong></span></span>
</dt>
<dd>
<p>
When toggled <span class="emphasis"><em>on</em></span>, the decompiler employs in-place assignment operators,
@ -248,13 +270,17 @@
</p>
<div class="informalexample">
<div class="variablelist"><dl class="variablelist">
<dt><span class="term"><span class="bold"><strong>Background Color</strong></span></span></dt>
<dt>
<a name="DisplayBackgroundColor"></a><span class="term"><span class="bold"><strong>Background Color</strong></span></span>
</dt>
<dd>
<p>
Assign the background color for the Decompiler window.
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Color for &lt;token&gt;</strong></span></span></dt>
<dt>
<a name="DisplayTokenColor"></a><span class="term"><span class="bold"><strong>Color for &lt;token&gt;</strong></span></span>
</dt>
<dd>
<p>
Assign colors to the different types of language tokens emitted by the decompiler.
@ -281,7 +307,9 @@
<p>
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Color Default</strong></span></span></dt>
<dt>
<a name="DisplayColorDefault"></a><span class="term"><span class="bold"><strong>Color Default</strong></span></span>
</dt>
<dd>
<p>
Assign the color to any characters emitted by the decompiler that do not fall into one of token types
@ -289,20 +317,26 @@
characters.
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Color for Current Variable Highlight</strong></span></span></dt>
<dt>
<a name="DisplayCurrentHighlight"></a><span class="term"><span class="bold"><strong>Color for Current Variable Highlight</strong></span></span>
</dt>
<dd>
<p>
Assign the background color used to highlight the token currently under the cursor in a Decompiler Window.
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Color for Highlighting Find Matches</strong></span></span></dt>
<dt>
<a name="DisplayFindHighlight"></a><span class="term"><span class="bold"><strong>Color for Highlighting Find Matches</strong></span></span>
</dt>
<dd>
<p>
Assign the background color used to highlight characters matching the current <span class="emphasis"><em>Find</em></span> pattern.
See <a class="xref" href="DecompilerWindow.html#ActionFind" title="Find ...">&#8220;Find ...&#8221;</a>.
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Comment line indent level</strong></span></span></dt>
<dt>
<a name="DisplayCommentIndent"></a><span class="term"><span class="bold"><strong>Comment line indent level</strong></span></span>
</dt>
<dd>
<p>
Set the number of characters that comment lines are indented within decompiler output. This applies only
@ -310,14 +344,18 @@
are not indented.
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Comment style</strong></span></span></dt>
<dt>
<a name="DisplayCommentStyle"></a><span class="term"><span class="bold"><strong>Comment style</strong></span></span>
</dt>
<dd>
<p>
Set the language syntax used to delimit comments emitted as part of decompiler output. For C and Java,
the choices are <code class="code">/* C style comments */</code> and <code class="code">// C++ style comments</code>.
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Disable printing of type casts</strong></span></span></dt>
<dt>
<a name="DisplayDisableCasts"></a><span class="term"><span class="bold"><strong>Disable printing of type casts</strong></span></span>
</dt>
<dd>
<p>
Set whether the syntax for <span class="emphasis"><em>type casts</em></span> is emitted in decompiler output.
@ -354,7 +392,9 @@
<p>
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Display Header comment</strong></span></span></dt>
<dt>
<a name="DisplayHeaderComment"></a><span class="term"><span class="bold"><strong>Display Header comment</strong></span></span>
</dt>
<dd>
<p>
Toggle whether the decompiler emits comments at the head (before the beginning) of a function.
@ -363,7 +403,9 @@
The inclusion of other Plate comments is controlled by the <span class="bold"><strong>Display PLATE comments</strong></span> toggle, described above.
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Display Line Numbers</strong></span></span></dt>
<dt>
<a name="DisplayLineNumbers"></a><span class="term"><span class="bold"><strong>Display Line Numbers</strong></span></span>
</dt>
<dd>
<p>
Toggle whether line numbers are displayed in any Decompiler Window. If toggled
@ -373,7 +415,9 @@
the decompiler's output.
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Display Namespaces</strong></span></span></dt>
<dt>
<a name="DisplayNamespaces"></a><span class="term"><span class="bold"><strong>Display Namespaces</strong></span></span>
</dt>
<dd>
<p>
Control how the decompiler displays namespace information associated
@ -404,7 +448,9 @@
circumstances and may produce output that is ambiguous and doesn't formally parse.
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Display Warning comments</strong></span></span></dt>
<dt>
<a name="DisplayWarningComments"></a><span class="term"><span class="bold"><strong>Display Warning comments</strong></span></span>
</dt>
<dd>
<p>
Toggle whether decompiler generated <span class="emphasis"><em>WARNING</em></span> comments are displayed as part
@ -412,7 +458,9 @@
indicate unusual conditions or possible errors (See <a class="xref" href="DecompilerAnnotations.html#CommentWarnings" title="Warning Comments">&#8220;Warning Comments&#8221;</a>).
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Font</strong></span></span></dt>
<dt>
<a name="DisplayFont"></a><span class="term"><span class="bold"><strong>Font</strong></span></span>
</dt>
<dd>
<p>
Set the typeface used to render characters in any Decompiler Window. Indentation is generally clearer
@ -420,7 +468,9 @@
the font can also be controlled from this option.
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Integer format</strong></span></span></dt>
<dt>
<a name="DisplayIntegerFormat"></a><span class="term"><span class="bold"><strong>Integer format</strong></span></span>
</dt>
<dd>
<p>
Set how integer constants are formatted in the decompiler output.
@ -445,7 +495,9 @@
a round hexadecimal value (0x10, 0x100, 0x1000, etc.)
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Maximum characters in a code line</strong></span></span></dt>
<dt>
<a name="DisplayMaxChar"></a><span class="term"><span class="bold"><strong>Maximum characters in a code line</strong></span></span>
</dt>
<dd>
<p>
Set the maximum number of characters in a line of code emitted by the decompiler before a line break
@ -454,7 +506,9 @@
extend the line beyond the maximum.
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Number of characters per indent level</strong></span></span></dt>
<dt>
<a name="DisplayIndentLevel"></a><span class="term"><span class="bold"><strong>Number of characters per indent level</strong></span></span>
</dt>
<dd>
<p>
Set the amount of indenting used to print statements within a nested scope in the
@ -463,7 +517,9 @@
bodies adds this number characters.
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Print 'NULL' for null pointers</strong></span></span></dt>
<dt>
<a name="DisplayNull"></a><span class="term"><span class="bold"><strong>Print 'NULL' for null pointers</strong></span></span>
</dt>
<dd>
<p>
Set how null pointers are displayed in decompiler output. If this is toggled
@ -472,7 +528,9 @@
which is then type cast into a pointer.
</p>
</dd>
<dt><span class="term"><span class="bold"><strong>Print calling convention name</strong></span></span></dt>
<dt>
<a name="DisplayConvention"></a><span class="term"><span class="bold"><strong>Print calling convention name</strong></span></span>
</dt>
<dd>
<p>
Set whether the <span class="emphasis"><em>calling convention</em></span> is printed as part of the function

View file

@ -16,7 +16,9 @@
<p>
To display the decompiler window, position the cursor on a
function in the Code Browser, then select the
<span class="guiicon"><img src="images/decompileFunction.gif"></span> icon from the tool bar, or the
<span class="guiicon">
<span class="inlinemediaobject"><img src="images/decompileFunction.gif" width="16" height="16"></span>
</span> icon from the tool bar, or the
<span class="bold"><strong>Decompile</strong></span> option from the
<span class="bold"><strong>Window</strong></span> menu in the tool.
</p>
@ -86,14 +88,17 @@
<a name="MainWindow"></a>Main Window</h2></div></div></div>
<p>
Initially pushing <span class="guiicon"><img src="images/decompileFunction.gif"></span> or selecting
<span class="bold"><strong>Decompile</strong></span> from the <span class="bold"><strong>Window</strong></span> menu in the tool
brings up the <span class="emphasis"><em>main</em></span> window. The main window always displays the function
at the <span class="emphasis"><em>current address</em></span> within the Code Browser and follows as the user navigates
within the Program. Any mouse click, menu option, or other action causing the cursor to move to a new
address in the Listing also causes the main window to display the function containing that address.
Navigation to new functions is also possible from within the window by double-clicking on function
tokens (See <a class="xref" href="DecompilerWindow.html#MouseActions" title="Mouse Actions">&#8220;Mouse Actions&#8221;</a>).
Initially pushing
<span class="guiicon">
<span class="inlinemediaobject"><img src="images/decompileFunction.gif" width="16" height="16"></span>
</span> or selecting
<span class="bold"><strong>Decompile</strong></span> from the <span class="bold"><strong>Window</strong></span> menu in the tool
brings up the <span class="emphasis"><em>main</em></span> window. The main window always displays the function
at the <span class="emphasis"><em>current address</em></span> within the Code Browser and follows as the user navigates
within the Program. Any mouse click, menu option, or other action causing the cursor to move to a new
address in the Listing also causes the main window to display the function containing that address.
Navigation to new functions is also possible from within the window by double-clicking on function
tokens (See <a class="xref" href="DecompilerWindow.html#MouseActions" title="Mouse Actions">&#8220;Mouse Actions&#8221;</a>).
</p>
<div class="sect2">
@ -118,7 +123,7 @@
<span class="emphasis"><em>Operator</em></span> tokens map to the machine instruction which performed that operation.
</p>
<p>
<span class="emphasis"><em>Function Name</em></span> tokens, if they represent a call to a sub-function, map to the
<span class="emphasis"><em>Function Name</em></span> tokens, if they represent a call to another function, map to the
machine instruction executing the call.
</p>
<p>
@ -145,8 +150,11 @@
<a name="Snapshot"></a>Snapshot Windows</h2></div></div></div>
<p>
Pressing the <span class="guiicon"><img src="images/camera-photo.png"></span>
icon in another Decompiler window's toolbar causes a <span class="emphasis"><em>Snapshot</em></span> window
Pressing the
<span class="guiicon">
<span class="inlinemediaobject"><img src="images/camera-photo.png" width="16" height="16"></span>
</span> icon
in another Decompiler window's toolbar causes a <span class="emphasis"><em>Snapshot</em></span> window
to be created, which initially shows decompilation of the same function. Multiple
Snapshot windows can be brought up to show decompilation of different functions
simultaneously. Snapshot
@ -178,6 +186,40 @@
</p>
</div>
<div class="section">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="UndefinedFunction"></a>Undefined Functions</h2></div></div></div>
<p>
If the current location within the Code Browser is in disassembled code, but that code
is not contained in a <a class="link" href="DecompilerAnnotations.html#AnnoteFormalFunctionBody" title="Formal Function Body">Formal Function Body</a>,
then the decompiler window invents a function body on the fly called an
<span class="bold"><strong>Undefined Function</strong></span>. The background color of the window
is changed to gray to indicate this special state.
</p>
<div class="mediaobject" align="center"><table border="0" summary="manufactured viewport for HTML img" style="cellpadding: 0; cellspacing: 0;" width="100%"><tr><td align="center"><img src="images/Undefined.png" align="middle" width="579" height="143"></td></tr></table></div>
<p>
</p>
<p>
The <span class="emphasis"><em>entry point</em></span> address of the Undefined Function is chosen by
backtracking through the code's control-flow from the current location to the start of
a basic block that has no flow coming in except possibly from <span class="emphasis"><em>call</em></span> instructions.
During decompilation, a function body is computed from the selected entry point (as with any function)
based on control-flow up to instructions with <span class="emphasis"><em>terminator</em></span> semantics.
</p>
<p>
The current address, as indicated by the cursor in the Listing Window for instance, is
generally <span class="emphasis"><em>not</em></span> the entry of the invented function, but the current address will be
contained somewhere in the body.
</p>
<p>
For display purposes in the window, the invented function is given a name based on the
computed entry point address with the prefix <code class="code">UndefinedFunction</code>. The function
is assigned the default calling convention, and parameters are discovered as part of
the decompiler's analysis.
</p>
</div>
<div class="section">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="ToolBar"></a>Tool Bar</h2></div></div></div>
@ -193,7 +235,9 @@
<a name="ToolBarExport"></a>Export to C</h3></div></div></div>
<p>
<span class="guiicon"><img src="images/page_edit.png"></span> - button
<span class="guiicon">
<span class="inlinemediaobject"><img src="images/page_edit.png" width="16" height="16"></span>
</span> - button
</p>
<p>
Exports the decompiled result of the current function to a file. A file chooser
@ -201,6 +245,14 @@
is not specified, a ".c" is appended to the filename. If the file already exists,
a final dialog is presented to confirm that the file should be overwritten.
</p>
<p>
This action exports a single function at a time. The user can export all functions
simultaneously from the Code Browser, by selecting the menu
<span class="bold"><strong>File -&gt; Export Program ...</strong></span> and then choosing
<a class="ulink" href="help/topics/ExporterPlugin/exporter.htm#c_cpp" target="_top">C/C++</a>
from the drop-down menu. See the full documentation for
the <a class="ulink" href="help/topics/ExporterPlugin/exporter.htm" target="_top">Export</a> dialog.
</p>
</div>
<div class="sect2">
@ -208,7 +260,9 @@
<a name="ToolBarSnapshot"></a>Snapshot</h3></div></div></div>
<p>
<span class="guiicon"><img src="images/camera-photo.png"></span> - button
<span class="guiicon">
<span class="inlinemediaobject"><img src="images/camera-photo.png" width="16" height="16"></span>
</span> - button
</p>
<p>
Creates a new <span class="emphasis"><em>Snapshot</em></span> window. The <span class="emphasis"><em>Snapshot</em></span> window
@ -223,7 +277,9 @@
<a name="ToolBarRedecompile"></a>Re-decompile</h3></div></div></div>
<p>
<span class="guiicon"><img src="images/reload3.png"></span> - button
<span class="guiicon">
<span class="inlinemediaobject"><img src="images/reload3.png" width="16" height="16"></span>
</span> - button
</p>
<p>
Triggers a re-decompilation of the current function displayed in the window.
@ -249,7 +305,9 @@
<a name="ToolBarCopy"></a>Copy</h3></div></div></div>
<p>
<span class="guiicon"><img src="images/page_white_copy.png"></span> - button
<span class="guiicon">
<span class="inlinemediaobject"><img src="images/page_white_copy.png" width="16" height="16"></span>
</span> - button
</p>
<p>
Copies the currently selected text in the decompiler window to the clipboard.
@ -293,7 +351,7 @@
<th align="left"></th>
</tr>
<tr><td align="left" valign="top">
If no Graph Service is available then this action will no be present.
If no Graph Service is available then this action will not be present.
</td></tr>
</table></div>
</div>
@ -348,10 +406,10 @@
</p>
<div class="informalexample">
<div class="variablelist"><dl class="variablelist">
<dt><span class="term"><span class="bold"><strong>Sub-function Symbols</strong></span></span></dt>
<dt><span class="term"><span class="bold"><strong>Function Symbols</strong></span></span></dt>
<dd><p>
Double clicking a sub-function name causes the
window itself to navigate away from its current function to the sub-function, triggering
Double clicking a called function name causes the
window itself to navigate away from its current function to the called function, triggering
a new decompilation if necessary and changing its display.
</p></dd>
<dt><span class="term"><span class="bold"><strong>Global Variables</strong></span></span></dt>
@ -391,7 +449,7 @@
<p>
Opens a new <span class="emphasis"><em>Snapshot</em></span> window, navigating it to the selected symbol.
This is a convenience for immediately decompiling and displaying a sub-function in a
This is a convenience for immediately decompiling and displaying a called function in a
new window, without disturbing the active window. The behavior is similar to the
Double Click action, the selected token must represent a function name symbol or possibly
a constant address, but the navigation occurs in the new Snapshot window.
@ -607,7 +665,7 @@
</p>
<p>
The action is available from any token in the decompiler window. Most tokens trigger editing
of the current function itself, but a subfunction can be edited by putting the cursor on
of the current function itself, but a called function can be edited by putting the cursor on
its name specifically.
</p>
<p>
@ -693,7 +751,8 @@
Highlight all variable tokens where the value at that point in the function is
directly affected by the value at the selected variable token.
A token is highlighted if there is a direct data-flow path
starting from the selected point and ending at the token.
starting from the selected point and ending at the token. A call operation is not
considered a direct data-flow path from its input parameters to its output value.
</p>
<p>
In the following example, the token <span class="emphasis"><em>b</em></span>, the output of
@ -709,22 +768,28 @@
directly affects the value at the selected variable token.
A token is highlighted if there is a direct data-flow path
starting from the token and ending at the selected point.
A call operation is not considered a direct data-flow path from its input parameters
to its output value.
</p></dd>
<dt><span class="term"><span class="bold"><strong>Forward Inst Slice</strong></span></span></dt>
<dt><span class="term"><span class="bold"><strong>Forward Operator Slice</strong></span></span></dt>
<dd><p>
Highlight every operator token that manipulates a value directly affected by the
value at the selected variable token. Along each direct data-flow path that
<span class="emphasis"><em>starts</em></span>
at the selected point, each token representing an operation is highlighted, along with
any explicit variable it writes to.
any explicit variable read or written by the operation. A call operation is not
considered a direct data-flow path from its input parameters to its output value.
This is an alternate presentation of the slice displayed by the Forward Slice action.
</p></dd>
<dt><span class="term"><span class="bold"><strong>Backward Inst Slice</strong></span></span></dt>
<dt><span class="term"><span class="bold"><strong>Backward Operator Slice</strong></span></span></dt>
<dd><p>
Highlight every operator token that manipulates a value that directly affects the
value at the selected variable token. Along each direct data-flow path that
<span class="emphasis"><em>ends</em></span>
at the selected point, each token representing an operation is highlighted, along with
any explicit variable it writes to.
any explicit variable read or written by the operation. A call operation is not
considered a direct data-flow path from its input parameters to its output value.
This is an alternate presentation of the slice displayed by the Backward Slice action.
</p></dd>
</dl></div>
</div>
@ -776,19 +841,19 @@
<a name="ActionOverrideSignature"></a>Override Signature</h3></div></div></div>
<p>
Override the function prototype corresponding to the sub-function under the cursor.
Override the function prototype corresponding to the function under the cursor.
</p>
<p>
This action can be triggered at <span class="emphasis"><em>call sites</em></span>, where the function
being decompiled is calling into another sub-function. Users must select either the token representing
the sub-function's name or the tokens representing the function pointer at the call site.
being decompiled is calling into another function. Users must select either the token representing
the called function's name or the tokens representing the function pointer at the call site.
A dialog is brought up where the a complete <span class="emphasis"><em>function declaration</em></span>, specifying
the return data-type along with the name and data-type for each input parameter. Additionally,
the "Calling Convention", "In Line", and "No Return" properties of the function prototype
can be set (See <a class="xref" href="DecompilerAnnotations.html#AnnotePrototype" title="Function Prototypes">&#8220;Function Prototypes&#8221;</a>).
</p>
<p>
Confirming the dialog forces the new function prototype on the decompiler's view of the sub-function,
Confirming the dialog forces the new function prototype on the decompiler's view of the called function,
but only for the single selected call site.
</p>
<p>
@ -861,12 +926,12 @@
<a name="ActionRemoveOverride"></a>Remove Signature Override</h3></div></div></div>
<p>
Remove the overriding function prototype applied previously to the sub-function under the cursor.
Remove the overriding function prototype applied previously to the called function under the cursor.
</p>
<p>
This action can only be triggered at <span class="emphasis"><em>call sites</em></span>, where an overriding
prototype was previously placed by the <a class="xref" href="DecompilerWindow.html#ActionOverrideSignature" title="Override Signature">&#8220;Override Signature&#8221;</a> command. As with
this command, users must select either the token representing the sub-function's name or the
this command, users must select either the token representing the called function's name or the
tokens representing the function pointer at the call site. The action causes the
override to be removed immediately. Parameter information will be drawn from the decompiler's
normal analysis.
@ -882,7 +947,7 @@
</p>
<p>
The current function can be renamed by selecting the name token within the function's
declaration at the top of the decompiler window, or individual subfunctions
declaration at the top of the decompiler window, or individual called functions
can be renamed by selecting their name token within a call expression.
This action brings up a dialog containing a text field prepopulated with the
name to be changed. The current namespace (and any parent namespaces) is
@ -1067,6 +1132,12 @@
input parameters to be created as well. In this situation, the action is equivalent to
<a class="xref" href="DecompilerWindow.html#ActionCommitParams" title="Commit Params/Return">&#8220;Commit Params/Return&#8221;</a>, and a confirmation dialog comes up to notify the user.
</p>
<p>
Setting a data-type on the return value using this action affects decompilation for the
function itself and, additionally, any function that calls this function. Within a calling
function, the decompiler propagates the data-type into the variable or expression incorporating
the return value at each call site.
</p>
</div>
<div class="sect2">
@ -1102,6 +1173,11 @@
parameter did not exist previously, then its data-type is <span class="emphasis"><em>not</em></span>
forced by this action.
</p>
<p>
Data-type information applied to parameters using this action is especially impactful
because it affects decompilation for the function owning the parameter and, additionally,
any function that calls this owning function.
</p>
</div>
<div class="sect2">

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB

View file

@ -22,6 +22,7 @@ import java.awt.Font;
import java.awt.event.MouseEvent;
import ghidra.GhidraOptions.CURSOR_MOUSE_BUTTON_NAMES;
import ghidra.app.util.HelpTopics;
import ghidra.framework.options.Options;
import ghidra.framework.options.ToolOptions;
import ghidra.framework.plugintool.Plugin;
@ -520,92 +521,169 @@ public class DecompileOptions {
* @param ownerPlugin the plugin to which the options should be registered
* @param opt the options object to register with
* @param program the program
* @param help the help
*/
public void registerOptions(Plugin ownerPlugin, ToolOptions opt, Program program,
HelpLocation help) {
opt.registerOption(PREDICATE_OPTIONSTRING, PREDICATE_OPTIONDEFAULT, help,
public void registerOptions(Plugin ownerPlugin, ToolOptions opt, Program program) {
opt.registerOption(PREDICATE_OPTIONSTRING,
PREDICATE_OPTIONDEFAULT,
new HelpLocation(HelpTopics.DECOMPILER, "AnalysisPredicate"),
PREDICATE_OPTIONDESCRIPTION);
opt.registerOption(READONLY_OPTIONSTRING, READONLY_OPTIONDEFAULT, help,
opt.registerOption(READONLY_OPTIONSTRING,
READONLY_OPTIONDEFAULT,
new HelpLocation(HelpTopics.DECOMPILER, "AnalysisReadOnly"),
READONLY_OPTIONDESCRIPTION);
opt.registerOption(ELIMINATE_UNREACHABLE_OPTIONSTRING, ELIMINATE_UNREACHABLE_OPTIONDEFAULT,
help, ELIMINATE_UNREACHABLE_OPTIONDESCRIPTION);
opt.registerOption(ELIMINATE_UNREACHABLE_OPTIONSTRING,
ELIMINATE_UNREACHABLE_OPTIONDEFAULT,
new HelpLocation(HelpTopics.DECOMPILER, "AnalysisUnreachable"),
ELIMINATE_UNREACHABLE_OPTIONDESCRIPTION);
opt.registerOption(SIMPLIFY_DOUBLEPRECISION_OPTIONSTRING,
SIMPLIFY_DOUBLEPRECISION_OPTIONDEFAULT, help,
SIMPLIFY_DOUBLEPRECISION_OPTIONDEFAULT,
new HelpLocation(HelpTopics.DECOMPILER, "AnalysisExtendedPrecision"),
SIMPLIFY_DOUBLEPRECISION_OPTIONDESCRIPTION);
opt.registerOption(IGNOREUNIMPL_OPTIONSTRING, IGNOREUNIMPL_OPTIONDEFAULT, help,
opt.registerOption(IGNOREUNIMPL_OPTIONSTRING,
IGNOREUNIMPL_OPTIONDEFAULT,
new HelpLocation(HelpTopics.DECOMPILER, "AnalysisIgnoreUnimplemented"),
IGNOREUNIMPL_OPTIONDESCRIPTION);
opt.registerOption(INFERCONSTPTR_OPTIONSTRING, INFERCONSTPTR_OPTIONDEFAULT, help,
opt.registerOption(INFERCONSTPTR_OPTIONSTRING,
INFERCONSTPTR_OPTIONDEFAULT,
new HelpLocation(HelpTopics.DECOMPILER, "AnalysisInferConstants"),
INFERCONSTPTR_OPTIONDESCRIPTION);
opt.registerOption(NULLTOKEN_OPTIONSTRING, NULLTOKEN_OPTIONDEFAULT, help,
opt.registerOption(NULLTOKEN_OPTIONSTRING,
NULLTOKEN_OPTIONDEFAULT,
new HelpLocation(HelpTopics.DECOMPILER, "DisplayNull"),
NULLTOKEN_OPTIONDESCRIPTION);
opt.registerOption(INPLACEOP_OPTIONSTRING, INPLACEOP_OPTIONDEFAULT, help,
opt.registerOption(INPLACEOP_OPTIONSTRING,
INPLACEOP_OPTIONDEFAULT,
new HelpLocation(HelpTopics.DECOMPILER, "AnalysisInPlace"),
INPLACEOP_OPTIONDESCRIPTION);
opt.registerOption(ALIASBLOCK_OPTIONSTRING, ALIASBLOCK_OPTIONDEFAULT, help,
opt.registerOption(ALIASBLOCK_OPTIONSTRING,
ALIASBLOCK_OPTIONDEFAULT,
new HelpLocation(HelpTopics.DECOMPILER, "AnalysisAliasBlocking"),
ALIASBLOCK_OPTIONDESCRIPTION);
opt.registerOption(CONVENTION_OPTIONSTRING, CONVENTION_OPTIONDEFAULT, help,
opt.registerOption(CONVENTION_OPTIONSTRING,
CONVENTION_OPTIONDEFAULT,
new HelpLocation(HelpTopics.DECOMPILER, "DisplayConvention"),
CONVENTION_OPTIONDESCRIPTION);
opt.registerOption(NOCAST_OPTIONSTRING, NOCAST_OPTIONDEFAULT, help,
opt.registerOption(NOCAST_OPTIONSTRING,
NOCAST_OPTIONDEFAULT,
new HelpLocation(HelpTopics.DECOMPILER, "DisplayDisableCasts"),
NOCAST_OPTIONDESCRIPTION);
opt.registerOption(MAXWIDTH_OPTIONSTRING, MAXWIDTH_OPTIONDEFAULT, help,
opt.registerOption(MAXWIDTH_OPTIONSTRING,
MAXWIDTH_OPTIONDEFAULT,
new HelpLocation(HelpTopics.DECOMPILER, "DisplayMaxChar"),
MAXWIDTH_OPTIONDESCRIPTION);
opt.registerOption(INDENTWIDTH_OPTIONSTRING, INDENTWIDTH_OPTIONDEFAULT, help,
opt.registerOption(INDENTWIDTH_OPTIONSTRING,
INDENTWIDTH_OPTIONDEFAULT,
new HelpLocation(HelpTopics.DECOMPILER, "DisplayIndentLevel"),
INDENTWIDTH_OPTIONDESCRIPTION);
opt.registerOption(COMMENTINDENT_OPTIONSTRING, COMMENTINDENT_OPTIONDEFAULT, help,
opt.registerOption(COMMENTINDENT_OPTIONSTRING,
COMMENTINDENT_OPTIONDEFAULT,
new HelpLocation(HelpTopics.DECOMPILER, "DisplayCommentIndent"),
COMMENTINDENT_OPTIONDESCRIPTION);
opt.registerOption(COMMENTSTYLE_OPTIONSTRING, COMMENTSTYLE_OPTIONDEFAULT, help,
opt.registerOption(COMMENTSTYLE_OPTIONSTRING,
COMMENTSTYLE_OPTIONDEFAULT,
new HelpLocation(HelpTopics.DECOMPILER, "DisplayCommentStyle"),
COMMENTSTYLE_OPTIONDESCRIPTION);
opt.registerOption(COMMENTEOL_OPTIONSTRING, COMMENTEOL_OPTIONDEFAULT, help,
opt.registerOption(COMMENTEOL_OPTIONSTRING,
COMMENTEOL_OPTIONDEFAULT,
new HelpLocation(HelpTopics.DECOMPILER, "CommentOptions"),
COMMENTEOL_OPTIONDESCRIPTION);
opt.registerOption(COMMENTPRE_OPTIONSTRING, COMMENTPRE_OPTIONDEFAULT, help,
opt.registerOption(COMMENTPRE_OPTIONSTRING,
COMMENTPRE_OPTIONDEFAULT,
new HelpLocation(HelpTopics.DECOMPILER, "CommentOptions"),
COMMENTPRE_OPTIONDESCRIPTION);
opt.registerOption(COMMENTPOST_OPTIONSTRING, COMMENTPOST_OPTIONDEFAULT, help,
opt.registerOption(COMMENTPOST_OPTIONSTRING,
COMMENTPOST_OPTIONDEFAULT,
new HelpLocation(HelpTopics.DECOMPILER, "CommentOptions"),
COMMENTPOST_OPTIONDESCRIPTION);
opt.registerOption(COMMENTPLATE_OPTIONSTRING, COMMENTPLATE_OPTIONDEFAULT, help,
opt.registerOption(COMMENTPLATE_OPTIONSTRING,
COMMENTPLATE_OPTIONDEFAULT,
new HelpLocation(HelpTopics.DECOMPILER, "CommentOptions"),
COMMENTPLATE_OPTIONDESCRIPTION);
opt.registerOption(COMMENTWARN_OPTIONSTRING, COMMENTWARN_OPTIONDEFAULT, help,
opt.registerOption(COMMENTWARN_OPTIONSTRING,
COMMENTWARN_OPTIONDEFAULT,
new HelpLocation(HelpTopics.DECOMPILER, "DisplayWarningComments"),
COMMENTWARN_OPTIONDESCRIPTION);
opt.registerOption(COMMENTHEAD_OPTIONSTRING, COMMENTHEAD_OPTIONDEFAULT, help,
opt.registerOption(COMMENTHEAD_OPTIONSTRING,
COMMENTHEAD_OPTIONDEFAULT,
new HelpLocation(HelpTopics.DECOMPILER, "DisplayHeaderComment"),
COMMENTHEAD_OPTIONDESCRIPTION);
opt.registerOption(NAMESPACE_OPTIONSTRING, NAMESPACE_OPTIONDEFAULT, help,
opt.registerOption(NAMESPACE_OPTIONSTRING,
NAMESPACE_OPTIONDEFAULT,
new HelpLocation(HelpTopics.DECOMPILER, "DisplayNamespaces"),
NAMESPACE_OPTIONDESCRIPTION);
opt.registerOption(INTEGERFORMAT_OPTIONSTRING, INTEGERFORMAT_OPTIONDEFAULT, help,
opt.registerOption(INTEGERFORMAT_OPTIONSTRING,
INTEGERFORMAT_OPTIONDEFAULT,
new HelpLocation(HelpTopics.DECOMPILER, "DisplayIntegerFormat"),
INTEGERFORMAT_OPTIONDESCRIPTION);
opt.registerOption(HIGHLIGHT_KEYWORD_MSG, HIGHLIGHT_KEYWORD_DEF, help,
opt.registerOption(HIGHLIGHT_KEYWORD_MSG,
HIGHLIGHT_KEYWORD_DEF,
new HelpLocation(HelpTopics.DECOMPILER, "DisplayTokenColor"),
"Color used for highlighting keywords.");
opt.registerOption(HIGHLIGHT_TYPE_MSG, HIGHLIGHT_TYPE_DEF, help,
opt.registerOption(HIGHLIGHT_TYPE_MSG,
HIGHLIGHT_TYPE_DEF,
new HelpLocation(HelpTopics.DECOMPILER, "DisplayTokenColor"),
"Color used for highlighting types.");
opt.registerOption(HIGHLIGHT_FUNCTION_MSG, HIGHLIGHT_FUNCTION_DEF, help,
opt.registerOption(HIGHLIGHT_FUNCTION_MSG,
HIGHLIGHT_FUNCTION_DEF,
new HelpLocation(HelpTopics.DECOMPILER, "DisplayTokenColor"),
"Color used for highlighting function names.");
opt.registerOption(HIGHLIGHT_COMMENT_MSG, HIGHLIGHT_COMMENT_DEF, help,
opt.registerOption(HIGHLIGHT_COMMENT_MSG,
HIGHLIGHT_COMMENT_DEF,
new HelpLocation(HelpTopics.DECOMPILER, "DisplayTokenColor"),
"Color used for highlighting comments.");
opt.registerOption(HIGHLIGHT_VARIABLE_MSG, HIGHLIGHT_VARIABLE_DEF, help,
opt.registerOption(HIGHLIGHT_VARIABLE_MSG,
HIGHLIGHT_VARIABLE_DEF,
new HelpLocation(HelpTopics.DECOMPILER, "DisplayTokenColor"),
"Color used for highlighting variables.");
opt.registerOption(HIGHLIGHT_CONST_MSG, HIGHLIGHT_CONST_DEF, help,
opt.registerOption(HIGHLIGHT_CONST_MSG,
HIGHLIGHT_CONST_DEF,
new HelpLocation(HelpTopics.DECOMPILER, "DisplayTokenColor"),
"Color used for highlighting constants.");
opt.registerOption(HIGHLIGHT_PARAMETER_MSG, HIGHLIGHT_PARAMETER_DEF, help,
opt.registerOption(HIGHLIGHT_PARAMETER_MSG,
HIGHLIGHT_PARAMETER_DEF,
new HelpLocation(HelpTopics.DECOMPILER, "DisplayTokenColor"),
"Color used for highlighting parameters.");
opt.registerOption(HIGHLIGHT_GLOBAL_MSG, HIGHLIGHT_GLOBAL_DEF, help,
opt.registerOption(HIGHLIGHT_GLOBAL_MSG,
HIGHLIGHT_GLOBAL_DEF,
new HelpLocation(HelpTopics.DECOMPILER, "DisplayTokenColor"),
"Color used for highlighting global variables.");
opt.registerOption(HIGHLIGHT_DEFAULT_MSG, HIGHLIGHT_DEFAULT_DEF, help,
opt.registerOption(HIGHLIGHT_DEFAULT_MSG,
HIGHLIGHT_DEFAULT_DEF,
new HelpLocation(HelpTopics.DECOMPILER, "DisplayColorDefault"),
"The color used when a specific color is not specified.");
opt.registerOption(CODE_VIEWER_BACKGROUND_COLOR_MSG, CODE_VIEWER_BACKGROUND_COLOR, help,
opt.registerOption(CODE_VIEWER_BACKGROUND_COLOR_MSG,
CODE_VIEWER_BACKGROUND_COLOR,
new HelpLocation(HelpTopics.DECOMPILER, "DisplayBackgroundColor"),
"The background color of the decompiler window.");
opt.registerOption(FONT_MSG, DEFAULT_FONT, help,
opt.registerOption(FONT_MSG,
DEFAULT_FONT,
new HelpLocation(HelpTopics.DECOMPILER, "DisplayFont"),
"The font used to render text in the decompiler.");
opt.registerOption(SEARCH_HIGHLIGHT_MSG, SEARCH_HIGHLIGHT_DEF, help,
opt.registerOption(SEARCH_HIGHLIGHT_MSG,
SEARCH_HIGHLIGHT_DEF,
new HelpLocation(HelpTopics.DECOMPILER, "DisplayFindHighlight"),
"The color used to highlight matches using the Find Dialog.");
opt.registerOption(LINE_NUMBER_MSG, LINE_NUMBER_DEF, help,
opt.registerOption(LINE_NUMBER_MSG,
LINE_NUMBER_DEF,
new HelpLocation(HelpTopics.DECOMPILER, "DisplayLineNumbers"),
"Toggle for displaying line numbers in the decompiler.");
opt.registerOption(DECOMPILE_TIMEOUT, SUGGESTED_DECOMPILE_TIMEOUT_SECS, help,
opt.registerOption(DECOMPILE_TIMEOUT,
SUGGESTED_DECOMPILE_TIMEOUT_SECS,
new HelpLocation(HelpTopics.DECOMPILER, "GeneralTimeout"),
"The number of seconds to allow the decompiler to run before terminating the " +
"decompiler.\nCurrently this does not affect the UI, which will run indefinitely. " +
"This setting currently only affects background analysis that uses the decompiler.");
opt.registerOption(PAYLOAD_LIMIT, SUGGESTED_MAX_PAYLOAD_BYTES, help,
opt.registerOption(PAYLOAD_LIMIT,
SUGGESTED_MAX_PAYLOAD_BYTES,
new HelpLocation(HelpTopics.DECOMPILER, "GeneralMaxPayload"),
"The maximum size of the decompiler result payload in MBYtes (Suggested value: 50).");
opt.registerOption(HIGHLIGHT_CURRENT_VARIABLE_MSG, HIGHLIGHT_CURRENT_VARIABLE_DEF, help,
opt.registerOption(HIGHLIGHT_CURRENT_VARIABLE_MSG,
HIGHLIGHT_CURRENT_VARIABLE_DEF,
new HelpLocation(HelpTopics.DECOMPILER, "DisplayCurrentHighlight"),
"Current variable highlight");
opt.registerOption(CACHED_RESULTS_SIZE_MSG, SUGGESTED_CACHED_RESULTS_SIZE, help,
opt.registerOption(CACHED_RESULTS_SIZE_MSG,
SUGGESTED_CACHED_RESULTS_SIZE,
new HelpLocation(HelpTopics.DECOMPILER, "GeneralCacheSize"),
CACHE_RESULTS_DESCRIPTION);
grabFromToolAndProgram(ownerPlugin, opt, program);
}

View file

@ -709,10 +709,14 @@ public class DecompilerProvider extends NavigatableComponentProviderAdapter
private void initializeDecompilerOptions() {
ToolOptions opt = tool.getOptions(OPTIONS_TITLE);
HelpLocation helpLocation = new HelpLocation(plugin.getName(), "DecompileOptions");
decompilerOptions.registerOptions(plugin, opt, program, helpLocation);
HelpLocation helpLocation = new HelpLocation(HelpTopics.DECOMPILER, "GeneralOptions");
opt.setOptionsHelpLocation(helpLocation);
opt.getOptions("Analysis")
.setOptionsHelpLocation(new HelpLocation(HelpTopics.DECOMPILER, "AnalysisOptions"));
opt.getOptions("Display")
.setOptionsHelpLocation(new HelpLocation(HelpTopics.DECOMPILER, "DisplayOptions"));
decompilerOptions.registerOptions(plugin, opt, program);
opt.addOptionsChangeListener(this);
ToolOptions codeBrowserOptions = tool.getOptions(GhidraOptions.CATEGORY_BROWSER_FIELDS);

View file

@ -30,10 +30,10 @@ import ghidra.util.HelpLocation;
public class BackwardsSliceToPCodeOpsAction extends AbstractDecompilerAction {
public BackwardsSliceToPCodeOpsAction() {
super("Highlight Backward Inst Slice");
super("Highlight Backward Operator Slice");
setHelpLocation(new HelpLocation(HelpTopics.DECOMPILER, "ActionHighlight"));
setPopupMenuData(
new MenuData(new String[] { "Highlight", "Backward Inst Slice" }, "Decompile"));
new MenuData(new String[] { "Highlight", "Backward Operator Slice" }, "Decompile"));
}
@Override
@ -50,7 +50,9 @@ public class BackwardsSliceToPCodeOpsAction extends AbstractDecompilerAction {
if (varnode != null) {
PcodeOp op = tokenAtCursor.getPcodeOp();
Set<PcodeOp> backwardSlice = DecompilerUtils.getBackwardSliceToPCodeOps(varnode);
backwardSlice.add(op);
if (op != null) {
backwardSlice.add(op);
}
DecompilerPanel decompilerPanel = context.getDecompilerPanel();
decompilerPanel.clearPrimaryHighlights();
decompilerPanel.addPcodeOpHighlights(backwardSlice,

View file

@ -30,10 +30,10 @@ import ghidra.util.HelpLocation;
public class ForwardSliceToPCodeOpsAction extends AbstractDecompilerAction {
public ForwardSliceToPCodeOpsAction() {
super("Highlight Forward Inst Slice");
super("Highlight Forward Operator Slice");
setHelpLocation(new HelpLocation(HelpTopics.DECOMPILER, "ActionHighlight"));
setPopupMenuData(
new MenuData(new String[] { "Highlight", "Forward Inst Slice" }, "Decompile"));
new MenuData(new String[] { "Highlight", "Forward Operator Slice" }, "Decompile"));
}
@Override
@ -50,7 +50,9 @@ public class ForwardSliceToPCodeOpsAction extends AbstractDecompilerAction {
if (varnode != null) {
PcodeOp op = tokenAtCursor.getPcodeOp();
Set<PcodeOp> forwardSlice = DecompilerUtils.getForwardSliceToPCodeOps(varnode);
forwardSlice.add(op);
if (op != null) {
forwardSlice.add(op);
}
DecompilerPanel decompilerPanel = context.getDecompilerPanel();
decompilerPanel.clearPrimaryHighlights();
decompilerPanel.addPcodeOpHighlights(forwardSlice,

View file

@ -31,6 +31,7 @@ import ghidra.framework.options.Options;
import ghidra.program.model.address.*;
import ghidra.program.model.data.*;
import ghidra.program.model.listing.*;
import ghidra.util.HelpLocation;
import ghidra.util.Msg;
import ghidra.util.xml.SpecXmlUtils;
import ghidra.xml.*;
@ -877,8 +878,11 @@ public class BasicCompilerSpec implements CompilerSpec {
// for upgrading/moving old property values.
Options decompilerPropertyList = program.getOptions(DECOMPILER_PROPERTY_LIST_NAME);
decompilerPropertyList
.setOptionsHelpLocation(new HelpLocation("DecompilePlugin", "ProgramOptions"));
decompilerPropertyList.registerOption(EVALUATION_MODEL_PROPERTY_NAME,
OptionType.STRING_TYPE, evaluationModelChoices[0], null,
OptionType.STRING_TYPE, evaluationModelChoices[0],
new HelpLocation("DecompilePlugin", "OptionProtoEval"),
"Select the default function prototype/evaluation model to be used during Decompiler analysis",
new StringWithChoicesEditor(evaluationModelChoices));