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
int variadic_foo(int count, ...) {
va_list args;
int i;
va_start(args, count);
int sum = 0;
for (i = 0; i < count; i++)
sum += va_arg(args, int);
va_end(args);
return (int)sum;
}
SymCC will not propagate symbolic expressions on arguments obtained through va_arg. Hence, SymCC will not, e.g., flip a branch that depends on the return value of variadic_function.
In SymFusion, we handle this by reverse engineering va_list, whose implementation is architecture specific: see, e.g., Section 3.34 in the AMD64 ABI. In particular, SymFusion instruments intrinsic va_start, adding a helper that "moves" at running time the symbolic expression for the i-th argument into the memory area where the program will read the i-th argument using va_arg (which is a C macro... hence, it is not an intrinsic). In SymFusion, we explicitly have information about the number of arguments and their types (integer vs floating point), making the implementation of this helper easier.
How do you think we should handle this in SymCC?
The text was updated successfully, but these errors were encountered:
Consider this function:
SymCC will not propagate symbolic expressions on arguments obtained through
va_arg
. Hence, SymCC will not, e.g., flip a branch that depends on the return value ofvariadic_function
.In SymFusion, we handle this by reverse engineering
va_list
, whose implementation is architecture specific: see, e.g., Section 3.34 in the AMD64 ABI. In particular, SymFusion instruments intrinsicva_start
, adding a helper that "moves" at running time the symbolic expression for the i-th argument into the memory area where the program will read the i-th argument usingva_arg
(which is a C macro... hence, it is not an intrinsic). In SymFusion, we explicitly have information about the number of arguments and their types (integer vs floating point), making the implementation of this helper easier.How do you think we should handle this in SymCC?
The text was updated successfully, but these errors were encountered: