This commit handles the situation where we have a function call with
more than one successor. This might be the case if there's an indirect
call but we're able to enumerate the possible targets statically.
This commit simply avoids an assertion, in the future we will register
all the possible destinations in the `function_call` marker.
This commit fixes a couple of bugs in function call
identification.
* Adopt a new version of `visitPredecessors` more similar to
`visitSuccessors`.
* If we meet a call to `newpc` which has an unexpected address (i.e.,
it's not the previous with respect to the last we saw) give up.
* Ensure we went through the required amount of instructions before
finding the return address (in case the architecture has delay slots).
* When counting the number of successors of a function call to check if
there's a single one, ignore the dispatcher-related basic blocks.
This commit introduces two new passes:
* `GeneratedCodeBasicInfo`: recovers from the IR some basic information
like the size of delay slots in the input architecture, the name of
the program counter and so on. It can also identify the type of a
basic block (e.g., dispatcher, jump target...). *
* `FunctionCallIdentification`: identifies function calls and injects a
marker before the associated terminator instruction.
The idea of these two passes is to try to progressively move information
we used to keep in `JumpTargetManager` into the IR, so that it is more
easily accessible and passes do not need a reference to `JTM`.
In particular by having markers for function calls available during jump
target discovery we don't have to have duplicated and suboptimal
implementation of `isCall`.
This commit also introduce some additional helper functions and an
helper class to quickly.
Alessandro Di Federico