|
Generic INS_PROP |
|
|
|
|
|
|
|
|
|
|
The category of an instruction is a higher level semantic description of an instruction than its opcode (INS_Opcode). So, for instance, you can test for a conditional branch by using INS_Category(ins) == XED_CATEGORY_COND_BR, whereas using INS_Opcode(ins) would require that you enumerate all twenty conditional branch opcodes. A category can be converted into a string by using CATEGORY_StringShort.
|
|
|
|
Disassembly type listing of instruction |
|
|
|
|
|
If INS_HasFallThrough(INS) is TRUE, then the instruction may execute the "natural" next instruction (i.e. the one which starts immediately after this one), if it is FALSE, then the instruction following the one tested will not (normally) be executed next. So HasFallThrough is TRUE for instructions which don't change the control flow (most instructions), or for conditional branches (which might change the control flow, but might not), and FALSE for unconditional branches and calls (where the next instruction to be executed is always explicitly specified). Note that an unconditional branch or call to the next instruction still doesn't have a fall-through, since a fall through is the implicitly following instruction, and an unconditional branch never uses that.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
These are supposed to be near relative branches.
|
|
These are supposed to be near relative branches.
|
|
These are supposed to be near relative branches.
|
|
|
|
Is an IP-relative read |
|
Is an IP-relative write |
|
|
|
|
|
|
|
|
|
We treat these instructions as predicated conditional move (CMOVcc) floating conditional move (FCMOVcc) rep string ops (since they don't execute if GCX==0) |
|
|
|
|
|
|
|
Access to the stack simply means that the instruction accesses memory relative to the stack pointer (ESP or RSP), or the frame pointer (EBP or RBP). In code compiled without a frame pointer (where EBP/RBP is used as a general register), this may give a misleading result.
|
|
Detection of stack accesses is done in the same way as for INS_IsStackRead, so the same caveats apply here too.
|
|
|
|
|
|
|
|
|
|
|
|
Is the nth memory operand read? |
|
Is the nth memory operand written? |
|
|
|
|
|
|
|
Only use this function if you really want a printable version of the instruction's opcode. If you are trying to test what the opcode of an instruction is, use INS_Opcode and compare it with one of the XED_ICLASS values, or use one of the INS_Is... calls such as INS_IsMov, rather than using this function and comparing a string. Generating and comparing strings is much slower than comparing small integer values!
|
|
|
|
Get the address of the next instruction. For the IA-64 architecture, it does not make sense to add the size to the address to get the next instruction so use this primitive for all architectures.
|
|
On ia-32 and Intel64 the opcodes are constants of the form XED_ICLASS_name. The full list of valid opcodes can be found in the idata.txt file in the XED distribution (which is distributed as part of the Pin kit), and the enum definitions are in the file "xed-iclass-enum.h". Use INS_Mnemonic if you want a string.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Check to see if the given instruction is a system call and return corresponding calling standard.
|
|
|
|
|
|
DEPRECATED VARIABLE_MEMORY_REFERENCE_SIZE is no longer generated by Pin, so all code which used to test for it can (and should ) now be removed, since the definition of this symbol will disappear in a future Pin release. Pin now treats REP prefixed string ops as implicit loops, with the IPOINT_BEFORE and IPOINT_AFTER instrumentation called once for each iteration. That allows the IARG_MEMORY*_SIZE of the instruction to be that of the un-repped instruction (1,2,4 or 8 bytes), which can be determined at instrumentation time as with any other instruction. In most cases this significantly simplifies tools, which no longer have to special case unbounded memory accesses. To handle the case of zero iteration REP prefixed instructions (which used to dynamically generate a zero memory size, but which will now generate the statically determined size), REP prefixed instructions are treated as predicated, so you can use INS_InsertPredicatedCall, or IARG_EXECUTING to determine whether the instruction actually executes. Note that this is the same behavior as for CMOVcc instructions which can also have conditional memory accesses, but have never generated a zero memory size operand. |