Perhaps worth mentioning is that someone attempted to port this to Rust and got about 60,000 lines of code into it before archiving the project. I feel like comparing these two efforts would be an interesting case study on the impacts / benefits / limitations or difficulties, etc involved in rewriting from C++ to Rust.
Is it truly only for C/C++?
My limited understanding says a debugger needs: a list of symbols (.pdb files on windows, can't remember what they are on linux), understanding of syscalls and a few other similar things. I thought they don't care too much what generated the binaries they are debugging (obviously as long as it's native code).
Doesn't rr work with other languages like rust, zig, odin, nim, and similar ones? Obviously, I wouldn't expect it to work for python, js, c# and other languages with managed memory.
rr is really cool, but almost every time I have decided to pull it out as one of the "big guns" it turns out that I have a concurrency bug and so rr is unable to reproduce it.
Despite that, it would be very, very, very cool if some languages built rr directly into their tooling. Obviously you can always "just" use rr/gdb, but imagine if rr invocations were as easy to set up and do as pdb is in Python!
See also https://pernos.co/ which is based on rr but adds a queryable database of the whole program execution, which allows you to do things like this:
> [...] just click on the incorrect value. With full program history Pernosco can immediately explain where this value came from. The value is tracked backwards through events such as memcpys or moves in and out of registers until we reach a point where the value "originated" from, and each step in this process is displayed in the "Dataflow" panel that opens automatically. There is no need to read or understand the code and think about what might have happened, we can simply ask the debugger what did happen.
GDBs built-in reverse debugging: https://www.sourceware.org/gdb/wiki/ProcessRecord/Tutorial
I assume rr provides more features and flexibility. Anyway I want to mention that GDB itself can already reverse debug for some time now.
On Windows you can use WinDbg for the same thing. It has better support for debugging multi-threaded issues.
https://www.forrestthewoods.com/blog/windbg-time-travelling-...
Long ago, VMWare workstation supported doing this, but not just for userspace programs but also for kernels and even drivers, in a VM. The feature shipped and existed for a few versions before it was killed by internal politics.
Are rr’s problems with Ryzen CPUs now firmly in the past or not?
A couple of previous discussions:
https://news.ycombinator.com/item?id=31617600 (June 2022)
I used this to help make my toy JIT compiler: https://github.com/danthedaniel/BF-JIT
Super useful, especially considering I know barely anything about x86-64.
I almost use rr every day, along with a gdb frontend: cgdb.
rr record /tmp/Debug/bin/llvm-mc a.s && rr replay -d cgdb
I've have success story with some bugs only reproducible with LTO. Without rr it would be a significant challenge.
It would be nice if Linux kernel could be debugged with rr. Does anyone have success with kernel under rr+qemu ? :)
[off-topic] does anyone here who regularly uses a debugger (even just breakpoints and watchers in their IDE) use it for async execution? I've never tried, but I'm just trying to think how all that jumping around the executor and any runtime would work (if at all).
Is it possible to use this with C/C++ code compiled to dll/so and called by Python?
Curious if anyone tried rr for/on Android? It seems possible to crosscompile it and it could be a good tool for native side debugging
Has anyone gotten rr to work with opengl or vulkan? It seems to always crash for me after making an opengl call.
Can someone explain how it works?
I've used rr very sucessfully for reverse engineering a large code base using a break on variable change combined with reverse-continue. Took the time to extract critical logic way down.