Get code pointers out of a abstract value.

The classifier for conditional and unconditional branches

Note that this classifier can convert a conditional branch to an unconditional branch if (and only if) the condition is syntactically true or false after constant propagation. It never attempts sophisticated path trimming.

Use the architecture-specific callback to check if last statement was a call.

Note that in some cases the call is known not to return, and thus this code will never jump to the return value; in that case, the noreturnCallClassifier should fire. As such, callClassifier should always be attempted *after* noreturnCallClassifier.

Check this block ends with a return as identified by the architecture-specific processing. Basic return identification can be performed by detecting when the Instruction Pointer (ip_reg) contains the ReturnAddr symbolic value (initially placed on the top of the stack or in the Link Register by the architecture-specific state initializer). However, some architectures perform expression evaluations on this value before loading the IP (e.g. ARM will clear the low bit in T32 mode or the low 2 bits in A32 mode), so the actual detection process is deferred to architecture-specific functionality.

Classifies jumps to concrete addresses as unconditional jumps. Note that this logic is substantially similar to the tailCallClassifier in cases where the function does not establish a stack frame (i.e., leaf functions).

Note that known call targets are not eligible to be intra-procedural jump targets (see classifyDirectJump). This means that we need to conservatively prefer to mis-classify terminators as jumps rather than tail calls. The downside of this choice is that code that could be considered a tail-called function may be duplicated in some cases (i.e., considered part of multiple functions).

The alternative interpretation (eagerly preferring tail calls) can cause a section of a function to be marked as a tail-called function, thereby blocking the directJumpClassifier or the branchClassifier from recognizing the "callee" as an intra-procedural jump. This results in classification failures that we don't have any mitigations for.

Attempt to recognize a call to a function that is known to not return. These are effectively tail calls, even if the compiler did not obviously generate a tail call instruction sequence.

This classifier is important because compilers often place garbage instructions (for alignment, or possibly the next function) after calls to no-return functions. Without knowledge of no-return functions, macaw would otherwise think that the callee could return to the garbage instructions, causing later classification failures.

This functionality depends on a set of known non-return functions are specified as an input to the code discovery process (see pctxKnownFnEntries).

Note that this classifier should always be run before the callClassifier.

Attempt to recognize tail call

The current heuristic is that the target looks like a call, except the stack height in the caller is 0.

Note that, in leaf functions (i.e., with no stack usage), tail calls and jumps look substantially similar. We typically apply the jump classifier first to prefer them, which means that we very rarely recognize tail calls in leaf functions.

This computes the abstract state for the start of a block for a given branch target. It is used so that we can make use of the branch condition to simplify the abstract state.