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

51–60 of 134 posts

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

#51

Post by [deleted] »

77pt77 wrote: post #48
johnwatson11218 wrote: post #17

Earlier quoted context omitted.

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

> the federal government issued a security advisory Well, I guess that's it... Maybe rust will take the same path as Ada.

[deleted]

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

#52

Post by jvanderbot »

_dain_ wrote: post #13
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?

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

You're correct that this is the stated justification most of the time.

Should be nuanced though, because the working C program has a risk, but the the risk is a function of the size of the codebase, its age, and the number of audits it has undergone.

It is definitely easier to write bugs in C due to the additional freedom you have, but it is not necessarily a "high" risk for mature C libraries.

It is definitely not as advisable to just replace all C with Rust, but it is advisable to prefer memory safety in new projects.

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

#53

Post by dzaima »

adgjlsfhk1 wrote: post #47
dzaima wrote: post #19

Earlier quoted context omitted.

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

I do know that RR works for Julia. Not sure why it wouldn't work for Go.

Julia goes through LLVM, which has good DWARF support (and, additionally, until recently, Julia hosted rr's CI, so Julia directly cares about rr). Whereas AFAIU Go does its codegen fully from scratch, without much regard for gdb/DWARF quality.

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

#54

Post by khuey »

suby wrote: post #6

Perhaps 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/

From the perspective of an rr maintainer, Sid's work was good and we were supportive of it. The main issues with migrating to that as the "blessed" version are that 1) rr has accumulated a decade of very hairy fixes for crazy kernel/process behavior that we feared could be lost during a port and 2) there's a closed source project (remix[0]) built on top of rr that would have needed to be ported too.

[0] https://robert.ocallahan.org/2020/12/rr-remix-efficient-repl...

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

#55

Post by bqmjjx0kac »

dzaima wrote: post #15
borodi wrote: post #10

Earlier quoted context omitted.

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

Yeah, the reason it only works for these coarser race conditions is that RR only has one thread executing at a time. Chaos mode randomizes the durations of time allotted to each thread before it is preempted. This may be out of date. I believe I read it in the Extended Technical Report from 2017: https://arxiv.org/pdf/1705.05937

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

#56

Post by nemetroid »

i_am_a_peasant wrote: post #14
tdullien wrote: post #11

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

RR supports recording multithreaded programs, but only runs one thread at a time, so it cannot trigger data race bugs.

It can find higher level concurrency bugs though, and has a "chaos mode" that schedules threads in an unfair random manner.

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

#57

Post by saagarjha »

tialaramex wrote: post #49
nsajko wrote: post #46

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

…or you can just waste a few bytes? It's not a big deal.

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

#58

Post by polio »

saagarjha wrote: post #57
tialaramex wrote: post #49

Earlier quoted context omitted.

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.

…or you can just waste a few bytes? It's not a big deal.

You can, but that makes the type system worse. Also depending on how these few bytes are used, they can add up and drag down performance.

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

#59

Post by saagarjha »

polio wrote: post #58
saagarjha wrote: post #57

Earlier quoted context omitted.

…or you can just waste a few bytes? It's not a big deal.

You can, but that makes the type system worse. Also depending on how these few bytes are used, they can add up and drag down performance.

No, my point is that it doesn't. If your zero-sized types are big your type system is not any worse: it's just less efficient.

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

#60

Post by vinnyvichy »

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

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

Post reply on HN