Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

rr – record and replay debugger for C/C++

rr-project.org

Post reply on HN
Print view View original

31–40 of 134 posts

Re: rr – record and replay debugger for C/C++

#31

Post by laserbeam »

dzaima wrote: post #27
laserbeam wrote: post #23

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?…

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.

Re: rr – record and replay debugger for C/C++

#32

Post by leni536 »

nsjolj wrote: post #3

[flagged]

rr is awesome. My typical debug workflow:

  * rr record
  * rr replay until crash or exception (set up catchpoint for that)
  * set up hardware watchpoint for borked data that caused the issue
  * work backwards in the data flow through watchpoints and reverse-continue
I would say this fundamentally changed how I approach debugging.

Re: rr – record and replay debugger for C/C++

#33

Post by vaughnegut »

laserbeam wrote: post #23

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?…

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

Re: rr – record and replay debugger for C/C++

#34

Post by Thaxll »

joechrisellis wrote: post #16
nsjolj wrote: post #3

[flagged]

My previous job was in compiler engineering and I worked on upstream LLVM for a little while. rr was indispensable for me — not just for debugging, but as a tool for understanding how the compiler works in general. For example: you can set a watchpoint on an object in memory, and reverse-execute to the point where it was instantiated. This allowed you to answer questions such as ‘which optimisation pass was responsib…

It says on https://rr-project.org/ that it supports Go programm, what's the status?

Re: rr – record and replay debugger for C/C++

#35

Post by mgaunard »

Agingcoder wrote: post #25
nsjolj wrote: post #3

[flagged]

You might be interested in the rather spectacular upgrade to it, called pernosco : https://pernos.co/ It’s based on rr ( same author ) but vastly better

There are other commercial reverse debuggers, like Undo.

Re: rr – record and replay debugger for C/C++

#36

Post by db48x »

mgaunard wrote: post #35
Agingcoder wrote: post #25

Earlier quoted context omitted.

You might be interested in the rather spectacular upgrade to it, called pernosco : https://pernos.co/ It’s based on rr ( same author ) but vastly better

There are other commercial reverse debuggers, like Undo.

Pernosco is more than merely a reverse debugger.

Re: rr – record and replay debugger for C/C++

#37

Post by pm215 »

adgjlsfhk1 wrote: post #18
i_am_a_peasant wrote: post #14

Earlier quoted context omitted.

Why isn't it good for concurrency bugs? rr doesn't record the entire state up to the race condition?

it serializes your problem because you can't atomically snapshot memory when there are multiple threads writing to it

This is true, but for at least some race conditions the rr "chaos mode" can help in tracking them down. Chaos mode basically randomly adjusts its thread scheduling so that it sometimes doesn't run a thread at all for a few seconds, so you run it a bunch of times until it hits the timing window for the race condition; and then when it does you debug the recording. IME it works at least sometimes but it does require that the thing you're testing doesn't take too long to fall over, since you need to do multiple recordings of it.

https://robert.ocallahan.org/2016/02/introducing-rr-chaos-mo...

Re: rr – record and replay debugger for C/C++

#38

Post by db48x »

laserbeam wrote: post #31
dzaima wrote: post #27

Earlier quoted context omitted.

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.

Re: rr – record and replay debugger for C/C++

#39

Post by Xeamek »

laserbeam wrote: post #31
dzaima wrote: post #27

Earlier quoted context omitted.

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.

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'?

Re: rr – record and replay debugger for C/C++

#40

Post by taneq »

rtpg wrote: post #20
tarruda wrote: post #9

Earlier quoted context omitted.

I don't understand the "rewrite X/Y/Z in Rust" trend that has been going for a few years. I'm not familiar with Rust, but I'm almost sure it has a good C interoperability. If a certain piece of software is working well, what is the benefit of rewriting it in Rust?

There's a bit of a higher abstraction ceiling in Rust so in theory if you are successful rewriting a thing in Rust then you now have a codebase that's easier to change confidently. This sort of property is nice to have in huge codebases where you really start losing confidence in shipping changes that don't subtly break things. But of course a huge codebase is hard to rewrite in general...

Sounds like a perfect situation for a strangler pattern? Wrap or transpile the original code into a language with stronger refactoring support and the rest should become incrementally easier.
Post reply on HN