- Aug 13, 2017
-
-
Alessandro Di Federico authored
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.
-
- Aug 12, 2017
-
-
Alessandro Di Federico authored
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.
-
Alessandro Di Federico authored
-
- Jan 23, 2017
-
-
Alessandro Di Federico authored
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.
-
- Dec 08, 2016
-
-
Alessandro Di Federico authored
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.
-
Alessandro Di Federico authored
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.
-