Solved a bug that always allocated an `i32` for representing the return
address PC in the `function_call` helper (third parameter).
Now we allocate an `i64` or an `i32` depending on the input architecture
of the translated binary.
When we have an indirect call (or jump) we are sometimes able to
identify one or more possible targets, therefore, as an optimization,
before performing the indirect jump we check if the target is one of the
expected ones.
This optimization however was creating two issues with the handling of
indirect function calls: 1) the call to the `function_call` marker was
no longer positioned right before the terminator and 2) the function
call was no longer identified as an indirect function call but as call
to `anyPC`. This commit fixes these two issues.
These issues have been identified thanks to a report from Andrea
Gussoni.
This commit extendes the FunctionCallIdentification pass to identify,
for each function call, where the return address is stored, i.e., the
link register. If the the return address is stored on the top of the
stack then the link register is `nullptr`.
This information is encoded as an extra argument to the marker
`function_call`.
This commit also makes the pass ignore dispatcher-related basic blocks
and ensures that calls to `function_call` are placed *before* calls to
`exitTB` so that they won't get purged.
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.
Andrea Gussoni