Description
Functor to emit block successor list.
If the unparser's control flow graph is not empty, then we use it to find successors, otherwise we consult the successors cached in the AST. The AST-cached successors were probably cached by the instruction partitioner (see Partitioner class), which does fairly extensive analysis – certainly more than just looking at the last instruction of the block.
Definition at line 512 of file AsmUnparser.h.
#include <backend/asmUnparser/AsmUnparser.h>
Inheritance diagram for Rose::BinaryAnalysis::AsmUnparser::BasicBlockSuccessors:
Collaboration diagram for Rose::BinaryAnalysis::AsmUnparser::BasicBlockSuccessors:
Public Member Functions | |
| virtual bool | operator() (bool enabled, const BasicBlockArgs &args) |
| Default callbacks. | |
 Public Member Functions inherited from Rose::BinaryAnalysis::AsmUnparser::UnparserCallback | |
| virtual bool | operator() (bool, const InsnArgs &) |
| Default callbacks. | |
| virtual bool | operator() (bool, const StaticDataArgs &) |
| Default callbacks. | |
| virtual bool | operator() (bool, const DataBlockArgs &) |
| Default callbacks. | |
| virtual bool | operator() (bool, const FunctionArgs &) |
| Default callbacks. | |
| virtual bool | operator() (bool, const InterpretationArgs &) |
| Default callbacks. | |
Member Function Documentation
◆ operator()()
|
virtual |
Default callbacks.
The default is to abort, because if these are called it means one of three things:
- The arguments are wrong in the subclass and the subclass therefore isn't providing an implementation when it thinks it is.
- The wrong type was used for the second argument. Instruction callbacks use InsnArgs, basic block callbacks use BasicBlockArgs, etc.
- The functor was added to the wrong callback list. For instance, an instruction functor was accidently added to one of the function callback lists.
Reimplemented from Rose::BinaryAnalysis::AsmUnparser::UnparserCallback.
The documentation for this class was generated from the following file:
