<gas>
cell, and the <wordStack>
cell.
<gas>
cell change is expected.
address
arguments.
<wordStack>
goes from 306 => 323
, and that is the argument that is used as the "jump-back" destination after the argument processing.
306
) to another different one (323
) (and we already have the valid jump destinations computed in the <jumpDests>
cell), then do not consider the two states in looping relation.
<ehildenb> Not sure if the above makes sense, but this new heuristic:
def kevmShouldSubsume(constrainedTerm1, constrainedTerm2):
if all([getCell(constrainedTerm1, cn) == getCell(constrainedTerm2, cn) for cn in ['PC_CELL', 'K_CELL', 'CALLDATA_CELL', 'PROGRAM_CELL', 'JUMPDESTS_CELL']]):
jumpDests = [ i['args'][0] for i in flattenLabel('_Set_', getCell(constrainedTerm1, 'JUMPDESTS_CELL')) ]
(state1, _) = splitConfigAndConstraints(constrainedTerm1)
(state2, _) = splitConfigAndConstraints(constrainedTerm2)
stateDelta = pushDownRewrites(KRewrite(state1, state2))
rewrites = []
def _collectRewrites(_k):
if isKRewrite(_k) and isKToken(_k['lhs']) and isKToken(_k['rhs']):
rewrites.append((_k['lhs'], _k['rhs']))
return _k
traverseBottomUp(stateDelta, _collectRewrites)
return not any([(i != j) and (i in jumpDests) and (j in jumpDests) for (i, j) in rewrites])
return False
checks that:
<pc>
, <k>
, <callData>
, <program>
, and <jumpDests>
cells are identical (could probably also add <callDepth>
to this one)This correctly identifies the loop in this code:
function sum(uint n) external pure returns (uint s) {
s = 0;
uint i = n;
while (0 < i) {
s = s + i;
i = i - 1;
}
return s;
}
while correctly not identifying a loop in this code:
function twoAddress(address a1, address a2) public pure returns (uint256) {
if (a1 == a2) {
return 0;
}
return 1;
}
<ehildenb> I'm testing it out. In this example:
contract LoopInput {
uint x = 0;
function addLoop(uint256[] memory intArr) public {
uint256 tmpSum = 0;
uint256 i = 0;
for (i = 0; i < intArr.length; i++) {
tmpSum += intArr[i];
}
x = tmpSum;
}
}
It seems to correctly detect the loop, but loses too much information during loop abstraction and has messy control-flow afterward.
run_small.js
script from github and modifying it while building the image. I wanted to ask you if it was okay to include this file (via download or just the plain file) in the image repo
smtsolver.availableSolvers
to eldarica (or whichever solver you want) + modified settings