Michael Elizabeth Chastain became the maintainer of the Linux ioctl list in the early days because he wanted his mec-replay tool to be able to work, and ioctls were a fly in the ointment — each ioctl has its own idea of how to interpret the arguments, and may end up accessing user memory in some complicated way. Record-and-replay tools like mec-replay, rr, https://github.com/moyix/panda, and http://velvetpulse.com/2012/11/27/scribe-the-deterministic-t... need to be able to intercept that access in order to record the relevant data.
Edit: of course, I should have mentioned that doesn't apply to PANDA — by recording events at a non-system-call interface, PANDA avoids the problems of system-call emulation and instead has the problems of hardware emulation. I imagine PANDA will be a heck of a lot more useful for debugging new bare-metal operating systems. The publisher regrets the error.
Time-travel debugging and deterministic replay is such a fundamentally important feature, and it can expand our capabilities in many different ways that we're only starting to explore. Debugging is just one possible application; consider also exhaustive testing of error conditions, re-execution of optimistic transactions that hit a write conflict, temporal backtracking search over executions, data prevalence (though it doesn't solve the schema upgrade problem), and deterministic building. And remember that the hardest problem for reverse-mode automatic differentiation is figuring out how to "run the program backwards" in order to find the gradient of the output; deterministic replay strategies are directly applicable to this problem and therefore to generalized gradient descent.
Much to my surprise, you can still download mec-replay 0.3 from 1995, although you'd probably need to build a Linux 1.3 kernel to run it with: ftp://ftp.shout.net/pub/users/mec/misc/mec-0.3.tar.gz
Just wanted to point out that PANDA actually doesn't need to know anything about the semantics of system calls, including ioctl. It builds on a whole-system emulator, and the things it records are hardware events (interrupts, memory mapped I/O, DMA, etc.). This is why you can record/replay Windows or any version of Linux without having to explicitly add support for those OSes.
Unfortunately we haven't implemented the gdb reverse debugging commands yet, so it's not as useful for debugging as it could be. Hopefully soon.
Thank you Mozilla!!! As someone that programs in R. By making a it called rr R is now the second hardest to find stuff on Google. They really are going to hate looking for help when all the R searches come up.
I think the ones that use GDB will be able to take advantage of rr: Emacs, vim, maybe old versions of XCode. I don't think there are any Java IDEs that implement stepping backwards.
I'm wondering: if people run something like an unstable Fedora or Ubuntu distribution, could they have an option to automatically run rr for certain software?
11 comments
[ 5.0 ms ] story [ 35.2 ms ] threadEdit: of course, I should have mentioned that doesn't apply to PANDA — by recording events at a non-system-call interface, PANDA avoids the problems of system-call emulation and instead has the problems of hardware emulation. I imagine PANDA will be a heck of a lot more useful for debugging new bare-metal operating systems. The publisher regrets the error.
Time-travel debugging and deterministic replay is such a fundamentally important feature, and it can expand our capabilities in many different ways that we're only starting to explore. Debugging is just one possible application; consider also exhaustive testing of error conditions, re-execution of optimistic transactions that hit a write conflict, temporal backtracking search over executions, data prevalence (though it doesn't solve the schema upgrade problem), and deterministic building. And remember that the hardest problem for reverse-mode automatic differentiation is figuring out how to "run the program backwards" in order to find the gradient of the output; deterministic replay strategies are directly applicable to this problem and therefore to generalized gradient descent.
It's a shame that mec-replay fell by the wayside 20 years ago. Surely we won't let that happen this time. http://www.boutell.com/lsm/lsmbyid.cgi/001191 https://static.lwn.net/1999/0121/a/mec.html
Much to my surprise, you can still download mec-replay 0.3 from 1995, although you'd probably need to build a Linux 1.3 kernel to run it with: ftp://ftp.shout.net/pub/users/mec/misc/mec-0.3.tar.gz
Unfortunately we haven't implemented the gdb reverse debugging commands yet, so it's not as useful for debugging as it could be. Hopefully soon.
Just like searching google for go is pointless; instead one should search for golang