KULFI does not support C++

[vcsharma]

KULFI beta version does not support C++

[quadpixels]

One piece of clue: On lines around 398 of faults.cpp, the program iterates over a list of function names and does string comparisons.
However C++ compiler would mangle function names, therefore all functions inside Corrupt.c need to be wrapped with "extern C" when compiling with clang++.
This is only a part of the problem... because the injector complains about invalid calling convention. Do you know how to show line numbers in opt's core dump?

[zvonimir]

Good observation.
Did you compile both LLVM and KULFI in Debug mode?
I think that might help... Otherwise, you should resort to logging.

[quadpixels]

I'm already building LLVM and KULFI in debug+assert mode; it down't show line numbers still.

[quadpixels]

I may have found some way to reproduce the bug ----- it actually has nothing to do with C or C++; it may be related to the return type of a CallInst that needs to be injected error!

To reproduce the problem on bubblesort, do the following:

1. rm *.bc
2. add a function whose return type is neither void or int and call it somewhere, for example

int** fancy() { return (int**)0xBAADCAFE; }
...
(at the beginning of main())
unsigned int asize = (int)fancy();

3. python kulfi.py bubblesort 100 99 0 0 1 1

And you will see the exact same error.

The error are generated in faults.cpp, lines 313, 323, 334, 344, when generating pointer errors (the same may happen to data register errors) where a Call Inst is created (if I understand correctly, the return value of some function is passed to corrupt_*() and modified, and LLVM has a strict requirement that all argument types must agree, even if they are convertible to each other. When it's neither int or void LLVM complains arguments of incompatible type.)

So I guess to remove the bug, it may be possible to add 1 instruction before the CallInst() and convert the return value to an int*...

[vcsharma]

thanks Sui for the debug data.. I would start working on this issue around Monday...this would be helpful then..

[quadpixels]

I've made the following changes to the code to make LLVM happy:
In InjectError_PtrError, case "store instructions" and "load instructions"

I've added code that

1. Converts the 1st(2nd) operand of the load(store) instruction to Int64
2. Performs bit masking on that Int64
3. Converts back to the original pointer type

I suddenly realized I am using LLVM 3.3 and it complains errors (argument of incompatible type) when I am attempting to inject errors into pointers, not sure if using LLVM 3.2 would have the same issue.
After adding these codes I see pointer corruptions working with BubbleSort (core dumps from system or from glibc and segfaults)

Also, the same error is seen on Function Call instructions. Maybe do the same thing to Function Call instructions ?

[vcsharma]

You may want to check with LLVM3.2 + the latest changes that I pushed just now. The latest changes fixes all the open issues/enhancement except this one(C++ support). Adding "C++ support" is WIP and will update once fixed.

[quadpixels]

I have identified something that may need to be handled to make Dynamic Fault Injection work with more (preferably C++) code:

1. Instructions can be of type "int1" (i.e. a Boolean)
2. Instructions can be of type Pointer.
3. Instructions can be of type Struct. That is, it's not a primitive type.

These should be the cases we have to add to function InjectError_DataReg_Dyn