5 ms·

55,000 lines of Rust code later: A debugger is born

86 points by ibraheemdev 5y ago

deleted 5y ago
[deleted]
jeff-davis 5y ago
Is the goal to replace rr or coexist somehow?
- khuey 5y ago
  In the short to medium term they will coexist.
- edflsafoiewq 5y ago
  The intent appears to be to replace. > However, does that mean that like LLVM we are forever stuck with C/C++ for a foundational piece of debugging software like rr? > No. The rd port of rr to Rust is my attempt to change that inevitability
  - forgotpwd16 5y ago
    Another day, another Rewrite it in Rust.
v8dev123 5y ago
What's with the people who still use the term C/C++? C++ and C are separate languages. I'd be grateful for the author to reflect it in the Readme. Further, Bragging about LoC is bad. LoC is a poor measure of both quality and functionality. "C/C++ - a mythical language referred to by people who cannot or do not want to recognize the magnitude of differences between the facilities offered by C and C++" -- Stroustrup
- fioawjpoifajio 5y ago
  Concretely, rr uses both C and C++, so the term is perfectly valid, given that the two languages interoperate just fine.
- smoldesu 5y ago
  > C++ and C are separate languages. I'd be grateful for the author to reflect it in the Readme. I agree, but we could honestly be as granular as we want here. We could ask the author to delineate between C99 and C11, but it ultimately doesn't really matter. The point of referring to "C/C++" is to cast a blanket statement over the traditional compiled mainstays and use them as a point of reference. While they are indeed different, they're more alike then they are dissimilar. I think the author is perfectly justified here. > Further, Bragging about LoC is bad. LoC is a poor measure of both quality and functionality. Rust is a language that is extremely verbose, and properly formatted Rust code often uses more lines than necessary to improve readability (expanding match arms, removing inlined if-statements, etc.). Hell, if you look at the repo, it looks almost identical to a default Rust project: src is clearly exposed at the root, and everything else is pretty well organized into distinct folders. I disagree with the first part of your statement ("Bragging about LoC is bad") but agree with the second part ("LoC is a poor measure of both quality and functionality.") Honestly, I think LoC-shaming originated in languages like Java and Python, where more lines of code almost guaranteed more complexity. Rust's focus on zero cost abstraction ultimately means that even massive programs can run with minimal overhead. I'm not here to parade Rust's achievements in front of you, but I figured it was worth pointing out at least here.
  - lmilcin 5y ago
    > Honestly, I think LoC-shaming originated in languages like Java and Python, where more lines of code almost guaranteed more complexity. Rust's focus on zero cost abstraction ultimately means that even massive programs can run with minimal overhead. Zero-cost abstractions are meant to be zero physical cost, not zero mental cost. LoC still translate to mental overhead and "LoC shaming" is appropriate for any language, not just verbose like Java or Python.
    - v8dev123 5y ago
      C++ also happen to use the term zero-cost abstractions along with RAII since 2011 but Chandler Carruth “There Are No Zero-cost Abstractions” You can watch and see what they really are. I bet this is true for Rust as-well.
- lmilcin 5y ago
  > Further, Bragging about LoC is bad. LoC is a poor measure of both quality and functionality. It is not a measure of quality but rather size of the project.
  - SquibblesRedux 5y ago
    It's not the size of the project, it's how you use it.
  - baby 5y ago
    Was he bragging about it? I think it was more about the amount of work accomplished. It’s not a 1k LOC project.
- jeff-davis 5y ago
  There aren't many pairs of mainstream languages that really interoperate well together. C and C++ do, which can blur the lines a bit. Not sure if this is what the author meant. With rust growing in popularity and good interoperability, I suspect we'll see the rise of projects written in C/Rust and C++/Rust, and maybe even C/C++/Rust. The line will obviously be more clear because of dramatically different syntax, packaging, build system, etc.
  - v8dev123 5y ago
    My issue was "/" and I'd be fine if he had used "C, C++" or "C & C++"
    - jeff-davis 5y ago
      Does "/" have a concrete meaning? I vaguely think it means "with" or "and" or "or", but it seems more ambiguous.
      - v8dev123 5y ago
        It's ambiguous and not clear to reader!
Scuds 5y ago
> In my opinion, debuggers are under-appreciated and under-invested tools in a programmer's arsenal. Oh yeah - microsoft's time travelling debugger is under appreciated, even with their quality tooling. But, it's on the windows platform. So anything like this on Linux sounds like a very positive step forward.
- flukus 5y ago
  > So anything like this on Linux sounds like a very positive step forward. GDB has had reverse debugging since 2009 and there are other tools like rr and a few commercial ones. If anything I'd say that you calling it time travel debugging instead of reverse debugging demonstrates how insular the windows developer world is more than the windows platform being ignored. A great demonstration is in the video "Give Me 15 minutes and I'll change your view of GDB": https://www.youtube.com/watch?v=PorfLSr3DDI https://www.youtube.com/watch?v=PorfLSr3DDI
  - Veserv 5y ago
    Time travel debugging is actually the more common historical term for the technology along with replay debugging specifically for the record-replay based variants. Reverse debugging as a term is really more of a GDB-ism and even there the term only really started gaining steam when rr produced a reasonable backend with GDB reverse debugging commands as a front-end. Also, frankly, the original GDB reverse debugging backend was entirely non-viable since it resulted in something like a 10,000x slowdown [2] during execution which made it essentially useless for anything other than actual toy problems. This is entirely an artifact of the implementation rather than any technology reason as most of the early solutions listed in [1] were somewhere between no slowdown for hardware-based solutions and 2x-100x for software based solutions. [1] http://jakob.engbloms.se/archives/1564 http://jakob.engbloms.se/archives/1564 [2] https://undo.io/resources/6-things-time-travel-debugging/ https://undo.io/resources/6-things-time-travel-debugging/
- paxys 5y ago
  Completely agree. At my current job I spent a lot of time in improving the developer tooling - step through debugging, live REPL, tracing, waterfalls, profiling, memory dumps. People are still not willing to spend the time to learn them and improve their workflows unless literally forced to do so. The prevalent attitude is simply laziness manifested as "why do I need all these fancy tools when print('I am here!') works just fine?"
jeff-davis 5y ago
From one of the linked pages: "Lack of garbage collection was a problem but runtimes are more troublesome...Linux signal handling becomes very complicated...Runtimes also often force layout of data structures be tuned to the needs of the garbage collector..." https://github.com/sidkshatriya/me/blob/master/002-why-rust.md#lack-of-garbage-collection-was-a-problem-but-runtimes-are-more-troublesome https://github.com/sidkshatriya/me/blob/master/002-why-rust.... That sums up my experience using a lot of higher-level languages. The pitch is always that language X should replace C because it's just as fast in most practical cases but much easier and safer. But the reason I use C is because of the pain of complex runtimes, especially when interoperating with other languages. And that's also why I'm interested in Rust. It's the first high-level language (I use the term loosely) that doesn't interfere with anything you're trying to do. It can even do dynamic dispatch on ordinary pointers to structures with a C memory layout, because it doesn't add a vtable pointer to structs (like C++ does). "I don't know much about dlang -- it could have been the best of both worlds" Yeah, I skipped over dlang, too. And I don't have a good reason for that, aside from a lack of time to really explore both. I hope dlang keeps growing and eventually I'll look into what it has to offer.
- v8dev123 5y ago
  Also, "Lack of Object-Orientation was a concern" Whenever you port a big program to another language it is important to be conservative, in my view. You don't want to make so many structural changes in the way things work in the original codebase while porting things over. You risk things becoming very confusing and the port could fail. In future iterations you could definitely make things more idiomatic in the target language. As far as Rust is concerned, it does not have traditional OO features. But by using the Deref/DerefMut trait specifically and traits in general I was able to recover and mimic a lot of OO behaviors present in rr in rd. The rd code may not always be beautiful. FYI, Rust had a GC also Classes in it's initial versions but they were removed for some reason!!!
  - jeff-davis 5y ago
    "Whenever you port a big program to another language it is important to be conservative, in my view." Either be very conservative or just tear things up. I think the middle ground is the worst, where you can't decide whether it's a rewrite or a port.
milani 5y ago
From the blog "Just like llvm facilitated the rise of hundreds of new computer languages, I forsee a similar rise for debugging and debuggers in the coming years." But the author provides no evidence to support the claim. Why would the status quo change?

86 points by ibraheemdev 5y ago

deleted 5y ago

[deleted]

jeff-davis 5y ago

Is the goal to replace rr or coexist somehow?

khuey 5y ago
In the short to medium term they will coexist.
edflsafoiewq 5y ago
The intent appears to be to replace. > However, does that mean that like LLVM we are forever stuck with C/C++ for a foundational piece of debugging software like rr? > No. The rd port of rr to Rust is my attempt to change that inevitability
- forgotpwd16 5y ago
  Another day, another Rewrite it in Rust.

v8dev123 5y ago

What's with the people who still use the term C/C++? C++ and C are separate languages. I'd be grateful for the author to reflect it in the Readme. Further, Bragging about LoC is bad. LoC is a poor measure of both quality and functionality. "C/C++ - a mythical language referred to by people who cannot or do not want to recognize the magnitude of differences between the facilities offered by C and C++" -- Stroustrup

fioawjpoifajio 5y ago
Concretely, rr uses both C and C++, so the term is perfectly valid, given that the two languages interoperate just fine.
smoldesu 5y ago
> C++ and C are separate languages. I'd be grateful for the author to reflect it in the Readme. I agree, but we could honestly be as granular as we want here. We could ask the author to delineate between C99 and C11, but it ultimately doesn't really matter. The point of referring to "C/C++" is to cast a blanket statement over the traditional compiled mainstays and use them as a point of reference. While they are indeed different, they're more alike then they are dissimilar. I think the author is perfectly justified here. > Further, Bragging about LoC is bad. LoC is a poor measure of both quality and functionality. Rust is a language that is extremely verbose, and properly formatted Rust code often uses more lines than necessary to improve readability (expanding match arms, removing inlined if-statements, etc.). Hell, if you look at the repo, it looks almost identical to a default Rust project: src is clearly exposed at the root, and everything else is pretty well organized into distinct folders. I disagree with the first part of your statement ("Bragging about LoC is bad") but agree with the second part ("LoC is a poor measure of both quality and functionality.") Honestly, I think LoC-shaming originated in languages like Java and Python, where more lines of code almost guaranteed more complexity. Rust's focus on zero cost abstraction ultimately means that even massive programs can run with minimal overhead. I'm not here to parade Rust's achievements in front of you, but I figured it was worth pointing out at least here.
- lmilcin 5y ago
  > Honestly, I think LoC-shaming originated in languages like Java and Python, where more lines of code almost guaranteed more complexity. Rust's focus on zero cost abstraction ultimately means that even massive programs can run with minimal overhead. Zero-cost abstractions are meant to be zero physical cost, not zero mental cost. LoC still translate to mental overhead and "LoC shaming" is appropriate for any language, not just verbose like Java or Python.
  - v8dev123 5y ago
    C++ also happen to use the term zero-cost abstractions along with RAII since 2011 but Chandler Carruth “There Are No Zero-cost Abstractions” You can watch and see what they really are. I bet this is true for Rust as-well.
lmilcin 5y ago
> Further, Bragging about LoC is bad. LoC is a poor measure of both quality and functionality. It is not a measure of quality but rather size of the project.
- SquibblesRedux 5y ago
  It's not the size of the project, it's how you use it.
- baby 5y ago
  Was he bragging about it? I think it was more about the amount of work accomplished. It’s not a 1k LOC project.
jeff-davis 5y ago
There aren't many pairs of mainstream languages that really interoperate well together. C and C++ do, which can blur the lines a bit. Not sure if this is what the author meant. With rust growing in popularity and good interoperability, I suspect we'll see the rise of projects written in C/Rust and C++/Rust, and maybe even C/C++/Rust. The line will obviously be more clear because of dramatically different syntax, packaging, build system, etc.
- v8dev123 5y ago
  My issue was "/" and I'd be fine if he had used "C, C++" or "C & C++"
  - jeff-davis 5y ago
    Does "/" have a concrete meaning? I vaguely think it means "with" or "and" or "or", but it seems more ambiguous.
    - v8dev123 5y ago
      It's ambiguous and not clear to reader!

Scuds 5y ago

> In my opinion, debuggers are under-appreciated and under-invested tools in a programmer's arsenal. Oh yeah - microsoft's time travelling debugger is under appreciated, even with their quality tooling. But, it's on the windows platform. So anything like this on Linux sounds like a very positive step forward.

flukus 5y ago
> So anything like this on Linux sounds like a very positive step forward. GDB has had reverse debugging since 2009 and there are other tools like rr and a few commercial ones. If anything I'd say that you calling it time travel debugging instead of reverse debugging demonstrates how insular the windows developer world is more than the windows platform being ignored. A great demonstration is in the video "Give Me 15 minutes and I'll change your view of GDB": https://www.youtube.com/watch?v=PorfLSr3DDI https://www.youtube.com/watch?v=PorfLSr3DDI
- Veserv 5y ago
  Time travel debugging is actually the more common historical term for the technology along with replay debugging specifically for the record-replay based variants. Reverse debugging as a term is really more of a GDB-ism and even there the term only really started gaining steam when rr produced a reasonable backend with GDB reverse debugging commands as a front-end. Also, frankly, the original GDB reverse debugging backend was entirely non-viable since it resulted in something like a 10,000x slowdown [2] during execution which made it essentially useless for anything other than actual toy problems. This is entirely an artifact of the implementation rather than any technology reason as most of the early solutions listed in [1] were somewhere between no slowdown for hardware-based solutions and 2x-100x for software based solutions. [1] http://jakob.engbloms.se/archives/1564 http://jakob.engbloms.se/archives/1564 [2] https://undo.io/resources/6-things-time-travel-debugging/ https://undo.io/resources/6-things-time-travel-debugging/
paxys 5y ago
Completely agree. At my current job I spent a lot of time in improving the developer tooling - step through debugging, live REPL, tracing, waterfalls, profiling, memory dumps. People are still not willing to spend the time to learn them and improve their workflows unless literally forced to do so. The prevalent attitude is simply laziness manifested as "why do I need all these fancy tools when print('I am here!') works just fine?"

jeff-davis 5y ago

From one of the linked pages: "Lack of garbage collection was a problem but runtimes are more troublesome...Linux signal handling becomes very complicated...Runtimes also often force layout of data structures be tuned to the needs of the garbage collector..." https://github.com/sidkshatriya/me/blob/master/002-why-rust.md#lack-of-garbage-collection-was-a-problem-but-runtimes-are-more-troublesome https://github.com/sidkshatriya/me/blob/master/002-why-rust.... That sums up my experience using a lot of higher-level languages. The pitch is always that language X should replace C because it's just as fast in most practical cases but much easier and safer. But the reason I use C is because of the pain of complex runtimes, especially when interoperating with other languages. And that's also why I'm interested in Rust. It's the first high-level language (I use the term loosely) that doesn't interfere with anything you're trying to do. It can even do dynamic dispatch on ordinary pointers to structures with a C memory layout, because it doesn't add a vtable pointer to structs (like C++ does). "I don't know much about dlang -- it could have been the best of both worlds" Yeah, I skipped over dlang, too. And I don't have a good reason for that, aside from a lack of time to really explore both. I hope dlang keeps growing and eventually I'll look into what it has to offer.

v8dev123 5y ago
Also, "Lack of Object-Orientation was a concern" Whenever you port a big program to another language it is important to be conservative, in my view. You don't want to make so many structural changes in the way things work in the original codebase while porting things over. You risk things becoming very confusing and the port could fail. In future iterations you could definitely make things more idiomatic in the target language. As far as Rust is concerned, it does not have traditional OO features. But by using the Deref/DerefMut trait specifically and traits in general I was able to recover and mimic a lot of OO behaviors present in rr in rd. The rd code may not always be beautiful. FYI, Rust had a GC also Classes in it's initial versions but they were removed for some reason!!!
- jeff-davis 5y ago
  "Whenever you port a big program to another language it is important to be conservative, in my view." Either be very conservative or just tear things up. I think the middle ground is the worst, where you can't decide whether it's a rewrite or a port.

milani 5y ago

From the blog "Just like llvm facilitated the rise of hundreds of new computer languages, I forsee a similar rise for debugging and debuggers in the coming years." But the author provides no evidence to support the claim. Why would the status quo change?