mirror of
https://github.com/NationalSecurityAgency/ghidra.git
synced 2025-10-05 10:49:34 +02:00
Changes in response to review
This commit is contained in:
parent
a7d5e983b7
commit
fe2d508c1c
14 changed files with 1089 additions and 379 deletions
|
@ -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
|
@ -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; }
|
||||
|
||||
|
|
|
@ -26,8 +26,12 @@
|
|||
processor specific form into Ghidra's IR language (see <a class="xref" href="DecompilerConcepts.html#ConceptPcode" title="P-code">“P-code”</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">“Context Registers”</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">“P-code Control Flow”</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">“Forcing Data-types”</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>
|
||||
|
|
|
@ -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">
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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">“Data Mutability”</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 <token></strong></span></span></dt>
|
||||
<dt>
|
||||
<a name="DisplayTokenColor"></a><span class="term"><span class="bold"><strong>Color for <token></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 ...">“Find ...”</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">“Warning Comments”</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
|
||||
|
|
|
@ -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">“Mouse Actions”</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">“Mouse Actions”</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 -> 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">“Function Prototypes”</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">“Override Signature”</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">“Commit Params/Return”</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 |
|
@ -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);
|
||||
}
|
||||
|
|
|
@ -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);
|
||||
|
|
|
@ -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,
|
||||
|
|
|
@ -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,
|
||||
|
|
|
@ -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));
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue