Giters

BoomerangDecompiler / boomerang

Boomerang Decompiler - Fighting the code-rot :)

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Use or remove range analysis

reductor opened this issue · comments

commented

Range range analysis was added in 3a9c806 however it is not currently used, we need to determine what to do with this code, I have not done any investigation into its usage currently.

commented

I think we should adopt the llvm's way of modeling things and switch to thinking/converting various parts of decompilation as Passes..
We'll have to see if we can just 'borrow' their PassManager code :)
RangeAnalysis would actually be a nice first bit of functionality we could Pass-ify :)

commented

For now I moved/converted it into a first prototype of FunctionPass. Will leave this open so that we'll remember to actually use it at some point :)

commented

It would be good to bring the full PassManager over from LLVM and start forming dependencies and breaking analysis from transformation.

commented

Agreed. although I think we should consider a few things first:

  1. Some passes might fail - we need to handle that gracefully ( LLVM doesn't have that kind of problem )
  2. Passes should be able to query for additional data
  3. Passes should have firmly defined preconditions of applicability

Pie-in-the-sky musings follow :)
What I'm currently envisioning is Boomerang having a list of Passes, where each Pass is registered observer for specific set of conditions ( applicability ) on their specific type of object (Module/Function/BasicBlock etc. ). When conditions are met, the Pass becomes 'active' for given object and a WorkItem can be added to the WorkQueue. In cases when Pass encounters some kind of problem (ambiguous decision etc. ) the WorkItems can be 'paused', a new Query object is inserted into DecisionList, and processing continues only after that Query is resolved ( by User, or another Pass )
While this might be overly complicating things, it would allow us to have multi-threaded processing of Passes, we will have the ability to add PassOrdering class to handle the cases when multiple Passes are 'active' for a single object ( we might be able to use some heuristics,predefined rules, user defined orderings, etc. )