At the moment the analysis in aIa and aIf only considers the initially given layer of function entry points. As a result of the analysis, more function entry points are discovered from call instructions, which are added as xrefs but otherwise not yet looked at further.
This should be an option to the driver, but it should be possible to recursively analyze all newly discovered functions as well.
The simplest solution would be to add all newly discovered entrypoints to the queue after each RzAbsIntResult received.
However it would be better to start by analyzing leaf functions before analyzing functions that call them because the the analysis of the caller depends on the analysis result of the callee, for example for noreturn.
Here is one idea for solving this:
Every already analyzed function is described by something like a "function summary" containing properties like noreturn behavior. Then:
- During the abstract interpretation of a function A, when a call is discovered to function B and B the summary for B is not yet known, the partial interpretation of A is saved somewhere
- B is analyzed to get its summary
- Analysis of A is resumed with the newly gained knowledge
This of course only works with call trees, not arbitrary graphs with loops.
To solve it for loops as well, some sort of constraint solving or fixpoint iteration would likely be necessary. As a simple overapproximation, we could however also go with something like an explicit "unknown" function summary whenever a loop is detected.
At the moment the analysis in
aIaandaIfonly considers the initially given layer of function entry points. As a result of the analysis, more function entry points are discovered from call instructions, which are added as xrefs but otherwise not yet looked at further.This should be an option to the driver, but it should be possible to recursively analyze all newly discovered functions as well.
The simplest solution would be to add all newly discovered entrypoints to the queue after each
RzAbsIntResultreceived.However it would be better to start by analyzing leaf functions before analyzing functions that call them because the the analysis of the caller depends on the analysis result of the callee, for example for noreturn.
Here is one idea for solving this:
Every already analyzed function is described by something like a "function summary" containing properties like noreturn behavior. Then:
This of course only works with call trees, not arbitrary graphs with loops.
To solve it for loops as well, some sort of constraint solving or fixpoint iteration would likely be necessary. As a simple overapproximation, we could however also go with something like an explicit "unknown" function summary whenever a loop is detected.