Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support error-injection simulation #41

4 tasks
sampsyo opened this issue Aug 31, 2015 · 0 comments
4 tasks

Support error-injection simulation #41

sampsyo opened this issue Aug 31, 2015 · 0 comments


Copy link

sampsyo commented Aug 31, 2015

I'm merging in the ACCEPT bits of the REACT compiler work. This just consists of the instruction-level error injection LLVM pass. ACCEPT needs a few more pieces before it's useful off-the-shelf for error injection experiments.

  • Document liberror. We need to add documentation for the error-injection interface. We should also package up our current error-injector implementations for reuse (in a separate repository? in the master branch of accept-apps?).
  • liberror convenience. The error-injection hooks currently need to be compiled along with the application source code. This is currently handled in accept-apps by requiring the user to cp ../liberror/* . before compiling the code. We should make this easier by building the error-injection library to LLVM bytecode separately, as we do for the acceptrt library, and linking it in.
  • Error parameters in driver. The driver currently doesn't know how to use the instruction sites produces by the error injector. It should be able to use some kind of user-supplied specification of the parameter space. For example, our liberror uses a packed pair consisting of a 16-bit "model" id and another 16-bit parameter, whose meaning depends on the model. This specification should come hand-in-hand with the liberror implementation.
  • Simulated performance. The --simulate flag to the driver is a good start for disabling the performance-sensitive parts of ACCEPT (which are irrelevant when doing injection). But we also need to pick up a performance number produced by some arbitrary RUNSHIM, e.g., an architectural simulator or a Pintool.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

1 participant