You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recently, when I ran symcc on the following program, trying to explore the two paths given the input g_617 = 32, symcc cannot successfully finds the case where if condition is false, and always fall into the case where if condition is true.
I have investigated the reason. The Intel processor masks the shift count to 5 bits to make sure that the shift left count is at most 31. Therefore, the if condition will be false only when g_617 mod 32 = 31. If we provide initial input g_617 = 32, symcc will capture the result of if condition is true and trying to solve the following constraint to make the if condition be false.
This constraint uses bvshl to perform shift left operation that corresponds to the if condition. However, when g_617 > 31, bvshl will compute the result as 0 (without mod 32 operation), which will satisfy the above constraint. In that case, symcc will generate an new input g_617 = 0x4001, which in fact, let the if the condition still be true in concrete execution.
The reason is the inconsistent handling for left shift overflow between shl opcode in machine code and bvshl in smt constraint. I'm wondering if symcc has been aware of such difference so that it can add an extra mod 32 operation for the left shift when collecting constraints.
This shift left overflow handling problem also exists in the qsym backend, and the generated constraints is shown as below:
Dear developers,
Recently, when I ran symcc on the following program, trying to explore the two paths given the input
g_617 = 32
, symcc cannot successfully finds the case where if condition is false, and always fall into the case where if condition is true.I have investigated the reason. The Intel processor masks the shift count to 5 bits to make sure that the shift left count is at most 31. Therefore, the if condition will be false only when
g_617 mod 32 = 31
. If we provide initial inputg_617 = 32
, symcc will capture the result of if condition is true and trying to solve the following constraint to make the if condition be false.This constraint uses
bvshl
to perform shift left operation that corresponds to the if condition. However, wheng_617 > 31
,bvshl
will compute the result as0
(withoutmod 32
operation), which will satisfy the above constraint. In that case, symcc will generate an new inputg_617 = 0x4001
, which in fact, let the if the condition still be true in concrete execution.The reason is the inconsistent handling for left shift overflow between
shl
opcode in machine code andbvshl
in smt constraint. I'm wondering if symcc has been aware of such difference so that it can add an extramod 32
operation for the left shift when collecting constraints.This shift left overflow handling problem also exists in the qsym backend, and the generated constraints is shown as below:
Thank you.
The text was updated successfully, but these errors were encountered: