Hacker News Reader

Comment by laserbeam | Hacker News Reader

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.

View on HN

I use it with Zig. It's pretty handy in conjunction with Zig's allocator because it writes 0xaa bytes upon free and doesn't reuse addresses, so it very likely causes a crash, then you can put a watchpoint on the memory and rewind to the point where it got freed.

That sounds really neat, is there more information on this?

*Edit

Found this, https://zig.news/david_vanderson/using-rr-to-quickly-debug-m...

I've gotten rr to work with very specific builds of rpython before but you might be surprised at the ongoing interest:

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...

We use RR a lot with Julia. It only gives you a GDB view of the system, but it can work with any interpreted or compiled language.

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.

Shameless plug: https://undo.io does everything rr can but can also work with drivers that update the process memory (or unrecorded processes or even hardware). If you need that kind of advanced usage, check it out.

(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 :)

rr uses gdb as the actual debugger part, so anything that works in gdb will work in rr. (you won't get rr running on windows though, as it is very much linux-specific, having to wrap all of its syscalls. The linux symbol info thing is DWARF)

Ok yeah, of course. I'd even argue that cross platform debuggers are not a thing to be desired. Too much low level integration with the operating system is needed when implementing one.

I disagree. You shouldn’t have to learn two debuggers just because you occasionally have to use a different OS. GDB has the right architecture here; the actual debugging operations are implemented by a gdbserver, and gdb is only the user interface that lets the user tell the server what to do. When you’re debugging on a different platform you use use a different gdbserver and keep using the same user interface that you are familiar with.

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.

Why? From the user's pov, what 'low level integration with an OS' is there that couldn't/shouldn't be abstracted into 'generic debugging functionalities'?

I did use gdb recently on Windows, but this was for a cross compiled program using mingw. Not sure it works for programs made with MSVC.

People use it for rust: https://bitshifter.github.io/rr+rust/index.html#1

Interestingly gdb (and in turn rr) has some limited support for debugging python. At least you can get a python backtrace, but I didn't have success in setting pyhton breakpoints.

Yeah, 'cause you're technically debugging the python interpreter. I've had some success with tracing tools designed for C/C++ for a python project. Was not easy to set up and will obviously include frames from the interpreter.

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.

https://undo.io/resources/how-i-debug-python-code-with-a-tim...

"How I debug Python code with a Time Travel Debugger"

Works surprisingly well.

Yes, it can generally debug any language that compiles to a binary with proper debug information.

It also works with Go, I think support for it is built into Goland too

Goland uses delve which has rr support

for js, there's http://replay.io

Reply on news.ycombinator.com