[flagged]
I've used it for years for vulnerability development (when you need to debug why a particular exploitation run went wrong etc.).
It is indeed marvelous for many situations; except for concurrency bugs ;)
rr – record and replay debugger for C/C++
11–20 of 134 posts
Re: rr – record and replay debugger for C/C++
#12Perhaps 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. https://github.com/sidkshatriya/rd/
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?
>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
Re: rr – record and replay debugger for C/C++
#13Perhaps 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. https://github.com/sidkshatriya/rd/
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?
>If a certain piece of software is working well, what is the benefit of rewriting it in Rust?
The "working" C program has a high risk of undiscovered bugs relating to concurrency and memory safety. Rust lets you rule out a large swathe of them by construction. Rust's type system is also far more expressive, which in many cases enables cleaner domain modelling.
Re: rr – record and replay debugger for C/C++
#14[flagged]
I've used it for years for vulnerability development (when you need to debug why a particular exploitation run went wrong etc.). It is indeed marvelous for many situations; except for concurrency bugs ;)
Why isn't it good for concurrency bugs? rr doesn't record the entire state up to the race condition?
Re: rr – record and replay debugger for C/C++
#15rr 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!
Chaos mode is an option when invoking rr that can expose some concurrency issues. Basically it switches which thread is executing a bunch to try and simulate multiple cores executing. It has found some race conditions for me but it’s of course limited
Unfortunately that only works for large-scale races, and not, say, one instruction interleaving with another one on another thread without proper synchronization. -fsanitize=thread probably works for that though (and of course you could then combine said sanitizer with rr to some effect probably).
Re: rr – record and replay debugger for C/C++
#16[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 responsible for creating this DAG node?’ and such.
Really powerful tooling — I haven’t kept up with it for a while, but last I checked it didn’t work on aarch64/arm64 because of a lack of certain performance counters only available on x86 hardware. The lack of support for other languages (e.g. Go) is also a shame. This has unfortunately rendered it unviable for my day job!
If you’re working in a stack where it’s supported, it’s really quite special.
Re: rr – record and replay debugger for C/C++
#17Perhaps 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. https://github.com/sidkshatriya/rd/
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?
Recently the federal government issued a security advisory encouraging all new development to be done in Rust. I'm not sure the extent of which agencies this was meant to cover but it struck me as very unrealistic having just done years of java development for a state agency.
https://www.nextgov.com/cybersecurity/2024/02/white-house-ur...
Re: rr – record and replay debugger for C/C++
#18Earlier quoted context omitted.
I've used it for years for vulnerability development (when you need to debug why a particular exploitation run went wrong etc.). It is indeed marvelous for many situations; except for concurrency bugs ;)
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
Re: rr – record and replay debugger for C/C++
#19[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…
I believe rr should support other languages exactly as well as gdb does; I've looked at some Rust in it once or twice at least, and IIRC even some Go; though I'm happy enough with doing assembly-level breakpoints/whatnot so I can't comment on more fancy things. Even some OpenJDK JIT! (though there of course source-mapping/stacktraces are non-existent, never mind reading variables, but even then I managed to hack together some basic source-mapping at https://github.com/dzaima/grr#java-jit; though it's rather unusable with rr due to OpenJDK's machine code dumping going directly to stdout, and general slowness).
That said, it would be very neat to have a more complete standard debugging interface across ahead-of-time-compiled code, interpreters, and JITs.
And it does have some aarch64 support by now, though it'll still require a suitable CPU with necessary perf counters.
Re: rr – record and replay debugger for C/C++
#20Perhaps 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. https://github.com/sidkshatriya/rd/
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...