Class FoldRevalidator

java.lang.Object
ghidra.pcode.emu.jit.folding.FoldRevalidator
public class FoldRevalidator extends Object
A mechanism for re-validating the folded constants discovered during decode

Because alternative flows into a block can be discovered during decode, after that block's computations were already examined for folded constants, blocks must generally be re-examined with all discovered flows considered. We also have to consider that a block that becomes an entry point into the passage may have no incoming folded constants.

The algorithm is basically a forward traversal of block flows until we reach convergence. We haven't performed full control-flow analysis at this point, so we just follow branches and merge as we go. If the target is also an entry point, we erase all the folded constants in the "merged" state. Otherwise, we merge with the state at the target and re-queue it for interpretation. Merging consists of taking only those constants common to both states, and where those constants have the same value. If merging produces the same state as was already there, that target is not re-queued. Convergence occurs when the queue is empty. LATER: Prove it?

  • Constructor Details

    • FoldRevalidator

      public FoldRevalidator(DecoderForOnePassage passage)
      Begin re-validating a decoded passage
      Parameters:
      passage - the (mutable) decoded passage

  • Method Details

    • revalidate

      public void revalidate()
      Re-validate folded constants

      I had worried this algorithm could get expensive with loops with a counter. I thought perhaps with bit-level tricks in INT_ADD/SUB, the varnode would get invalidated one bit per re-interpretation of the loop. However, INT_ADD would invalidate all higher order bits of an unknown bit all at once.