Hacker News new | ask | show | jobs
by Scuds 1861 days 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.
2 comments
paxys 1861 days 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?"

link
flukus 1861 days 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

link
Veserv 1861 days 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

[2] https://undo.io/resources/6-things-time-travel-debugging/

link