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
rr – record and replay debugger for C/C++
61–70 of 134 posts
Re: rr – record and replay debugger for C/C++
#62Is 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?…
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.
Re: rr – record and replay debugger for C/C++
#63Earlier quoted context omitted.
> If a certain piece of software is working well, what is the benefit of rewriting it in Rust? Presumablly the idea here is to support Rust replay debugging, not just rewrite a C/C++ targetting replay debugger in Rust
I'm not so sure of this. Most code in a debugger doesn't have much to do with the source language. Line mapping and figuring out values for variables happens via symbol information, eg. DWARF, and compilers for multiple languages can produce that in the same format.
Does that neutral way of debugging work as well as having first-class explicit support for the language, or it's more of a lowest common denominator (kind of like what e.g. language support over LSP can offer and how conveniently, compared to what a native Lisp or Smalltalk environment's language support can offer)?
Re: rr – record and replay debugger for C/C++
#64Earlier quoted context omitted.
> If a certain piece of software is working well, what is the benefit of rewriting it in Rust? Presumablly the idea here is to support Rust replay debugging, not just rewrite a C/C++ targetting replay debugger in Rust
It works with pretty much any compiled language.
Does it understand the semantics, primitives, and structures of any compiled language?
Or is it more of a lowest common denominator experience, where e.g. all of them are constrained to common semantics of C/C++?
Re: rr – record and replay debugger for C/C++
#65On 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-...
Re: rr – record and replay debugger for C/C++
#66On 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-...
WinDbg uses a instruction-level emulation time travel implementation, so incurs the 10-20x slowdown associated with that technique. rr uses a replay-record time travel debugging implementation, which can incur far less overhead when done correctly. Last I saw, rr has overhead in the 2x slowdown range and, if I remember correctly, I have seen a different record-replay time travel debugger in the 10% range.
10% is 100x cheaper than WinDbg and cheap enough to leave on all the time in production. That is a game-changer.
Re: rr – record and replay debugger for C/C++
#67Earlier quoted context omitted.
I'm not so sure of this. Most code in a debugger doesn't have much to do with the source language. Line mapping and figuring out values for variables happens via symbol information, eg. DWARF, and compilers for multiple languages can produce that in the same format.
Does that neutral way of debugging work as well as having first-class explicit support for the language, or it's more of a lowest common denominator (kind of like what e.g. language support over LSP can offer and how conveniently, compared to what a native Lisp or Smalltalk environment's language support can offer)?
One debugger feature I thought of while writing the comment was the ?? command in windbg. That takes an expression and evaluates it. Gdb also does this which I've used with the "print" command to print a C expression, including pointer casts and such. That would obviously require language support.
But then again you don't need to code everything in the same language either. You could write a rust parser in another language. Or a modular interface to dispatch knowledge of a programming language (does Microsoft's "language server" concept work this way?)
Re: rr – record and replay debugger for C/C++
#68Earlier quoted context omitted.
It works with pretty much any compiled language.
Does it understand the semantics, primitives, and structures of any compiled language? Or is it more of a lowest common denominator experience, where e.g. all of them are constrained to common semantics of C/C++?
That's up to debuggers to implement. lldb, gdb, and delve all support rr traces.
Re: rr – record and replay debugger for C/C++
#69Earlier quoted context omitted.
> There's a bit of a higher abstraction ceiling in Rust Compared to C, yes, but not compared to C++.
This isn't really true. Rust has a much better type system. When writing generic code the impact is enormous. C++ doesn't have a real Empty Type, and it thinks Units have non-zero size. In practical terms this makes it incredibly wasteful and in terms of a clear abstraction it encourages you to come up with a hack that's unclear but efficient.
Do you have a link to an example where this matters?
Re: rr – record and replay debugger for C/C++
#70Is 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
Goland uses delve which has rr support