Tho, it feels wrong to expect a tool designed for native binaries to work well with python in this context. And that's ok. It feels lucky when it works as much as it does.
"How I debug Python code with a Time Travel Debugger"
Works surprisingly well.
When you replay a recording, rr first starts its custom gdbserver (which reads from the recording instead of from a live process) then starts a gdb process that connects to it.
https://github.com/python/devguide/issues/1283
https://morepypy.blogspot.com/2016/07/reverse-debugging-for-...
https://github.com/mesalock-linux/mesapy/blob/mesapy2.7/READ...
Things that don't work are drivers that update mapped addresses directly. An example of this is CUDA in order to replay one would need to model the driver interactions (and that's even before you get to UVM)
Another great thing is that RR records the process tree and so you can easily look at different processes spawned by your executable.
(Unlike rr it's not open source though - sorry! We have lots of programmes working on it full time and they insist on getting paid every month :)
*Edit
Found this, https://zig.news/david_vanderson/using-rr-to-quickly-debug-m...
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.