On Tue, 14 Feb 2006, Karthik Pattabiraman wrote:> I'm a PhD student at UIUC and I am using LLVM to add fault-tolerance
> capabilities to applications. I would like to evaluate my framework by
> performing fault-injections (fault-insertions) in the application.
> Essentially, I want to corrupt an LLVM value at the time of its definition
> and study the behavior of the program under this condition. I would like to
> be able to do this in a generic way without recompiling the program between
> injections (I will not know which value(s) I am going to fault-inject at
> compile-time).
ok
> I would like to know if similar tools/capabilities already exist for
> LLVM,
Not that I'm aware of.
> and if not, which of the following methods is easiest to implement
> and would give me what I need:
>
> 1. Extending the LLVM debugging interface to support modification of
> program variables: My understanding is that the current version of the
> debugging interface only allows inspecting a program's state and not
> modifying it.
Two things:
1. Support for debug info for variables is still being developed, even
reading isn't supported yet :). However, this is rapidly changing, and
support will be in soon.
2. Writing will still generally work, unless the variable gets optimized
out, in which case, there is nothing to write to.
However, I'm not sure why you want to do this in terms of source
variables.
> I don't know how difficult it would be to implement this
> modification, but it seems to be the most straightforward way to inject
> faults. However, I would be limited by the resolution of the debugging
> interface, and would be able to inject faults only to source-level
> variables.
Yes. It doesn't appear that you need to rely on debug information at all
for this purpose.
> 2. Changing the LLVM Interpreter to randomly corrupt data values when the
> bytecode instruction is executed. This would probably involve extensive
This isn't a good solution: unfortunately the LLVM interpreter is not
robust.
> 3. Adding a new intrinsic to perform fault-injections similar to how the
> current debugging intrinsics work: This would probably be the most
> efficient way to inject a fault and would also give me fine-grained
> control over where the fault is injected, but from what I've read about
> adding intrinsics, it also seems to be a lot of work. Or maybe I could
> somehow extend the current debugging intrinsics to also perform
> fault-injections ?
It depends on what you mean by "faults". You could also just sprinkle
the
code with calls to some function in a library that stomps on a random bit
of memory or something.
> Of course, I could simply perform fault-injections on the compiled
> binaries, but then I would not be able to map the data value I corrupted
> to its LLVM equivalent (or would I ?).
No, you wouldn't. At least not without far more debugging support than we
currently have.
> Also, this would not allow me to trace the propagation of the fault in a
> fine-grained fasion, which is essential for me to understanding its
> effects. What do people think of the above methods ? Or is there some
> simple way to do this using existing capabilities that I'm missing ?
I'd suggest just doing this based on LLVM values, using an LLVM-to-LLVM
transformation to insert the faults. For example, you could use something
like this:
llvm-gcc *.c -o program
opt program.bc -fault-inject -o - | llc > program.s
gcc program.s
./a.out
Repeating the last 3 lines as you want to change the faults injected.
By doing the transformation on the LLVM level, you can use SSA form of the
IR to trace the effects. I don't know anything about the fault injection
field or your goals, but maybe that would be sufficient for your purposes.
-Chris
--
http://nondot.org/sabre/
http://llvm.org/