| (I work for Undo) > gdb has had reversible debugging since release 7, in 2009. What does udb offer that it lacks? GDB's built-in reversible debugging is cool (and it's helped raise awareness) but it doesn't scale well. We build on the same command set and serial protocol that GDB defined - UDB is GDB but with additional Python code hooking it up to our separate record/replay engine. For UDB, I'd say we offer:
1. Performance & efficiency (orders of magnitude faster at runtime and lower in memory requirements).
2. Recordings can be saved to portable files (share with colleagues, receive from customers, etc).
3. Library API so applications can self-record with control of when to capture and save.
4. Wider support of modern software (proactively tracking modern CPU features, shared memory and device maps, etc).
5. Correctness (in the past we've found the reverse operations in GDB don't have as strong semantics as we'd hoped, though I'd also be happy to be wrong here) FWIW, rr (https://rr-project.org/) also offers many similar benefits over GDB's built-in system (though not the library API in point 3) but with differences in what CPUs / systems are supported, ability to attach at runtime, etc. If you're looking for an open source solution, I'd choose rr over GDB's built-in approach. |